From owner-freebsd-current@FreeBSD.ORG Tue Jan 1 06:54:39 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 103EA16A49C for ; Tue, 1 Jan 2008 06:54:39 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.182]) by mx1.freebsd.org (Postfix) with ESMTP id D8C5C13C468 for ; Tue, 1 Jan 2008 06:54:38 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so8580309waf.3 for ; Mon, 31 Dec 2007 22:54:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=UNDDGaNq+qK9j2H8tmJiDi2IH7+/nQ46F9cT4C9ccb4=; b=Jk0Ws1z+FtlBt29ovSqzpG4DMq75weAjSQganWgjBsAdl48QfqXZCeoNVj4g5jFySuSGrOIsslOX+USqb+3esYVRkcDwa7A9wXYI+sqW4fq0j8Bkikcltdno7OgUDVKKXGZI3N8l24f4aDizfWhJNrWvx6o4LlNvH4qbOV8qddA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=rK/Xd2po2K91edq41HVBy5/fD+mT/cHtFD7wB/kWPcbGTITOtyXbkR4IgR/NEK9NWcX6TIi/bFAS35ZjJkA4vThBmmBOxnNkq1okSjoav8t/R/XtYWZIn1/f/pVblK2RIdakRmVLB2iea6chwuby8+MCrnz9X2XtCs/4fuC4Mj4= Received: by 10.142.215.5 with SMTP id n5mr3713133wfg.161.1199168867374; Mon, 31 Dec 2007 22:27:47 -0800 (PST) Received: by 10.142.162.20 with HTTP; Mon, 31 Dec 2007 22:27:47 -0800 (PST) Message-ID: Date: Tue, 1 Jan 2008 14:27:47 +0800 From: "Sepherosa Ziehau" To: "=?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?=" In-Reply-To: <86ir2hznnd.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <86ir2hznnd.fsf@ds4.des.no> Cc: kevlo@freebsd.org, sam@freebsd.org, current@freebsd.org, net@freebsd.org Subject: Re: if_ral regression X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jan 2008 06:54:39 -0000 On Dec 29, 2007 8:33 PM, Dag-Erling Sm=F8rgrav wrote: > I upgraded my router cum firewall cum access point (soekris net4801 with > a cheap third-party ralink-based wlan adapter) from RELENG_6 to HEAD and > noticed what seems to be a regression in if_ral. After a certain amount > of use (i.e. actually having a client connected to it and transferring > data), the connection falters, and eventually the client can no longer > see even see the access point in a scan. Restarting the interface on > the router (/etc/rc.d/netif restart ral0) fixes it. I now have a cron > job that does this every five minutes. I still get occasional outages, > but all I have to do is wait a few minutes for the cron job to kick in. > > Outages are clearly related to traffic; a sure-fire way to trigger one > is to start a backup job on my laptop (rsync to my file server). I will > lose the wlan connection repeatedly until I either stop trying or run > the script with a bandwidth limit. > > des@soe ~% uname -a > FreeBSD soe.des.no 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Sat Dec 15 20:46:2= 9 UTC 2007 des@pwd.des.no:/usr/obj/usr/src/sys/soe i386 > des@soe ~% kldstat -v > Id Refs Address Size Name > 1 18 0xc0400000 33fdfc kernel (/boot/soe/kernel) > 2 1 0xc0740000 7690 if_sis.ko (/boot/soe/if_sis.ko) > 3 2 0xc0748000 1dbe0 miibus.ko (/boot/soe/miibus.ko) > 4 1 0xc0766000 18e28 if_ral.ko (/boot/soe/if_ral.ko) > 5 4 0xc077f000 2a95c wlan.ko (/boot/soe/wlan.ko) > 6 1 0xc07aa000 2cb0 wlan_acl.ko (/boot/soe/wlan_acl.ko) > 7 1 0xc07ad000 1924 wlan_scan_ap.ko (/boot/soe/wlan_scan_ap.ko) > 8 1 0xc107f000 6000 geom_md.ko (/boot/soe/geom_md.ko) > 9 1 0xc10f9000 2000 pflog.ko (/boot/soe/pflog.ko) > 10 1 0xc10fb000 2f000 pf.ko (/boot/soe/pf.ko) > 11 4 0xc118d000 a000 netgraph.ko (/boot/soe/netgraph.ko) > 12 1 0xc119c000 3000 ng_ether.ko (/boot/soe/ng_ether.ko) > 13 1 0xc11a8000 5000 ng_pppoe.ko (/boot/soe/ng_pppoe.ko) > 14 1 0xc11ad000 4000 ng_socket.ko (/boot/soe/ng_socket.ko) > des@soe ~% grep ral0 /var/run/dmesg.boot > ral0: mem 0xa0004000-0xa0005fff irq 11 at devi= ce 10.0 on pci0 I don't whether following thingies will fix your problem: 1) rt2560.c: rt2560_setup_tx_desc() Set RT2560_{TX,TX_CIPHER}_BUSY desc flag at the end of this function, instead of at the beginning of this function. The original way _may_ confuse hardware encryption/tx engine. 2) And the rt2560_bbp_read() is not correct, it should look like following: static uint8_t rt2560_bbp_read(struct rt2560_softc *sc, uint8_t reg) { =09uint32_t val; =09int ntries; =09for (ntries =3D 0; ntries < 100; ntries++) { =09=09if (!(RAL_READ(sc, RT2560_BBPCSR) & RT2560_BBP_BUSY)) =09=09=09break; =09=09DELAY(1); =09} =09if (ntries =3D=3D 100) { =09=09device_printf(sc->sc_dev, "could not read from BBP\n"); =09=09return 0; =09} =09val =3D RT2560_BBP_BUSY | reg << 8; =09RAL_WRITE(sc, RT2560_BBPCSR, val); =09for (ntries =3D 0; ntries < 100; ntries++) { =09=09val =3D RAL_READ(sc, RT2560_BBPCSR); =09=09if (!(val & RT2560_BBP_BUSY)) =09=09=09return val & 0xff; =09=09DELAY(1); =09} =09device_printf(sc->sc_dev, "could not read from BBP\n"); =09return 0; } 3) After above fix, rt2560_set_txantenna() and rt2560_set_rxantenna() should be called after rt2560_bbp_init(), since above two function touch BBP. NOTE: without above fix, you may burn your card. Even with these in place in dfly, I still have strange TX performance regression in sta mode (drop from 20Mb/s to 3Mb/s under very well condition) on certain hardwares after 20sec~30sec TCP_STREAM netperf testing; didn't have enough time to dig, however, all of the tested hardwares stayed connected during testing (I usually run netperf stream test for 12 hours or more). Best Regards, sephe --=20 Live Free or Die From owner-freebsd-current@FreeBSD.ORG Tue Jan 1 13:32:26 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4AA7B16A46B; Tue, 1 Jan 2008 13:32:26 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 040BD13C4E3; Tue, 1 Jan 2008 13:32:25 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id C76A420A0; Tue, 1 Jan 2008 14:32:16 +0100 (CET) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: -0.1/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id B95E9209C; Tue, 1 Jan 2008 14:32:16 +0100 (CET) Received: by ds4.des.no (Postfix, from userid 1001) id 983FC8449F; Tue, 1 Jan 2008 14:32:16 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: "Sepherosa Ziehau" References: <86ir2hznnd.fsf@ds4.des.no> Date: Tue, 01 Jan 2008 14:32:16 +0100 In-Reply-To: (Sepherosa Ziehau's message of "Tue\, 1 Jan 2008 14\:27\:47 +0800") Message-ID: <86abnpu0wv.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: kevlo@freebsd.org, sam@freebsd.org, current@freebsd.org, net@freebsd.org Subject: Re: if_ral regression X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jan 2008 13:32:26 -0000 "Sepherosa Ziehau" writes: > I don't whether following thingies will fix your problem: > [...] Can you provide a diff? DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Tue Jan 1 13:52:23 2008 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6DFBE16A419 for ; Tue, 1 Jan 2008 13:52:23 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 9021913C457; Tue, 1 Jan 2008 13:52:22 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <477A4594.7050304@FreeBSD.org> Date: Tue, 01 Jan 2008 14:52:20 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Mikhail Teterin References: <200712311620.lBVGKweV086742@bonkers.video-collage.com> In-Reply-To: <200712311620.lBVGKweV086742@bonkers.video-collage.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: efinleywork@efinley.com, current@FreeBSD.org Subject: Re: a new way to hang 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jan 2008 13:52:23 -0000 Mikhail Teterin wrote: >>> After correcting the destination path and REBOOTING, the dump >>> is proceeding. I removed the L-flag too, just in case :( >>> >>> Is this really a new way, or is it well known already? Thanks! >> -L has been hanging systems ever since it existed. Don't use it. > > Why does `dump' implore me to use it, then? Because the previous poster is being uncharitable with the facts :) There are a history of problems with -L (more generally, UFS snapshots), but these are believed to have been fixed over the past 2 years. Since you are claiming to have found a new one, please follow up with the usual kernel debugging so someone can try and study it. > I wonder, if this is also > a problem on DragonFlyBSD... Since Dragonfly is FreeBSD 4 + some stuff it is unlikely that it even supports UFS snapshots. Kris From owner-freebsd-current@FreeBSD.ORG Tue Jan 1 16:08:11 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CE46616A468; Tue, 1 Jan 2008 16:08:11 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.freebsd.org (Postfix) with ESMTP id A284213C44B; Tue, 1 Jan 2008 16:08:11 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 7C4F982CDC; Tue, 1 Jan 2008 10:58:04 -0500 (EST) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Tue, 01 Jan 2008 10:58:04 -0500 X-Sasl-enc: Ih19NMzuZ0PxUXaNFZV/o90mGE03F0AhTriJhqfFw07Z 1199203084 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id E280811359; Tue, 1 Jan 2008 10:58:03 -0500 (EST) Message-ID: <477A630A.5050103@FreeBSD.org> Date: Tue, 01 Jan 2008 15:58:02 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.6 (X11/20070928) MIME-Version: 1.0 To: Vladimir Grebenschikov References: <1198439210.1617.8.camel@localhost> In-Reply-To: <1198439210.1617.8.camel@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current , freebsd-mobile Subject: Re: device uart - does it work for anybody with PCMCI card? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jan 2008 16:08:11 -0000 Vladimir Grebenschikov wrote: > Hi ppl > > Can anybody confirm that device uart just works for some PCMCI card ? > > I've tried with two different cards (both are different pccard celluar > modems) and gets exactly same result. > > Device is detected, port can be open with any valid speed, but no any > communication, or probably, no any replays from modem. > I see the same issue with "device uart" using a US Robotics Speedster 28800 PCMCIA with 6.2-RELEASE. uart attaches, but I see the same symptoms as you. Rebuilding the kernel with sio, puc, and pccard statically compiled results in the PCMCIA modem being detected as per onboard serial ports would be (this Thinkpad T43 only has an IR port), and the modem works OK. cheers BMS From owner-freebsd-current@FreeBSD.ORG Tue Jan 1 16:13:11 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B6F3416A41B; Tue, 1 Jan 2008 16:13:11 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.freebsd.org (Postfix) with ESMTP id 8D25413C4E8; Tue, 1 Jan 2008 16:13:11 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 5EC0F591ED; Tue, 1 Jan 2008 10:55:40 -0500 (EST) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Tue, 01 Jan 2008 10:55:40 -0500 X-Sasl-enc: sua2Upwsy/xOgdkBxje9zLEzo1pYwDqqbzJxs/vEOZGV 1199202940 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id AD9ECAEFE; Tue, 1 Jan 2008 10:55:39 -0500 (EST) Message-ID: <477A627A.8010601@FreeBSD.org> Date: Tue, 01 Jan 2008 15:55:38 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.6 (X11/20070928) MIME-Version: 1.0 To: Mike Silbersack References: <20071228015651.X1565@odysseus.silby.com> <20071228095539.F45653@fledge.watson.org> <20071229180004.O6052@odysseus.silby.com> In-Reply-To: <20071229180004.O6052@odysseus.silby.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Robert Watson , current@freebsd.org Subject: Re: [patch] Auto-setting hz to 100 inside QEMU/VMWare X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jan 2008 16:13:11 -0000 This is really cool. If it works (it looks OK) please do commit it. Cheers BMS From owner-freebsd-current@FreeBSD.ORG Tue Jan 1 17:58:04 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C35B116A421; Tue, 1 Jan 2008 17:58:04 +0000 (UTC) (envelope-from peter.schuller@infidyne.com) Received: from smtp.infidyne.com (ds9.infidyne.com [88.80.6.206]) by mx1.freebsd.org (Postfix) with ESMTP id 33E9F13C47E; Tue, 1 Jan 2008 17:58:04 +0000 (UTC) (envelope-from peter.schuller@infidyne.com) Received: from c-8216e555.03-51-73746f3.cust.bredbandsbolaget.se (c-8216e555.03-51-73746f3.cust.bredbandsbolaget.se [85.229.22.130]) by smtp.infidyne.com (Postfix) with ESMTP id 5148D779CF; Tue, 1 Jan 2008 18:58:02 +0100 (CET) From: Peter Schuller To: freebsd-current@freebsd.org Date: Tue, 1 Jan 2008 18:57:48 +0100 User-Agent: KMail/1.9.7 References: <200707282028.37102.peter.schuller@infidyne.com> <200707292157.09742.peter.schuller@infidyne.com> <200707310126.06923.peter.schuller@infidyne.com> In-Reply-To: <200707310126.06923.peter.schuller@infidyne.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1470949.D78ygmVzrc"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200801011857.57757.peter.schuller@infidyne.com> Cc: Pawel Jakub Dawidek , current@freebsd.org Subject: Re: (ZFS?): panic: lockmgr: locking against myself X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jan 2008 17:58:04 -0000 --nextPart1470949.D78ygmVzrc Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline (quoting last post for convenience; more history at=20 http://www.usenetarticles.com/thread/952336.html) > > vnode 0xffffff00037473e0: tag devfs, type VDIR > > usecount 0, writecount 0, refcount 1 mountedhere 0xffffff0003745ca0 > > flags (VV_ROOT) > > lock type devfs: EXCL (count 1) by thread 0xffffff00010e6680 (pid 1) > > Some additional facts: > > Looking at the printouts, there is always a sequence of three or more > (three at least twice; more than three at least once) vrele():s of the sa= me > vnode, in both the successful case and the panicing case. There are no > vrele():s of any other vnodes in either case. > > Inserting enter/exit debug printouts in mountcheckdirs() confirms that all > calls occur within the bounds of a single call to mountcheckdirs(). Does > not this imply there is some locking mismatch in the non-ZFS specific cod= e? > I must admit I find the locking confusing; with several locking/unlocking > functions/macros intermixed at different levels in the callstack. My > (incorrect) reading was that this panic should always be happening, which > is obviously not the case. > > Running with vfs.zfs.debug=3D1 confirms that vdev_geom open/attach/detach= is > happening prior to any vrele() even in the panicing case (i.e., zfs pool > discovery seems to complete). > > In the case of an expected provider not being found, vd->vdev_devid is NU= LL > in vdev_geom_open(), based on the "provider not found" debug printout > (perhaps normal?). I *think* I just experienced the same problem on 7.0-BETA3, except the kern= el=20 does not have WITNESS/INVARIANTS so I just get a hack instead of a panic. I= =20 wanted to post with the information I have for completeness; I realize what= =20 follows is a bunch of anecdotal mumbo-jumbo. The boot-up process hangs right before the would-be 'trying to mount root=20 from....", after all the glabel tasting has completed. This was on a completely different system than the one in the original post= ,=20 but it also has root-on-zfs (this time on a 5 disk raidz2). It's a dual cor= e=20 amd64 machine with a low-end mobo and low-end SATA controllers (SiI and som= e=20 built-in nVidia chipset). It all started when I was booting back into FreeBSD after having Windows=20 booted for a while. It wouldn't boot. If fiddled some wiht vfs.zfs.debug=3D= 1,=20 removing a cd ion the drive (in case it affected timing), but it did not=20 help. I did not try the boot-7-live cd trick this time as I did originally = on=20 the other machine. I looked carefully to make sure all drives were detected, including geom=20 tasting on all but one of them that are in the zfs pool. The I/O indicator= =20 leds on the respective drives that ar part of the zfs pool did not indicate= =20 any I/O after the hang. I waited 5+ minutes at least once in the hope that = it=20 was a drive timing out. After several attempts I turned off the machine and let it do a cold boot -= at=20 this point the system booted fine. This is different from before, in that previously the behavior was seemingl= y=20 triggered by changes in system configuration (loss of a drive, etc). This=20 time it was just a reboot. I *did* touch a bunch of cables in between, and= =20 blew some air on components (for reasons not relating to this) which I=20 originally figured could explain the problem. Before this incident, the system has booted with root-on-zfs several times = (at=20 least 25, probably more like 50+) without any kind of problem, ever. =2D-=20 / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller ' Key retrieval: Send an E-Mail to getpgpkey@scode.org E-Mail: peter.schuller@infidyne.com Web: http://www.scode.org --nextPart1470949.D78ygmVzrc Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBHen8lDNor2+l1i30RAh9uAJ0XoABn2gWFopb+g0hP73bRS8HJ/ACgm42P Ho33IXjvrscn04uOtk4K31I= =mTaZ -----END PGP SIGNATURE----- --nextPart1470949.D78ygmVzrc-- From owner-freebsd-current@FreeBSD.ORG Tue Jan 1 18:18:02 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 763FD16A417 for ; Tue, 1 Jan 2008 18:18:02 +0000 (UTC) (envelope-from peter.schuller@infidyne.com) Received: from smtp.infidyne.com (ds9.infidyne.com [88.80.6.206]) by mx1.freebsd.org (Postfix) with ESMTP id EEB0113C4E9 for ; Tue, 1 Jan 2008 18:18:01 +0000 (UTC) (envelope-from peter.schuller@infidyne.com) Received: from c-8216e555.03-51-73746f3.cust.bredbandsbolaget.se (c-8216e555.03-51-73746f3.cust.bredbandsbolaget.se [85.229.22.130]) by smtp.infidyne.com (Postfix) with ESMTP id 5148D779CF; Tue, 1 Jan 2008 18:58:02 +0100 (CET) From: Peter Schuller To: freebsd-current@freebsd.org Date: Tue, 1 Jan 2008 18:57:48 +0100 User-Agent: KMail/1.9.7 References: <200707282028.37102.peter.schuller@infidyne.com> <200707292157.09742.peter.schuller@infidyne.com> <200707310126.06923.peter.schuller@infidyne.com> In-Reply-To: <200707310126.06923.peter.schuller@infidyne.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1470949.D78ygmVzrc"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200801011857.57757.peter.schuller@infidyne.com> Cc: Pawel Jakub Dawidek , current@freebsd.org Subject: Re: (ZFS?): panic: lockmgr: locking against myself X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jan 2008 18:18:02 -0000 --nextPart1470949.D78ygmVzrc Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline (quoting last post for convenience; more history at=20 http://www.usenetarticles.com/thread/952336.html) > > vnode 0xffffff00037473e0: tag devfs, type VDIR > > usecount 0, writecount 0, refcount 1 mountedhere 0xffffff0003745ca0 > > flags (VV_ROOT) > > lock type devfs: EXCL (count 1) by thread 0xffffff00010e6680 (pid 1) > > Some additional facts: > > Looking at the printouts, there is always a sequence of three or more > (three at least twice; more than three at least once) vrele():s of the sa= me > vnode, in both the successful case and the panicing case. There are no > vrele():s of any other vnodes in either case. > > Inserting enter/exit debug printouts in mountcheckdirs() confirms that all > calls occur within the bounds of a single call to mountcheckdirs(). Does > not this imply there is some locking mismatch in the non-ZFS specific cod= e? > I must admit I find the locking confusing; with several locking/unlocking > functions/macros intermixed at different levels in the callstack. My > (incorrect) reading was that this panic should always be happening, which > is obviously not the case. > > Running with vfs.zfs.debug=3D1 confirms that vdev_geom open/attach/detach= is > happening prior to any vrele() even in the panicing case (i.e., zfs pool > discovery seems to complete). > > In the case of an expected provider not being found, vd->vdev_devid is NU= LL > in vdev_geom_open(), based on the "provider not found" debug printout > (perhaps normal?). I *think* I just experienced the same problem on 7.0-BETA3, except the kern= el=20 does not have WITNESS/INVARIANTS so I just get a hack instead of a panic. I= =20 wanted to post with the information I have for completeness; I realize what= =20 follows is a bunch of anecdotal mumbo-jumbo. The boot-up process hangs right before the would-be 'trying to mount root=20 from....", after all the glabel tasting has completed. This was on a completely different system than the one in the original post= ,=20 but it also has root-on-zfs (this time on a 5 disk raidz2). It's a dual cor= e=20 amd64 machine with a low-end mobo and low-end SATA controllers (SiI and som= e=20 built-in nVidia chipset). It all started when I was booting back into FreeBSD after having Windows=20 booted for a while. It wouldn't boot. If fiddled some wiht vfs.zfs.debug=3D= 1,=20 removing a cd ion the drive (in case it affected timing), but it did not=20 help. I did not try the boot-7-live cd trick this time as I did originally = on=20 the other machine. I looked carefully to make sure all drives were detected, including geom=20 tasting on all but one of them that are in the zfs pool. The I/O indicator= =20 leds on the respective drives that ar part of the zfs pool did not indicate= =20 any I/O after the hang. I waited 5+ minutes at least once in the hope that = it=20 was a drive timing out. After several attempts I turned off the machine and let it do a cold boot -= at=20 this point the system booted fine. This is different from before, in that previously the behavior was seemingl= y=20 triggered by changes in system configuration (loss of a drive, etc). This=20 time it was just a reboot. I *did* touch a bunch of cables in between, and= =20 blew some air on components (for reasons not relating to this) which I=20 originally figured could explain the problem. Before this incident, the system has booted with root-on-zfs several times = (at=20 least 25, probably more like 50+) without any kind of problem, ever. =2D-=20 / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller ' Key retrieval: Send an E-Mail to getpgpkey@scode.org E-Mail: peter.schuller@infidyne.com Web: http://www.scode.org --nextPart1470949.D78ygmVzrc Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBHen8lDNor2+l1i30RAh9uAJ0XoABn2gWFopb+g0hP73bRS8HJ/ACgm42P Ho33IXjvrscn04uOtk4K31I= =mTaZ -----END PGP SIGNATURE----- --nextPart1470949.D78ygmVzrc-- From owner-freebsd-current@FreeBSD.ORG Tue Jan 1 19:46:48 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 166E816A41B for ; Tue, 1 Jan 2008 19:46:48 +0000 (UTC) (envelope-from roy@marples.name) Received: from mail.marples.name (rsm.demon.co.uk [80.177.111.50]) by mx1.freebsd.org (Postfix) with ESMTP id C3C2013C4D1 for ; Tue, 1 Jan 2008 19:46:47 +0000 (UTC) (envelope-from roy@marples.name) Received: from [10.73.1.31] (uberlaptop.marples.name [10.73.1.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.marples.name (Postfix) with ESMTP id A57741900DE for ; Tue, 1 Jan 2008 19:46:16 +0000 (GMT) From: Roy Marples To: freebsd-current@freebsd.org Content-Type: text/plain Date: Tue, 01 Jan 2008 19:46:16 +0000 Message-Id: <1199216776.25213.10.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.12.2 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Subject: #define _XOPEN_SOURCE breaks userland applications X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jan 2008 19:46:48 -0000 Hi Consider the following #define _XOPEN_SOURCE 600 #include int main(void) { return 0; } Gives the following when compiled > gcc x.c In file included from x.c:2: /usr/include/sys/file.h:162: error: expected specifier-qualifier-list before 'u_int' The error was caused by this patch http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/sys/types.h.diff?r1=1.73;r2=1.74;f=h No CVS comment as to why the change was needed I propose that the first part of the patch is reverted, as follows Thanks Roy --- src/sys/sys/types.h 2008-01-01 18:52:26.000000000 +0000 +++ src.orig/sys/sys/types.h 2008-01-01 19:20:21.000000000 +0000 @@ -46,7 +46,7 @@ #include -#if __BSD_VISIBLE +#ifndef _POSIX_SOURCE typedef unsigned char u_char; typedef unsigned short u_short; typedef unsigned int u_int; From owner-freebsd-current@FreeBSD.ORG Tue Jan 1 20:52:43 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8111D16A417 for ; Tue, 1 Jan 2008 20:52:43 +0000 (UTC) (envelope-from martin_voros@yahoo.com) Received: from web55510.mail.re4.yahoo.com (web55510.mail.re4.yahoo.com [206.190.58.219]) by mx1.freebsd.org (Postfix) with SMTP id 2921413C46A for ; Tue, 1 Jan 2008 20:52:43 +0000 (UTC) (envelope-from martin_voros@yahoo.com) Received: (qmail 7999 invoked by uid 60001); 1 Jan 2008 20:26:01 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=rv9bXeuYA0g7WY/RvYFYyJHWAztwVek5qp1GNu0s146dAtJdGhUn+cNEVsDHe+es6HVgsWOG70T0zDjrkIEwB+JUz7hluorPOP/h1khch4SJPUZP9+TmpNMCq9ndv7k69FdfUEptxU/wGD4fXQ8RroAxweOnGB3nVwPLgPjHo1c=; X-YMail-OSG: f.h_VoEVM1kFrUPDxlKyIsinIVRLkuDL4z6rNiPIQjoY28iYYLouk.UCzME0DUKKkD9Cw.eBOyFY.frGOeaeu0JXF5E5mBegSZBYIaJXsrAgq8KJkXOoOWc2kw-- Received: from [77.247.224.21] by web55510.mail.re4.yahoo.com via HTTP; Tue, 01 Jan 2008 12:26:01 PST X-Mailer: YahooMailRC/818.31 YahooMailWebService/0.7.158.1 Date: Tue, 1 Jan 2008 12:26:01 -0800 (PST) From: Martin Voros To: Mike Silbersack MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <656382.6504.qm@web55510.mail.re4.yahoo.com> Cc: current@freebsd.org Subject: Re: [patch] Auto-setting hz to 100 inside QEMU/VMWare X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jan 2008 20:52:43 -0000 It works fine here (VMware). Martin ----- Original Message ---- From: Mike Silbersack To: Robert Watson Cc: current@freebsd.org Sent: Sunday, December 30, 2007 1:01:43 AM Subject: Re: [patch] Auto-setting hz to 100 inside QEMU/VMWare On Fri, 28 Dec 2007, Robert Watson wrote: > I like the general idea, but one thing that does worry me is that this > prevents me from using config to set HZ at all, I have to set it at runtime > using the tunable. Could we add an: Attached is a patch which attempts to address all of Robert's concerns and includes all the strings for the various VMs that people have mailed in to me. Please test/review. :) Mike "Silby" Silbersack -----Inline Attachment Follows----- diff -u -r /usr/src/sys.old/amd64/amd64/machdep.c /usr/src/sys/amd64/amd64/machdep.c --- /usr/src/sys.old/amd64/amd64/machdep.c 2007-12-29 03:01:02.000000000 -0600 +++ /usr/src/sys/amd64/amd64/machdep.c 2007-12-29 18:57:01.000000000 -0600 @@ -1935,3 +1935,33 @@ } #endif /* KDB */ + +/* kenv strings used to identify various VM environments */ + +static char *vm_strings[] = { + "hint.acpi.0.oem", "QEMU", + "hint.acpi.0.oem", "VBOX", /* VirtualBox */ + "smbios.system.maker", "VMware, Inc.", + "smbios.bios.vendor", "Parallels Software International Inc.", + NULL + }; + +int +detect_virtualmachine(void) +{ + char *envptr; + int i; + for (i = 0; ; i += 2) { + if (vm_strings[i] == NULL) + break; + envptr = getenv(vm_strings[i]); + if (envptr) { + if (strncmp(envptr, vm_strings[i+1], strlen(vm_strings[i+1])) == 0) { + freeenv(envptr); + return 1; + } + freeenv(envptr); + } + } + return 0; +} diff -u -r /usr/src/sys.old/arm/arm/machdep.c /usr/src/sys/arm/arm/machdep.c --- /usr/src/sys.old/arm/arm/machdep.c 2007-12-29 03:01:06.000000000 -0600 +++ /usr/src/sys/arm/arm/machdep.c 2007-12-29 18:57:21.000000000 -0600 @@ -631,3 +631,9 @@ pcb->un_32.pcb32_lr = tf->tf_usr_lr; pcb->un_32.pcb32_sp = tf->tf_usr_sp; } + +int +detect_virtualmachine(void) +{ + return 0; +} diff -u -r /usr/src/sys.old/conf/NOTES /usr/src/sys/conf/NOTES --- /usr/src/sys.old/conf/NOTES 2007-12-29 03:01:19.000000000 -0600 +++ /usr/src/sys/conf/NOTES 2007-12-29 18:54:40.000000000 -0600 @@ -1115,6 +1115,7 @@ # the accuracy of operation. options HZ=100 +options VIRTUAL_HZ=100 # Enable support for the kernel PLL to use an external PPS signal, # under supervision of [x]ntpd(8) diff -u -r /usr/src/sys.old/conf/options /usr/src/sys/conf/options --- /usr/src/sys.old/conf/options 2007-12-29 03:01:19.000000000 -0600 +++ /usr/src/sys/conf/options 2007-12-29 03:06:22.000000000 -0600 @@ -262,6 +262,7 @@ # Options used only in subr_param.c. HZ opt_param.h +VIRTUAL_HZ opt_param.h MAXFILES opt_param.h NBUF opt_param.h NSFBUFS opt_param.h diff -u -r /usr/src/sys.old/i386/i386/machdep.c /usr/src/sys/i386/i386/machdep.c --- /usr/src/sys.old/i386/i386/machdep.c 2007-12-29 03:01:29.000000000 -0600 +++ /usr/src/sys/i386/i386/machdep.c 2007-12-29 03:59:05.000000000 -0600 @@ -3110,3 +3110,33 @@ } #endif /* KDB */ + +/* kenv strings used to identify various VM environments */ + +static char *vm_strings[] = { + "hint.acpi.0.oem", "QEMU", + "hint.acpi.0.oem", "VBOX", /* VirtualBox */ + "smbios.system.maker", "VMware, Inc.", + "smbios.bios.vendor", "Parallels Software International Inc.", + NULL + }; + +int +detect_virtualmachine(void) +{ + char *envptr; + int i; + for (i = 0; ; i += 2) { + if (vm_strings[i] == NULL) + break; + envptr = getenv(vm_strings[i]); + if (envptr) { + if (strncmp(envptr, vm_strings[i+1], strlen(vm_strings[i+1])) == 0) { + freeenv(envptr); + return 1; + } + freeenv(envptr); + } + } + return 0; +} diff -u -r /usr/src/sys.old/ia64/ia64/machdep.c /usr/src/sys/ia64/ia64/machdep.c --- /usr/src/sys.old/ia64/ia64/machdep.c 2007-12-29 03:01:29.000000000 -0600 +++ /usr/src/sys/ia64/ia64/machdep.c 2007-12-29 19:02:23.000000000 -0600 @@ -1531,3 +1531,9 @@ { return (ENODEV); } + +int +detect_virtualmachine(void) +{ + return 0; +} diff -u -r /usr/src/sys.old/kern/subr_param.c /usr/src/sys/kern/subr_param.c --- /usr/src/sys.old/kern/subr_param.c 2007-12-29 03:01:29.000000000 -0600 +++ /usr/src/sys/kern/subr_param.c 2007-12-29 03:14:23.000000000 -0600 @@ -58,6 +58,9 @@ # define HZ 100 # endif #endif +#ifndef VIRTUAL_HZ +# define VIRTUAL_HZ 100 +#endif #define NPROC (20 + 16 * maxusers) #ifndef NBUF #define NBUF 0 @@ -109,7 +112,16 @@ init_param1(void) { - hz = HZ; + /* Virtualization environments can't keep up with a + * 1000hz tick rate, leading to highly inaccurate + * timekeeping by FreeBSD guests. To fix this problem, + * drop back to 100hz when we detect that we are running + * inside a virtual machine. + */ + if (detect_virtualmachine()) + hz = VIRTUAL_HZ; + else + hz = HZ; TUNABLE_INT_FETCH("kern.hz", &hz); tick = 1000000 / hz; diff -u -r /usr/src/sys.old/pc98/pc98/machdep.c /usr/src/sys/pc98/pc98/machdep.c --- /usr/src/sys.old/pc98/pc98/machdep.c 2007-12-29 03:01:34.000000000 -0600 +++ /usr/src/sys/pc98/pc98/machdep.c 2007-12-29 19:01:49.000000000 -0600 @@ -2791,3 +2791,9 @@ } #endif /* KDB */ + +int +detect_virtualmachine(void) +{ + return 0; +} diff -u -r /usr/src/sys.old/powerpc/powerpc/intr_machdep.c /usr/src/sys/powerpc/powerpc/intr_machdep.c --- /usr/src/sys.old/powerpc/powerpc/intr_machdep.c 2007-12-29 03:01:34.000000000 -0600 +++ /usr/src/sys/powerpc/powerpc/intr_machdep.c 2007-12-29 18:59:36.000000000 -0600 @@ -304,3 +304,9 @@ if (i != NULL) PIC_MASK(pic, i->irq); } + +int +detect_virtualmachine(void) +{ + return 0; +} diff -u -r /usr/src/sys.old/sparc64/sparc64/machdep.c /usr/src/sys/sparc64/sparc64/machdep.c --- /usr/src/sys.old/sparc64/sparc64/machdep.c 2007-12-29 03:01:35.000000000 -0600 +++ /usr/src/sys/sparc64/sparc64/machdep.c 2007-12-29 19:01:33.000000000 -0600 @@ -910,3 +910,9 @@ mtx_pool_unlock(mtxpool_sleep, ut); return (ut); } + +int +detect_virtualmachine(void) +{ + return 0; +} diff -u -r /usr/src/sys.old/sun4v/sun4v/machdep.c /usr/src/sys/sun4v/sun4v/machdep.c --- /usr/src/sys.old/sun4v/sun4v/machdep.c 2007-12-29 03:01:01.000000000 -0600 +++ /usr/src/sys/sun4v/sun4v/machdep.c 2007-12-29 18:58:49.000000000 -0600 @@ -999,3 +999,9 @@ if (rdpr(pil) < PIL_TICK) hv_cpu_yield(); } + +int +detect_virtualmachine(void) +{ + return 0; +} diff -u -r /usr/src/sys.old/sys/systm.h /usr/src/sys/sys/systm.h --- /usr/src/sys.old/sys/systm.h 2007-12-29 03:01:35.000000000 -0600 +++ /usr/src/sys/sys/systm.h 2007-12-29 03:50:59.000000000 -0600 @@ -245,6 +245,8 @@ int unsetenv(const char *name); int testenv(const char *name); +int detect_virtualmachine(void); + typedef uint64_t (cpu_tick_f)(void); void set_cputicker(cpu_tick_f *func, uint64_t freq, unsigned var); extern cpu_tick_f *cpu_ticks; -----Inline Attachment Follows----- _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" ____________________________________________________________________________________ Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping From owner-freebsd-current@FreeBSD.ORG Tue Jan 1 21:16:32 2008 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 91C3216A41A for ; Tue, 1 Jan 2008 21:16:32 +0000 (UTC) (envelope-from mi@bonkers.video-collage.com) Received: from bonkers.video-collage.com (static-151-204-231-237.bos.east.verizon.net [151.204.231.237]) by mx1.freebsd.org (Postfix) with ESMTP id 3856913C47E for ; Tue, 1 Jan 2008 21:16:31 +0000 (UTC) (envelope-from mi@bonkers.video-collage.com) Received: from bonkers.video-collage.com (localhost [127.0.0.1]) by bonkers.video-collage.com (8.14.1/8.14.1) with ESMTP id m01LGQtb012861; Tue, 1 Jan 2008 16:16:26 -0500 (EST) (envelope-from mi@bonkers.video-collage.com) Received: (from mi@localhost) by bonkers.video-collage.com (8.14.1/8.14.1/Submit) id m01LGQhN012860; Tue, 1 Jan 2008 16:16:26 -0500 (EST) (envelope-from mi) From: Mikhail Teterin Message-Id: <200801012116.m01LGQhN012860@bonkers.video-collage.com> In-Reply-To: <477A4594.7050304@FreeBSD.org> To: Kris Kennaway Date: Tue, 1 Jan 2008 16:16:26 -0500 (EST) X-Mailer: ELM [version 2.4ME+ PL124 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" X-Virus-Scanned: ClamAV 0.88.7/5330/Tue Jan 1 15:33:57 2008 on bonkers.video-collage.com X-Virus-Status: Clean X-Mailman-Approved-At: Tue, 01 Jan 2008 21:28:01 +0000 Cc: efinleywork@efinley.com, current@FreeBSD.org Subject: Re: a new way to hang 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jan 2008 21:16:32 -0000 > >>> Is this really a new way, or is it well known already? Thanks! -L > >>has been hanging systems ever since it existed. Don't use it. > > > > Why does `dump' implore me to use it, then? > Because the previous poster is being uncharitable with the facts :) I'd say both previous posters reported problems -- their tone was different, but both reported their glass being, uhm, less then full :) > There are a history of problems with -L (more generally, UFS > snapshots), but these are believed to have been fixed over the past 2 > years. Since you are claiming to have found a new one, please follow > up with the usual kernel debugging so someone can try and study it. I'll try, but I am not, unfortunately, well setup for kernel debugging. Most of the time I only have one system, and can't afford to hang it even for a short while. > > I wonder, if this is also a problem on DragonFlyBSD... > > Since Dragonfly is FreeBSD 4 + some stuff it is unlikely that it even > supports UFS snapshots. Yes, you are right. I confused the -L with the -C option... Thanks, -mi From owner-freebsd-current@FreeBSD.ORG Tue Jan 1 21:40:19 2008 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 154C816A46B for ; Tue, 1 Jan 2008 21:40:19 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 3EEE113C442; Tue, 1 Jan 2008 21:40:14 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <477AB33B.7000506@FreeBSD.org> Date: Tue, 01 Jan 2008 22:40:11 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Mikhail Teterin References: <200801012116.m01LGQhN012860@bonkers.video-collage.com> In-Reply-To: <200801012116.m01LGQhN012860@bonkers.video-collage.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: efinleywork@efinley.com, current@FreeBSD.org Subject: Re: a new way to hang 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jan 2008 21:40:19 -0000 Mikhail Teterin wrote: >>>>> Is this really a new way, or is it well known already? Thanks! -L >>>> has been hanging systems ever since it existed. Don't use it. >>> Why does `dump' implore me to use it, then? > >> Because the previous poster is being uncharitable with the facts :) > > I'd say both previous posters reported problems -- their tone was > different, but both reported their glass being, uhm, less then full :) They made claims but failed to actually report anything. >> There are a history of problems with -L (more generally, UFS >> snapshots), but these are believed to have been fixed over the past 2 >> years. Since you are claiming to have found a new one, please follow >> up with the usual kernel debugging so someone can try and study it. > > I'll try, but I am not, unfortunately, well setup for kernel debugging. > Most of the time I only have one system, and can't afford to hang it even > for a short while. OK. Maybe it will stay broken until someone else can reproduce then. Kris From owner-freebsd-current@FreeBSD.ORG Wed Jan 2 03:01:00 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DA96916A41A for ; Wed, 2 Jan 2008 03:01:00 +0000 (UTC) (envelope-from srw@udor.net) Received: from mail.udor.net (mail.udor.net [64.34.95.190]) by mx1.freebsd.org (Postfix) with ESMTP id B2EEE13C46A for ; Wed, 2 Jan 2008 03:01:00 +0000 (UTC) (envelope-from srw@udor.net) Received: from localhost (KD121110020099.ppp-bb.dion.ne.jp [121.110.20.99]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.udor.net (Postfix) with ESMTP id D70664287 for ; Tue, 1 Jan 2008 21:39:53 -0500 (EST) Date: Wed, 2 Jan 2008 11:43:27 +0900 From: srwadleigh To: freebsd-current@freebsd.org Message-ID: <20080102114327.62f661f5@udor.net> X-Mailer: Claws Mail 3.0.2 (GTK+ 2.12.3; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Gjournal X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2008 03:01:00 -0000 I am having a strange problem with gjournal on a thinkpad T41, I am running: 7.0-PRERELEASE - Wed Jan 2 06:05:20 JST 2008 And have the problem with both a custom and generic kernel. If I load gjournal through loader.conf or compile GEOM_JOURNAL into the kernel, upon reboot all my slices change, and break booting. ad0s1a becomes ad0a ad0s1d becomes ad0d, and so on.. If I manually run gjournal load after boot the slices are fine, everything works as expected. Here is my journal setup: /dev/ad0s1f.journal 64G /usr/home Geom name: gjournal 2080874044 ID: 2080874044 Providers: 1. Name: ad0s1f.journal Mediasize: 70812433920 (66G) Sectorsize: 512 Mode: r1w1e1 Consumers: 1. Name: ad0s1f Mediasize: 71886176256 (67G) Sectorsize: 512 Mode: r1w1e1 Jend: 71886175744 Jstart: 70812433920 Role: Data,Journal Doing some research on the list I found a similar problem in the past with gmirror, where the slice and device ending at the same place was being confused. The solution suggested there seemed to be to hardcode the provider names into the metadata. http://lists.freebsd.org/pipermail/freebsd-stable/2005-May/014448.html My question is, is this possibly the same issue now with gjournal? and is it possible to hardcode provider names after a journal has been created? thanks srw From owner-freebsd-current@FreeBSD.ORG Wed Jan 2 03:07:38 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B305616A468 for ; Wed, 2 Jan 2008 03:07:38 +0000 (UTC) (envelope-from weongyo.jeong@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.181]) by mx1.freebsd.org (Postfix) with ESMTP id 7F66F13C44B for ; Wed, 2 Jan 2008 03:07:38 +0000 (UTC) (envelope-from weongyo.jeong@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so9178013waf.3 for ; Tue, 01 Jan 2008 19:07:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:date:to:cc:subject:message-id:mail-followup-to:references:mime-version:content-type:content-disposition:content-transfer-encoding:in-reply-to:user-agent:organization:x-operation-sytem:from; bh=I9iTXpKPoCvbL8sc1t5g0mC/daVOusGhd5NxAn7tRLs=; b=sWWzYMxn8z1erc1dPhRBeB6GF/C+7NA8ZZFrxQmeE4Lz+KjBhfwQXkgxRsMDAkknZmgi3bYyCp0e4Fj4Ia2QHcC2pBHMZ4EPfwFT9ogP9pMtyJKF178wafN+Uj4rHzTF3dOY6VQkSpuWl1TIy9coNCrtj9q2p2XhxsfT5kBnSfw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:to:cc:subject:message-id:mail-followup-to:references:mime-version:content-type:content-disposition:content-transfer-encoding:in-reply-to:user-agent:organization:x-operation-sytem:from; b=u78KBAHaB6LPnxbd0wg5URy72T/VTMrUAgE5tCf69pPgcSTIgSngtXCUAX2KK6qJB1Lu5HfFhgjHwt3I2Kt3cyVewwd6bPmckNZ0L/AEzIBEY08jnzdGQLY/5alwYBqFH1xWd5YiBHJAnSty1GO9C1fDFKRB4/UhfDYRFB+8bdU= Received: by 10.114.199.1 with SMTP id w1mr12849388waf.38.1199241524058; Tue, 01 Jan 2008 18:38:44 -0800 (PST) Received: from freebsd.weongyo.org ( [211.53.35.67]) by mx.google.com with ESMTPS id y11sm22234796pod.9.2008.01.01.18.38.41 (version=SSLv3 cipher=OTHER); Tue, 01 Jan 2008 18:38:43 -0800 (PST) Received: by freebsd.weongyo.org (sSMTP sendmail emulation); Wed, 2 Jan 2008 11:38:32 +0900 Date: Wed, 2 Jan 2008 11:38:31 +0900 To: Sepherosa Ziehau Message-ID: <20080102023831.GA53242@freebsd.weongyo.org> Mail-Followup-To: Sepherosa Ziehau , Dag-Erling =?UTF8?Q?Sm=F8rgrav?= , kevlo@freebsd.org, sam@freebsd.org, current@freebsd.org, net@freebsd.org References: <86ir2hznnd.fsf@ds4.des.no> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.3i Organization: CDNetworks. X-Operation-Sytem: FreeBSD From: Weongyo Jeong Cc: Dag-Erling =?UTF8?Q?Sm=F8rgrav?= , sam@freebsd.org, net@freebsd.org, current@freebsd.org, kevlo@freebsd.org Subject: Re: if_ral regression X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2008 03:07:38 -0000 On Tue, Jan 01, 2008 at 02:27:47PM +0800, Sepherosa Ziehau wrote: > On Dec 29, 2007 8:33 PM, Dag-Erling Smørgrav wrote: > > I upgraded my router cum firewall cum access point (soekris net4801 with > > a cheap third-party ralink-based wlan adapter) from RELENG_6 to HEAD and > > noticed what seems to be a regression in if_ral. After a certain amount > > of use (i.e. actually having a client connected to it and transferring > > data), the connection falters, and eventually the client can no longer > > see even see the access point in a scan. Restarting the interface on > > the router (/etc/rc.d/netif restart ral0) fixes it. I now have a cron > > job that does this every five minutes. I still get occasional outages, > > but all I have to do is wait a few minutes for the cron job to kick in. > > > > Outages are clearly related to traffic; a sure-fire way to trigger one > > is to start a backup job on my laptop (rsync to my file server). I will > > lose the wlan connection repeatedly until I either stop trying or run > > the script with a bandwidth limit. > > > > des@soe ~% uname -a > > FreeBSD soe.des.no 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Sat Dec 15 20:46:29 UTC 2007 des@pwd.des.no:/usr/obj/usr/src/sys/soe i386 > > des@soe ~% kldstat -v > > Id Refs Address Size Name > > 1 18 0xc0400000 33fdfc kernel (/boot/soe/kernel) > > 2 1 0xc0740000 7690 if_sis.ko (/boot/soe/if_sis.ko) > > 3 2 0xc0748000 1dbe0 miibus.ko (/boot/soe/miibus.ko) > > 4 1 0xc0766000 18e28 if_ral.ko (/boot/soe/if_ral.ko) > > 5 4 0xc077f000 2a95c wlan.ko (/boot/soe/wlan.ko) > > 6 1 0xc07aa000 2cb0 wlan_acl.ko (/boot/soe/wlan_acl.ko) > > 7 1 0xc07ad000 1924 wlan_scan_ap.ko (/boot/soe/wlan_scan_ap.ko) > > 8 1 0xc107f000 6000 geom_md.ko (/boot/soe/geom_md.ko) > > 9 1 0xc10f9000 2000 pflog.ko (/boot/soe/pflog.ko) > > 10 1 0xc10fb000 2f000 pf.ko (/boot/soe/pf.ko) > > 11 4 0xc118d000 a000 netgraph.ko (/boot/soe/netgraph.ko) > > 12 1 0xc119c000 3000 ng_ether.ko (/boot/soe/ng_ether.ko) > > 13 1 0xc11a8000 5000 ng_pppoe.ko (/boot/soe/ng_pppoe.ko) > > 14 1 0xc11ad000 4000 ng_socket.ko (/boot/soe/ng_socket.ko) > > des@soe ~% grep ral0 /var/run/dmesg.boot > > ral0: mem 0xa0004000-0xa0005fff irq 11 at device 10.0 on pci0 > > I don't whether following thingies will fix your problem: > > 1) > rt2560.c: rt2560_setup_tx_desc() > Set RT2560_{TX,TX_CIPHER}_BUSY desc flag at the end of this function, > instead of at the beginning of this function. The original way _may_ > confuse hardware encryption/tx engine. > > 2) > And the rt2560_bbp_read() is not correct, it should look like following: > static uint8_t > rt2560_bbp_read(struct rt2560_softc *sc, uint8_t reg) > { > uint32_t val; > int ntries; > > for (ntries = 0; ntries < 100; ntries++) { > if (!(RAL_READ(sc, RT2560_BBPCSR) & RT2560_BBP_BUSY)) > break; > DELAY(1); > } > if (ntries == 100) { > device_printf(sc->sc_dev, "could not read from BBP\n"); > return 0; > } > > val = RT2560_BBP_BUSY | reg << 8; > RAL_WRITE(sc, RT2560_BBPCSR, val); > > for (ntries = 0; ntries < 100; ntries++) { > val = RAL_READ(sc, RT2560_BBPCSR); > if (!(val & RT2560_BBP_BUSY)) > return val & 0xff; > DELAY(1); > } > > device_printf(sc->sc_dev, "could not read from BBP\n"); > return 0; > } > > 3) > After above fix, > rt2560_set_txantenna() and rt2560_set_rxantenna() should be called > after rt2560_bbp_init(), since above two function touch BBP. NOTE: > without above fix, you may burn your card. > > Even with these in place in dfly, I still have strange TX performance > regression in sta mode (drop from 20Mb/s to 3Mb/s under very well > condition) on certain hardwares after 20sec~30sec TCP_STREAM netperf > testing; didn't have enough time to dig, however, all of the tested > hardwares stayed connected during testing (I usually run netperf > stream test for 12 hours or more). I also saw some regression in TX performance during porting malo(4). Problems were fixed after removing following lines in *_start: /* * Cancel any background scan. */ if (ic->ic_flags & IEEE80211_F_SCAN) ieee80211_cancel_scan(ic); and (optionally) if (m->m_flags & M_TXCB) ... ieee80211_process_callback(ni, m, 0); /* XXX status? ... I tested in malo(4) only not in other devices so I can't sure that this would fix regression but it worked well after patching. However, I know that this workaround isn't a fundamental sulution to fix this problem. regards, Weongyo Jeong From owner-freebsd-current@FreeBSD.ORG Wed Jan 2 03:42:11 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9DA5B16A420 for ; Wed, 2 Jan 2008 03:42:11 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.181]) by mx1.freebsd.org (Postfix) with ESMTP id 3865113C459 for ; Wed, 2 Jan 2008 03:42:11 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so9195429waf.3 for ; Tue, 01 Jan 2008 19:42:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from:to:subject:message-id:reply-to:mime-version:content-type:content-disposition:user-agent; bh=oiBk4uAURGwIn5pzTVM/l13aWtClpgm/0AGDhi4mApM=; b=cRtn9gouW7p2TB8ko/ozQoCj2PcRJc80142kZFWwWdGeM7mOoamFX1B8CRDiaDrfxn9DPTqC8Lgn//fFnepRVMKW4naFHBRSdn7LOl0KQQTcLj9dUj7LkTD2aw9lzTiAx/Rkmt2bZ9Z3fPMg4ipnuhsReY+2T49DhHyBdmmEK/k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:subject:message-id:reply-to:mime-version:content-type:content-disposition:user-agent; b=oJU30GUk9bjetMxnYvTglIR6tcN+SjDBWo4j+w3Y9dTPOXRavr4gjXCRW5bfqRldeSw0WkXfZNcAmMHTxbl4AxLWEXrr6rB8r2oMYruX7PYsrRdkH3fUJSkYw/NgpeExNqNEH1lHK5ZeOdjrnabvZrPL2dZdnQDOxxLsxMxPxXc= Received: by 10.114.156.1 with SMTP id d1mr5885647wae.120.1199245330929; Tue, 01 Jan 2008 19:42:10 -0800 (PST) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTPS id j21sm5753122wah.8.2008.01.01.19.42.05 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 01 Jan 2008 19:42:09 -0800 (PST) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id m023ddDP028339 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 2 Jan 2008 12:39:39 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id m023ddb1028338 for freebsd-current@freebsd.org; Wed, 2 Jan 2008 12:39:39 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Wed, 2 Jan 2008 12:39:39 +0900 From: Pyun YongHyeon To: freebsd-current@freebsd.org Message-ID: <20080102033939.GB27551@cdnetworks.co.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: CFT: sf(4) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2008 03:42:11 -0000 Hi, I had been using the following overhauled sf(4) for serveral months without issues. It would be really great sf(4) users can test the driver and report back how it works on his/her box. Basically the driver does the following thing. - bus_dma(9) conversion and endianness support : Now sf(4) should work on all architectures that FreeBSD runs. - Performance optimization : switch to type 2 Tx descriptor and removed lots of PCI register access. Rx alignment fixup is only called on strict-alignment architectures so i386/amd64 would get instant Rx performance boost. - AIC-6915 supports Rx/Tx checksum offload as well as hardware VLAN tag insertion/stripping if firmware is loaded into frame processor. Unfortunately the firmware is not available under BSD license so these additional hardware accelerations are not available yet on FreeBSD. :-( - Code cleanup & misc bug fixes. You can find the latest sf(4) code at the following URL. http://people.freebsd.org/~yongari/sf/if_sf.c http://people.freebsd.org/~yongari/sf/if_sfreg.h Thanks. -- Regards, Pyun YongHyeon From owner-freebsd-current@FreeBSD.ORG Wed Jan 2 03:54:51 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 70B0D16A417 for ; Wed, 2 Jan 2008 03:54:51 +0000 (UTC) (envelope-from bofh@terranova.net) Received: from tog.net (tog.net [216.89.226.5]) by mx1.freebsd.org (Postfix) with ESMTP id 4C94A13C448 for ; Wed, 2 Jan 2008 03:54:51 +0000 (UTC) (envelope-from bofh@terranova.net) Received: from [216.89.228.170] (host-216-89-228-170.wireless.terranova.net [216.89.228.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tog.net (Postfix) with ESMTP id 90AA329B61C for ; Tue, 1 Jan 2008 22:54:50 -0500 (EST) Message-ID: <477B0B07.8080703@terranova.net> Date: Tue, 01 Jan 2008 22:54:47 -0500 From: Travis Mikalson Organization: TerraNovaNet Internet Services User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <1497D115-2534-4799-9D8E-18A267DF0B62@mipster.net> <9A374150-DC2A-439D-A205-E8867B663C5A@mipster.net> In-Reply-To: <9A374150-DC2A-439D-A205-E8867B663C5A@mipster.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: ServerWorks/Broadcom HT1000 chipset errata saga X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2008 03:54:51 -0000 Nick Pope wrote: > Installed the patch, now it thinks my Marvel SATA controller is an rr232x!! > > If I comment out rr232x driver in the kernel config, the Marvel is > detected no problem. However, as soon as I mount my zpool (using the > Marvel controller) the Ierrs start up again. > > -Nick > On Dec 30, 2007, at 11:52 PM, > wrote: > >> BTW, I've had PCI-X problems with a Marvel MV88SX6081 SATA controller >> on a M/B WITHOUT the HT1000 chipset (Tyan S2881UG2NR). The M/B worked >> flawlessly under 7.0-BETA1 & BETA2. I added the Marvell controller >> and EVERYTHING on the PCI-X bus flaked out. I'm seeing Ierrs and >> Oerrs (netstat -i) on the built-in bge interfaces, ZFS checksum errors >> on disks attached to the Marvel controller, etc. >> >> I wasn't sure from reading the thread whether Soren thought the >> problem went beyond the HT1000 chipset or not. The problem seems to >> manifest itself only when I use the disks attached to the Marvel >> controller. I'm applying the patch now to see if it fixes the problem. >> >> -Nick Thanks for trying it out. I just waved this in front of Søren. The apparently new mis-detection issue is certainly something to be concerned about. You're absolutely sure it was detected as a Marvell reliably (with rr232x still in there) before you applied that patch? The fact that the patch didn't do anything to solve your Marvell controller problem is too bad, also, but the mis-detection issue is of more immediate concern since this HT1000/Marvell-fixing code is being vetted for inclusion in 7.0-R. Have you tried that hardware combination with any other OSes to see if it's a FreeBSD-specific issue and not just a hardware-level issue? I haven't had a chance to confirm myself since my box with the Marvell controller in it is a long drive away from me, but Søren did get his PCI-X 8-port Marvell working perfectly fine after making these fixes. -- TerraNovaNet Internet Services - Key Largo, FL Voice: (305)453-4011 x101 Fax: (305)451-5991 http://www.terranova.net/ ---------------------------------------------- Life's not fair, but the root password helps. From owner-freebsd-current@FreeBSD.ORG Wed Jan 2 04:27:30 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BDD9D16A418 for ; Wed, 2 Jan 2008 04:27:30 +0000 (UTC) (envelope-from silby@silby.com) Received: from relay02.pair.com (relay02.pair.com [209.68.5.16]) by mx1.freebsd.org (Postfix) with SMTP id 56D3813C43E for ; Wed, 2 Jan 2008 04:27:30 +0000 (UTC) (envelope-from silby@silby.com) Received: (qmail 89302 invoked from network); 2 Jan 2008 04:27:29 -0000 Received: from unknown (HELO localhost) (unknown) by unknown with SMTP; 2 Jan 2008 04:27:29 -0000 X-pair-Authenticated: 209.68.2.70 Date: Tue, 1 Jan 2008 22:27:28 -0600 (CST) From: Mike Silbersack To: "Bruce M. Simpson" In-Reply-To: <477A627A.8010601@FreeBSD.org> Message-ID: <20080101222654.A8764@odysseus.silby.com> References: <20071228015651.X1565@odysseus.silby.com> <20071228095539.F45653@fledge.watson.org> <20071229180004.O6052@odysseus.silby.com> <477A627A.8010601@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Robert Watson , current@freebsd.org Subject: Re: [patch] Auto-setting hz to 100 inside QEMU/VMWare X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2008 04:27:30 -0000 On Tue, 1 Jan 2008, Bruce M. Simpson wrote: > This is really cool. If it works (it looks OK) please do commit it. > > Cheers > BMS It looks like we're going to go with an alternate implementation that resides in the loader instead. The effect will be the same, and it should be committed within a few days. Mike "Silby" Silbersack From owner-freebsd-current@FreeBSD.ORG Wed Jan 2 04:56:17 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7F00616A418; Wed, 2 Jan 2008 04:56:17 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from webaccess-cl.virtdom.com (webaccess-cl.virtdom.com [216.240.101.25]) by mx1.freebsd.org (Postfix) with ESMTP id 30E1913C442; Wed, 2 Jan 2008 04:56:17 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from [192.168.1.107] (cpe-24-94-75-93.hawaii.res.rr.com [24.94.75.93]) (authenticated bits=0) by webaccess-cl.virtdom.com (8.13.6/8.13.6) with ESMTP id m024thIF072050; Tue, 1 Jan 2008 23:55:44 -0500 (EST) (envelope-from jroberson@chesapeake.net) Date: Tue, 1 Jan 2008 18:56:59 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: Kris Kennaway In-Reply-To: <4743342A.10507@FreeBSD.org> Message-ID: <20080101185451.S957@desktop> References: <20071120141403.GE81260@comp.chem.msu.su> <4743342A.10507@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Yar Tikhiy , freebsd-current@FreeBSD.org Subject: Re: SCHED_ULE & niceness / rtprio X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2008 04:56:17 -0000 On Tue, 20 Nov 2007, Kris Kennaway wrote: > Yar Tikhiy wrote: >> Hi all, >> >> SCHED_ULE seems to do an unfair job to processes with low niceness >> or with real-time priority. Here are my observations: >> >> A few days ago I noticed that music (played by Totem, Gnome's default >> player) would pause for a fraction of second each time I did something >> in X/Gnome, such as switched between windows, clicked on a link in >> the web browser, etc. Then I found that music was jerky only if >> the player ran with a negative niceness or a real-time priority: >> As soon as I returned it to niceness 0 and normal priority, sound >> became totally seamless notwithstanding my activity in X. >> >> The approximate value required for the effect to appear was niceness >> as low as -5 or RT priority as high as 10; niceness -1 or rtprio 1 >> wasn't enough. >> >> Curious, I substituted SCHED_4BSD for SCHED_ULE in my otherwise >> GENERIC kernel, and the jerkiness of sound was gone irrespective >> of the niceness or RT priority of the player. >> >> To rule out other possible causes, I also tried kernels with SCHED_ULE >> but without SMP or without debug stuff (INVARIANTS+WITNESS), but >> the issue was there in both cases, unlike in the case of SCHED_4BSD. >> >> Of course, X+Gnome+stuff isn't the clearest environment for debugging >> schedulers, but multimedia apps are rather sensitive to scheduling >> quality. This case should be rather obvious: When I click in an >> inactive window, some processes are woken that have been idle. >> After that the high-priority player isn't scheduled long enough for >> the hardware audo buffer to drain, although it would be scheduled >> soon if it had normal priority. >> >> Did I hit a known issue? > > Others have reported it, but I don't know if Jeff has had time to investigate > yet. > I tried to reproduce this recently by running mplayer with various nice values while scrolling around a lot in firefox. This is on a 1.4ghz machine. I didn't encounter any problems. If anyone is having nice related problems with ULE I'd love a simple test case that shows it. I tried installing boinc which was mentioned in other threads but had trouble contacting the servers and getting it setup. Something simpler would be very beneficial. Thanks, Jeff > Kris > From owner-freebsd-current@FreeBSD.ORG Wed Jan 2 05:08:41 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 68E3A16A418 for ; Wed, 2 Jan 2008 05:08:41 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from webaccess-cl.virtdom.com (webaccess-cl.virtdom.com [216.240.101.25]) by mx1.freebsd.org (Postfix) with ESMTP id 2523413C43E for ; Wed, 2 Jan 2008 05:08:41 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from [192.168.1.107] (cpe-24-94-75-93.hawaii.res.rr.com [24.94.75.93]) (authenticated bits=0) by webaccess-cl.virtdom.com (8.13.6/8.13.6) with ESMTP id m0258cKr073117; Wed, 2 Jan 2008 00:08:39 -0500 (EST) (envelope-from jroberson@chesapeake.net) Date: Tue, 1 Jan 2008 19:09:54 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: Rene Ladan In-Reply-To: <476F81AF.7000505@gmail.com> Message-ID: <20080101190607.B957@desktop> References: <20071223092332.GJ25002@server.vk2pj.dyndns.org> <476F81AF.7000505@gmail.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="2547152148-680891004-1199250594=:957" Cc: Peter Jeremy , freebsd-current@freebsd.org Subject: Re: idle priority scheduling broken in 7.0-BETA4 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2008 05:08:41 -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. --2547152148-680891004-1199250594=:957 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed On Mon, 24 Dec 2007, Rene Ladan wrote: > Peter Jeremy schreef: >> In August, I reported that idprio was not working in -current. >> Successive upgrades to 7.0-BETA2 and 7.0-BETA4, as well as switching >> to ULE have not resolved the problem. >> >> The problem affects both boinc-einsteinathome and boinc-setiathome and >> causes them to report "No heartbeat from core client for 31 sec - >> exiting" and get repeatedly restarted. The boinc compute modules >> (einstein@home, seti@home etc) use a SysV SHM segment to exchange >> heartbeats with the boinc core client. The problem is that the core >> client is not being scheduled whilst the compute module is running, >> causing them to die. >> >> Previously, multiple idprio tasks were round-robined but it seems that >> something has been changed and it appears that the last scheduled task >> is now re-scheduled. >> >> Has anyone else seen this behaviour? >> > On my CURRENT 2007-12-23 dualcore (Intel T5600) i386 I get similar behaviour > when using the ULE scheduler. With the 4BSD scheduler priorities are sometimes > wrong, but boinc tasks (einstein,seti,simap) run continuously until preempted, > they are kept in memory. > > last pid: 8141; load averages: 2.03, 2.14, 2.18 up 0+20:48:27 10:51:54 > 146 processes: 7 running, 120 sleeping, 19 waiting > CPU states: % user, % nice, % system, % interrupt, % idle > Mem: 373M Active, 1040M Inact, 223M Wired, 17M Cache, 112M Buf, 349M Free > Swap: 4062M Total, 4062M Free > > PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND > 7315 boinc 171 i31 65960K 64904K CPU1 1 187:57 62.89% {einstein_S5R3_4. > 7859 boinc 171 i31 13680K 12552K RUN 0 71:31 60.16% {simap_5.10_i686- > 7859 boinc 20 i31 13680K 12552K kserel 0 71:31 10.45% {simap_5.10_i686- > 5168 boinc 8 i31 41960K 37564K nanslp 0 205:14 0.00% {initial thread} > 5168 boinc 8 19 41960K 37564K nanslp 0 205:14 0.00% {setiathome-5.27. > 7315 boinc 20 i31 65960K 64904K ksesig 0 187:57 0.00% {einstein_S5R3_4. > 7315 boinc 20 i31 65960K 64904K kserel 0 187:57 0.00% {einstein_S5R3_4. > 7859 boinc 20 i31 13680K 12552K ksesig 0 71:31 0.00% {simap_5.10_i686- > 22403 boinc 171 i31 9572K 6700K select 1 0:32 0.00% boinc_client Can you please try this experimental patch for ULE? It re-enables the time slicing code for idle prio and realtime tasks that are not fifo. Thanks, Jeff > > > Rene > -- > GPG fingerprint = E738 5471 D185 7013 0EE0 4FC8 3C1D 6F83 12E1 84F6 (subkeys.pgp.net) > > "It won't fit on the line." > -- me, 2001 > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > --2547152148-680891004-1199250594=:957 Content-Type: TEXT/x-diff; charset=US-ASCII; name=uleidle.diff Content-Transfer-Encoding: BASE64 Content-ID: <20080101190954.K957@desktop> Content-Description: Content-Disposition: attachment; filename=uleidle.diff SW5kZXg6IHNjaGVkX3VsZS5jDQo9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpS Q1MgZmlsZTogL2hvbWUvbmN2cy9zcmMvc3lzL2tlcm4vc2NoZWRfdWxlLmMs dg0KcmV0cmlldmluZyByZXZpc2lvbiAxLjIyMA0KZGlmZiAtdSAtcjEuMjIw IHNjaGVkX3VsZS5jDQotLS0gc2NoZWRfdWxlLmMJMjEgRGVjIDIwMDcgMjM6 MzA6MTggLTAwMDAJMS4yMjANCisrKyBzY2hlZF91bGUuYwkyIEphbiAyMDA4 IDA1OjA5OjMzIC0wMDAwDQpAQCAtMjE4NiwxNyArMjE4NiwxNiBAQA0KIAkJ CXRkcS0+dGRxX3JpZHggPSB0ZHEtPnRkcV9pZHg7DQogCX0NCiAJdHMgPSB0 ZC0+dGRfc2NoZWQ7DQotCS8qDQotCSAqIFdlIG9ubHkgZG8gc2xpY2luZyBj b2RlIGZvciBUSU1FU0hBUkUgdGhyZWFkcy4NCi0JICovDQotCWlmICh0ZC0+ dGRfcHJpX2NsYXNzICE9IFBSSV9USU1FU0hBUkUpDQorCWlmICh0ZC0+dGRf cHJpX2NsYXNzICYgUFJJX0ZJRk8pDQogCQlyZXR1cm47DQotCS8qDQotCSAq IFdlIHVzZWQgYSB0aWNrOyBjaGFyZ2UgaXQgdG8gdGhlIHRocmVhZCBzbyB0 aGF0IHdlIGNhbiBjb21wdXRlIG91cg0KLQkgKiBpbnRlcmFjdGl2aXR5Lg0K LQkgKi8NCi0JdGQtPnRkX3NjaGVkLT50c19ydW50aW1lICs9IHRpY2tpbmNy Ow0KLQlzY2hlZF9pbnRlcmFjdF91cGRhdGUodGQpOw0KKwlpZiAodGQtPnRk X3ByaV9jbGFzcyA9PSBQUklfVElNRVNIQVJFKSB7DQorCQkvKg0KKwkJICog V2UgdXNlZCBhIHRpY2s7IGNoYXJnZSBpdCB0byB0aGUgdGhyZWFkIHNvDQor CQkgKiB0aGF0IHdlIGNhbiBjb21wdXRlIG91ciBpbnRlcmFjdGl2aXR5Lg0K KwkJICovDQorCQl0ZC0+dGRfc2NoZWQtPnRzX3J1bnRpbWUgKz0gdGlja2lu Y3I7DQorCQlzY2hlZF9pbnRlcmFjdF91cGRhdGUodGQpOw0KKwl9DQogCS8q DQogCSAqIFdlIHVzZWQgdXAgb25lIHRpbWUgc2xpY2UuDQogCSAqLw0K --2547152148-680891004-1199250594=:957-- From owner-freebsd-current@FreeBSD.ORG Wed Jan 2 07:31:48 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7494F16A417 for ; Wed, 2 Jan 2008 07:31:48 +0000 (UTC) (envelope-from silby@silby.com) Received: from relay02.pair.com (relay02.pair.com [209.68.5.16]) by mx1.freebsd.org (Postfix) with SMTP id 2769313C442 for ; Wed, 2 Jan 2008 07:31:47 +0000 (UTC) (envelope-from silby@silby.com) Received: (qmail 20800 invoked from network); 2 Jan 2008 07:31:46 -0000 Received: from unknown (HELO localhost) (unknown) by unknown with SMTP; 2 Jan 2008 07:31:46 -0000 X-pair-Authenticated: 209.68.2.70 Date: Wed, 2 Jan 2008 01:31:45 -0600 (CST) From: Mike Silbersack To: current@freebsd.org In-Reply-To: <20071224020713.F1390@odysseus.silby.com> Message-ID: <20080102004324.U9178@odysseus.silby.com> References: <20071224020713.F1390@odysseus.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Subject: Update: Repeated or missed keys after upgrading from 6.2 to 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2008 07:31:48 -0000 On Mon, 24 Dec 2007, Mike Silbersack wrote: > In order to eat my own dog food, I upgraded my laptop from 6.2 to 7.0. This > seemed to have gone well, until I started writing a long e-mail while sitting > on the couch today. As I was typing the e-mail, I noticed that my typing > skills seemed to have gone missing; there were words missing 2-3 letters, and > other places where I was apparently holding down keyyyys. Heh, that's a real > example of the phenomenon right there. > > After a while I realized that I was not typing sloppily, but that in fact > keys are being lost in certain cases and duplicated in others. Since I did > not rebuild any ports or packages, I'm convinced that this is directly > related to the 7.0 upgrade. > > This behavior has shown up when running a local copy of pine (inside > konsole), chatting in ksirc, and in a few other programs. (I'm running KDE.) > I think it happens more when on battery than when plugged into an outlet. > I'm running xbattbar, so it could be querying the battery status and causing > problems. This is using the laptop's built-in keyboard (non-USB.) > > I'm going to try to track this down, although I don't know how successful > I'll be. I'd like to know if anyone else has seen this problem and if they > have any additional information that might help me track it down faster. > > Thanks, > > Mike "Silby" Silbersack Thanks to everyone who responded to this thread. Here's what I've learned since my initial message: 1. Other people have seen this problem (or something similar) as far back as 5.x. 1a. I noticed in my kernel config file that I did NOT have kdbmux in my 6.2 kernel config file, but I do have it in my 7.0 kernel config file. However, I also tried recompiling 7.0 without kbdmux, and the problem still occurs. 2. The problem only happens when I have xbattbar running. Whether or not I'm actually running on battery makes no difference. 3. Ssh sessions into the box do not appear to be affected. 4. If I plug in a USB keyboard, it does not seem to be affected. (Either with or without kbdmux.) I've added some KTR debugging statements to try to help me track this down, but I have not yet made much progress. Mike "Silby" Silbersack From owner-freebsd-current@FreeBSD.ORG Wed Jan 2 10:16:54 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3552C16A418 for ; Wed, 2 Jan 2008 10:16:54 +0000 (UTC) (envelope-from Benjamin.Close@clearchain.com) Received: from ipmail05.adl2.internode.on.net (ipmail05.adl2.internode.on.net [203.16.214.145]) by mx1.freebsd.org (Postfix) with ESMTP id B70A213C45B for ; Wed, 2 Jan 2008 10:16:53 +0000 (UTC) (envelope-from Benjamin.Close@clearchain.com) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq4HAMfxekd5LUVm/2dsb2JhbACBV6UA X-IronPort-AV: E=Sophos;i="4.24,233,1196602200"; d="scan'208";a="28058164" Received: from ppp121-45-69-102.lns10.adl6.internode.on.net (HELO mail.clearchain.com) ([121.45.69.102]) by ipmail05.adl2.internode.on.net with ESMTP; 02 Jan 2008 20:46:51 +1030 Received: from [192.168.155.249] (draco.internal.clearchain.com [192.168.155.249]) (authenticated bits=0) by mail.clearchain.com (8.13.8/8.13.8) with ESMTP id m02AGmeO031172 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Jan 2008 20:46:49 +1030 (CST) (envelope-from Benjamin.Close@clearchain.com) Message-ID: <477B648D.2080303@clearchain.com> Date: Wed, 02 Jan 2008 20:46:45 +1030 From: Benjamin Close User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Mike Silbersack References: <20071224020713.F1390@odysseus.silby.com> <20080102004324.U9178@odysseus.silby.com> In-Reply-To: <20080102004324.U9178@odysseus.silby.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.92, clamav-milter version 0.92 on pegasus.clearchain.com X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (mail.clearchain.com [192.168.154.1]); Wed, 02 Jan 2008 20:46:49 +1030 (CST) Cc: current@freebsd.org Subject: Re: Update: Repeated or missed keys after upgrading from 6.2 to 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2008 10:16:54 -0000 Mike Silbersack wrote: > > On Mon, 24 Dec 2007, Mike Silbersack wrote: > >> In order to eat my own dog food, I upgraded my laptop from 6.2 to >> 7.0. This seemed to have gone well, until I started writing a long >> e-mail while sitting on the couch today. As I was typing the e-mail, >> I noticed that my typing skills seemed to have gone missing; there >> were words missing 2-3 letters, and other places where I was >> apparently holding down keyyyys. Heh, that's a real example of the >> phenomenon right there. >> >> After a while I realized that I was not typing sloppily, but that in >> fact keys are being lost in certain cases and duplicated in others. >> Since I did not rebuild any ports or packages, I'm convinced that >> this is directly related to the 7.0 upgrade. >> >> This behavior has shown up when running a local copy of pine (inside >> konsole), chatting in ksirc, and in a few other programs. (I'm >> running KDE.) I think it happens more when on battery than when >> plugged into an outlet. I'm running xbattbar, so it could be querying >> the battery status and causing problems. This is using the laptop's >> built-in keyboard (non-USB.) >> >> I'm going to try to track this down, although I don't know how >> successful I'll be. I'd like to know if anyone else has seen this >> problem and if they have any additional information that might help >> me track it down faster. >> >> Thanks, >> >> Mike "Silby" Silbersack > > Thanks to everyone who responded to this thread. Here's what I've > learned since my initial message: > > 1. Other people have seen this problem (or something similar) as far > back as 5.x. > > 1a. I noticed in my kernel config file that I did NOT have kdbmux in > my 6.2 kernel config file, but I do have it in my 7.0 kernel config > file. However, I also tried recompiling 7.0 without kbdmux, and the > problem still occurs. > > 2. The problem only happens when I have xbattbar running. Whether or > not I'm actually running on battery makes no difference. > > 3. Ssh sessions into the box do not appear to be affected. > > 4. If I plug in a USB keyboard, it does not seem to be affected. > (Either with or without kbdmux.) > > I've added some KTR debugging statements to try to help me track this > down, but I have not yet made much progress. > Mike, Does this only happen under X? If so it may not be kernel related at all. Until recently Xorg had a bug: http://bugs.freedesktop.org/show_bug.cgi?id=12610 Cheers, Benjamin From owner-freebsd-current@FreeBSD.ORG Wed Jan 2 10:51:02 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7238A16A41A for ; Wed, 2 Jan 2008 10:51:02 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail12.syd.optusnet.com.au (mail12.syd.optusnet.com.au [211.29.132.193]) by mx1.freebsd.org (Postfix) with ESMTP id 09B7413C45D for ; Wed, 2 Jan 2008 10:51:01 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from server.vk2pj.dyndns.org (c220-239-20-82.belrs4.nsw.optusnet.com.au [220.239.20.82]) by mail12.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m02Aoom1019020 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Jan 2008 21:50:51 +1100 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.2/8.14.1) with ESMTP id m02AooxZ000950; Wed, 2 Jan 2008 21:50:50 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.2/8.14.2/Submit) id m02Aon8i000949; Wed, 2 Jan 2008 21:50:49 +1100 (EST) (envelope-from peter) Date: Wed, 2 Jan 2008 21:50:49 +1100 From: Peter Jeremy To: Jeff Roberson Message-ID: <20080102105049.GA903@server.vk2pj.dyndns.org> References: <20071223092332.GJ25002@server.vk2pj.dyndns.org> <476F81AF.7000505@gmail.com> <20080101190607.B957@desktop> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="uAKRQypu60I7Lcqm" Content-Disposition: inline In-Reply-To: <20080101190607.B957@desktop> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-current@freebsd.org Subject: Re: idle priority scheduling broken in 7.0-BETA4 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2008 10:51:02 -0000 --uAKRQypu60I7Lcqm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 01, 2008 at 07:09:54PM -1000, Jeff Roberson wrote: >Can you please try this experimental patch for ULE? It re-enables the tim= e=20 >slicing code for idle prio and realtime tasks that are not fifo. I still had boinc running at "nice -n 19" and the system wouldn't boot: It started boinc, reported it was checking the apache.conf and didn't go any further. I couldn't kill boinc or setiathome from ddb and had to push the reset button. I will look at the patch more closely tomorrow but it looks suspiciously like it stopped time-slicing. --=20 Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. --uAKRQypu60I7Lcqm Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHe2yJ/opHv/APuIcRAodxAJ4mXG5UBI6ebWmIW+fin/SM5sd2VgCdH218 rFHaZEp0WoDH/jQGO/ND/wA= =+GKn -----END PGP SIGNATURE----- --uAKRQypu60I7Lcqm-- From owner-freebsd-current@FreeBSD.ORG Wed Jan 2 11:01:49 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7FCC216A46B for ; Wed, 2 Jan 2008 11:01:49 +0000 (UTC) (envelope-from silby@silby.com) Received: from relay01.pair.com (relay01.pair.com [209.68.5.15]) by mx1.freebsd.org (Postfix) with SMTP id 1DBF813C457 for ; Wed, 2 Jan 2008 11:01:48 +0000 (UTC) (envelope-from silby@silby.com) Received: (qmail 18008 invoked from network); 2 Jan 2008 11:01:47 -0000 Received: from unknown (HELO localhost) (unknown) by unknown with SMTP; 2 Jan 2008 11:01:47 -0000 X-pair-Authenticated: 209.68.2.70 Date: Wed, 2 Jan 2008 05:01:46 -0600 (CST) From: Mike Silbersack To: Benjamin Close In-Reply-To: <477B648D.2080303@clearchain.com> Message-ID: <20080102050136.J1392@odysseus.silby.com> References: <20071224020713.F1390@odysseus.silby.com> <20080102004324.U9178@odysseus.silby.com> <477B648D.2080303@clearchain.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: current@freebsd.org Subject: Re: Update: Repeated or missed keys after upgrading from 6.2 to 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2008 11:01:49 -0000 On Wed, 2 Jan 2008, Benjamin Close wrote: > Mike, > Does this only happen under X? > If so it may not be kernel related at all. Until recently Xorg had a bug: > > http://bugs.freedesktop.org/show_bug.cgi?id=12610 > > Cheers, > Benjamin Good question. I exited X and opened vi at the console. Then I used X11 forwarding from another machine to run xbattbar. The keystroke loss still occured in vi running on the console. So, I don't think it's X's fault in my case. Mike "Silby" Silbersack From owner-freebsd-current@FreeBSD.ORG Wed Jan 2 10:58:19 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 252EB16A41A for ; Wed, 2 Jan 2008 10:58:19 +0000 (UTC) (envelope-from horus.li@gmail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.185]) by mx1.freebsd.org (Postfix) with ESMTP id 6C2D813C469 for ; Wed, 2 Jan 2008 10:58:18 +0000 (UTC) (envelope-from horus.li@gmail.com) Received: by rv-out-0910.google.com with SMTP id l15so5682965rvb.43 for ; Wed, 02 Jan 2008 02:58:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=h1SsBGRie3LZERVHS8bfASWBWFz0z6LVqr2AnTXTPcA=; b=kZcTb2Cb5XS5gHLVrCwMVR9ulrmYpWAfe6Mz8KRfEPf22tC8UPaMXvijxV3yznK3evmSg3a0XX8YjGNr2wrA23Q+f8ryN0jLgifljn5/1Pz+gQIaXnjN4Cp8HsWigIxnpyTwTMsJ7wGx8VhwYvlmnzCq2WITF2UetFXXzHpcJvw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=uvQ9sjE+qIr8I0L9q/LhnIUsZV9Ivv0UGSZq+r422RF51yg91VHCi2trVu7osGsgeyGHkNs4Y7RZ158IA9gA932R2Va8V5onF/034KdPkIInUe8md2k6aRkyGRGpkZAzDaIzO00LuAQJSy9bqGf5YodjWo75qEeb/u2/aCtxF0g= Received: by 10.141.49.6 with SMTP id b6mr3081885rvk.68.1199270000066; Wed, 02 Jan 2008 02:33:20 -0800 (PST) Received: by 10.141.70.11 with HTTP; Wed, 2 Jan 2008 02:33:20 -0800 (PST) Message-ID: Date: Wed, 2 Jan 2008 18:33:20 +0800 From: "Horus Lee" To: freebsd-current@freebsd.org MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 02 Jan 2008 12:38:42 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: make buildworld error on FreeBSD 8.0-CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2008 10:58:19 -0000 Hey all, Recently i am running a FreeBSD 8.0-CURRENT(upgraded from FreeBSD 6.2-RELEASE): # uname -a FreeBSD header......cn 8.0-CURRENT FreeBSD 8.0-CURRENT #1: Thu Dec 27 08:53:03 CST 2007 horus@header....cn:/usr/obj/usr/src/sys/HEADER i386 machine. Today, i decided to make it more up-to-date, i cvsuped the source, just type cd /usr/src ; make buildworld & Everything went smoothly at first, but suddenly an error occured: objcopy -S -O binary boot2.out boot2.bin btxld -v -E 0x2000 -f bin -b /usr/obj/usr/src/sys/boot/i386/boot2/../btx/btx/btx -l boot2.ldr -o boot2.ld -P 1 boot2.bin kernel: ver=1.01 size=7b0 load=9000 entry=9010 map=16M pgctl=1:1 client: fmt=bin size=14d5 text=0 data=0 bss=0 entry=0 output: fmt=bin size=1d99 text=114 data=1c85 org=0 entry=0 arithmetic expression: syntax error: "7680-/etc/group" *** Error code 2 Stop in /usr/src/sys/boot/i386/boot2. *** Error code 1 Stop in /usr/src/sys/boot/i386. *** Error code 1 Stop in /usr/src/sys/boot. *** Error code 1 Stop in /usr/src/sys. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. [1] Exit 1 make buildworld then i rolled back to type the following lines: chflags -R noschg /usr/obj/usr rm -rf /usr/obj/usr cd /usr/src make cleandir make cleandir started to rebuild the world, the same thing happened again. i searched the maillist and got: http://lists.freebsd.org/mailman/htdig/freebsd-current/2005-August/054376.html ...... here comes my dmesg, could some one tell me what's wrong? Copyright (c) 1992-2007 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 is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-CURRENT #1: Thu Dec 27 08:53:03 CST 2007 horus@header........cn:/usr/obj/usr/src/sys/HEADER WARNING: WITNESS option enabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) 4 CPU 1.70GHz (1703.88-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf12 Stepping = 2 Features=0x3febfbff real memory = 259981312 (247 MB) avail memory = 240447488 (229 MB) mptable_probe: MP Config Table has bad signature: \^Bp\M-p kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, f6f0000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 cpu0: on acpi0 p4tcc0: on cpu0 acpi_button0: on acpi0 acpi_button1: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: mem 0xd0000000-0xd7ffffff,0xde000000-0xde07ffff irq 11 at device 2.0 on pci0 agp0: on vgapci0 agp0: detected 8060k stolen memory agp0: aperture size is 128M uhci0: port 0xb800-0xb81f irq 11 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xb000-0xb01f irq 11 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xb400-0xb41f irq 11 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered ehci0: mem 0xde080000-0xde0803ff irq 9 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb3: EHCI version 1.0 usb3: companion controllers, 2 ports each: usb0 usb1 usb2 usb3: on ehci0 usb3: USB revision 2.0 uhub3: on usb3 uhub3: 6 ports with 6 removable, self powered pcib1: at device 30.0 on pci0 pci1: on pcib1 rl0: port 0xa000-0xa0ff mem 0xdd000000-0xdd0000ff irq 11 at device 0.0 on pci1 miibus0: on rl0 rlphy0: PHY 0 on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl0: Ethernet address: 50:78:9b:31:77:c2 rl0: [ITHREAD] isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xcc00-0xcc0f mem 0xde081000-0xde0813ff irq 11 at device 31.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] pci0: at device 31.3 (no driver attached) pci0: at device 31.5 (no driver attached) acpi_tz0: on acpi0 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FILTER] sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio0: [FILTER] sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A sio1: [FILTER] atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model Generic PS/2 mouse, device ID 0 pmtimer0 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppbus0: on ppc0 plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 ppc0: [GIANT-LOCKED] ppc0: [ITHREAD] Timecounter "TSC" frequency 1703875300 Hz quality 800 Timecounters tick every 1.000 msec ad0: DMA limited to UDMA33, controller found non-ATA66 cable ad0: 38172MB at ata0-master UDMA33 WARNING: WITNESS option enabled, expect reduced performance. Trying to mount root from ufs:/dev/ad0s1a rl0: link state changed to UP Greatly thanks...Please help me out :-) From owner-freebsd-current@FreeBSD.ORG Wed Jan 2 13:18:39 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1824516A41A for ; Wed, 2 Jan 2008 13:18:39 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.230]) by mx1.freebsd.org (Postfix) with ESMTP id C76B513C46E for ; Wed, 2 Jan 2008 13:18:38 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: by nz-out-0506.google.com with SMTP id l8so845798nzf.13 for ; Wed, 02 Jan 2008 05:18:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=p4ncwgVfJjUwvSdaY7rjdiIX/ZZlLQD51bPGlrZI4jI=; b=YV9zt34xXtro3SUOF8a2wvgV0pve5y/bFUpv0k9HauLMicg8xMqgNMgILqbwjyVSLwEdj69xLCHivbma+c2BRTvNFiBaTTv0ivoXMMBqlHAYH/ql+pi47Ioeq1sX+6dUSTtV4zO1b5xXLfvswh8hVtfxyA2o9eCyyq1GLQg/B8s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Zjqt3EhwtjsSfxhf6Y5hzmtdaV8BpKxDtpfYeAOluNwgBylCOn6COPOmKTh3a4zHi5E8c8j0yJFfFgZ5g9b85+dKH1SWfSUbUeRiaYEk1RVQmhYwjYeKNC7/huf2eHOiwS4mfAUZp1z4qgSW1CIE9edxQq2y5ZomsNh+HOwM+gM= Received: by 10.142.108.14 with SMTP id g14mr3444922wfc.52.1199279917515; Wed, 02 Jan 2008 05:18:37 -0800 (PST) Received: by 10.142.162.20 with HTTP; Wed, 2 Jan 2008 05:18:37 -0800 (PST) Message-ID: Date: Wed, 2 Jan 2008 21:18:37 +0800 From: "Sepherosa Ziehau" To: "=?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?=" In-Reply-To: <86abnpu0wv.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <86ir2hznnd.fsf@ds4.des.no> <86abnpu0wv.fsf@ds4.des.no> Cc: kevlo@freebsd.org, sam@freebsd.org, current@freebsd.org, net@freebsd.org Subject: Re: if_ral regression X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2008 13:18:39 -0000 On Jan 1, 2008 9:32 PM, Dag-Erling Sm=F8rgrav wrote: > "Sepherosa Ziehau" writes: > > I don't whether following thingies will fix your problem: > > [...] > > Can you provide a diff? http://people.freebsd.org/~sephe/rt2560_test.diff Hope it will have some effect. Best Regards, sephe --=20 Live Free or Die From owner-freebsd-current@FreeBSD.ORG Wed Jan 2 13:28:31 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EFD5216A469 for ; Wed, 2 Jan 2008 13:28:31 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.183]) by mx1.freebsd.org (Postfix) with ESMTP id 79D4613C4DD for ; Wed, 2 Jan 2008 13:28:31 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: by py-out-1112.google.com with SMTP id u52so9884412pyb.10 for ; Wed, 02 Jan 2008 05:28:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=e8HDWh4hpLn9Hz87T0deh8k4k/QK2ShmvBOwXITVZ6o=; b=Y3c3P4o+/YFT4nAgf8CvtpUOenry/WCnVamP1x9pn+/QpPjF8KTqDDkJ0GF9RatqkQTDoPzH0zSwDwQAmqZhuUgqhEP0xf+tG0eQToX6mVNnwXB+yghAVk5jJTHnH93uNauR1b4JXYT9AUqDI3P60fPbh/2ducb0673v4J2kd/4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=dXDAhD5C3KzHs1rfWLuNMXOQ9J784cg2A04P+Ch8ClcogcohziYolLMNJWo2aqd0u7DHYWir4Z6s+wmtKeWULSwesn42HReMULC67Auz5gWHnloc/zHnR2mOXiyCrhuWGQL/noJ6oMZb/C+2hd8gKGwkbCLnddjloVrAmVXHDQI= Received: by 10.142.132.2 with SMTP id f2mr3893856wfd.221.1199280510335; Wed, 02 Jan 2008 05:28:30 -0800 (PST) Received: by 10.142.162.20 with HTTP; Wed, 2 Jan 2008 05:28:30 -0800 (PST) Message-ID: Date: Wed, 2 Jan 2008 21:28:30 +0800 From: "Sepherosa Ziehau" To: "Weongyo Jeong" In-Reply-To: <20080102023831.GA53242@freebsd.weongyo.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <86ir2hznnd.fsf@ds4.des.no> <20080102023831.GA53242@freebsd.weongyo.org> Cc: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= , sam@freebsd.org, net@freebsd.org, current@freebsd.org, kevlo@freebsd.org Subject: Re: if_ral regression X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2008 13:28:32 -0000 On Jan 2, 2008 10:38 AM, Weongyo Jeong wrote: > > > Even with these in place in dfly, I still have strange TX performance > > regression in sta mode (drop from 20Mb/s to 3Mb/s under very well > > condition) on certain hardwares after 20sec~30sec TCP_STREAM netperf > > testing; didn't have enough time to dig, however, all of the tested > > hardwares stayed connected during testing (I usually run netperf > > stream test for 12 hours or more). > > I also saw some regression in TX performance during porting malo(4). Have you tried to turn bgscan off completely? My problem seems to be hardware (I suspect rf) related. The TX performance regression does not happen with UDP stream which only uses 802.11 ack, i.e. hardware seems to have touble to switch between data RX and data TX at high freq. > Problems were fixed after removing following lines in *_start: > > /* > * Cancel any background scan. > */ > if (ic->ic_flags & IEEE80211_F_SCAN) > ieee80211_cancel_scan(ic); > > and (optionally) > > if (m->m_flags & M_TXCB) > ... > ieee80211_process_callback(ni, m, 0); /* XXX status? > ... I don't think you can remove TXCB processing in drivers :) Best Regards, sephe -- Live Free or Die From owner-freebsd-current@FreeBSD.ORG Wed Jan 2 13:30:22 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0839316A468 for ; Wed, 2 Jan 2008 13:30:22 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from webaccess-cl.virtdom.com (webaccess-cl.virtdom.com [216.240.101.25]) by mx1.freebsd.org (Postfix) with ESMTP id B9C0F13C4F5 for ; Wed, 2 Jan 2008 13:30:21 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from [192.168.1.107] (cpe-24-94-75-93.hawaii.res.rr.com [24.94.75.93]) (authenticated bits=0) by webaccess-cl.virtdom.com (8.13.6/8.13.6) with ESMTP id m02DUGM3021183; Wed, 2 Jan 2008 08:30:18 -0500 (EST) (envelope-from jroberson@chesapeake.net) Date: Wed, 2 Jan 2008 03:31:34 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: Peter Jeremy In-Reply-To: <20080102105049.GA903@server.vk2pj.dyndns.org> Message-ID: <20080102033011.P957@desktop> References: <20071223092332.GJ25002@server.vk2pj.dyndns.org> <476F81AF.7000505@gmail.com> <20080101190607.B957@desktop> <20080102105049.GA903@server.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="2547152148-139958016-1199280694=:957" Cc: freebsd-current@freebsd.org Subject: Re: idle priority scheduling broken in 7.0-BETA4 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2008 13:30:22 -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. --2547152148-139958016-1199280694=:957 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed On Wed, 2 Jan 2008, Peter Jeremy wrote: > On Tue, Jan 01, 2008 at 07:09:54PM -1000, Jeff Roberson wrote: >> Can you please try this experimental patch for ULE? It re-enables the time >> slicing code for idle prio and realtime tasks that are not fifo. > > I still had boinc running at "nice -n 19" and the system wouldn't > boot: It started boinc, reported it was checking the apache.conf and > didn't go any further. I couldn't kill boinc or setiathome from ddb > and had to push the reset button. I will look at the patch more > closely tomorrow but it looks suspiciously like it stopped > time-slicing. ah, I'm sorry. the new line with PRI_FIFO should read PRI_FIFO_BIT. I tested the patch but not with any idle prio tasks that run forever. Enclosed is a new patch. Thanks, Jeff > > -- > Peter Jeremy > Please excuse any delays as the result of my ISP's inability to implement > an MTA that is either RFC2821-compliant or matches their claimed behaviour. > --2547152148-139958016-1199280694=:957 Content-Type: TEXT/x-diff; charset=US-ASCII; name=uleidle.diff Content-Transfer-Encoding: BASE64 Content-ID: <20080102033134.B957@desktop> Content-Description: Content-Disposition: attachment; filename=uleidle.diff SW5kZXg6IHNjaGVkX3VsZS5jDQo9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpS Q1MgZmlsZTogL2hvbWUvbmN2cy9zcmMvc3lzL2tlcm4vc2NoZWRfdWxlLmMs dg0KcmV0cmlldmluZyByZXZpc2lvbiAxLjIxNC4yLjINCmRpZmYgLXUgLXIx LjIxNC4yLjIgc2NoZWRfdWxlLmMNCi0tLSBzY2hlZF91bGUuYwkyMCBEZWMg MjAwNyAwNzoxNTo0MCAtMDAwMAkxLjIxNC4yLjINCisrKyBzY2hlZF91bGUu YwkyIEphbiAyMDA4IDEzOjMxOjEwIC0wMDAwDQpAQCAtMjE4MywxNyArMjE4 MywxNiBAQA0KIAkJCXRkcS0+dGRxX3JpZHggPSB0ZHEtPnRkcV9pZHg7DQog CX0NCiAJdHMgPSB0ZC0+dGRfc2NoZWQ7DQotCS8qDQotCSAqIFdlIG9ubHkg ZG8gc2xpY2luZyBjb2RlIGZvciBUSU1FU0hBUkUgdGhyZWFkcy4NCi0JICov DQotCWlmICh0ZC0+dGRfcHJpX2NsYXNzICE9IFBSSV9USU1FU0hBUkUpDQor CWlmICh0ZC0+dGRfcHJpX2NsYXNzICYgUFJJX0ZJRk9fQklUKQ0KIAkJcmV0 dXJuOw0KLQkvKg0KLQkgKiBXZSB1c2VkIGEgdGljazsgY2hhcmdlIGl0IHRv IHRoZSB0aHJlYWQgc28gdGhhdCB3ZSBjYW4gY29tcHV0ZSBvdXINCi0JICog aW50ZXJhY3Rpdml0eS4NCi0JICovDQotCXRkLT50ZF9zY2hlZC0+dHNfcnVu dGltZSArPSB0aWNraW5jcjsNCi0Jc2NoZWRfaW50ZXJhY3RfdXBkYXRlKHRk KTsNCisJaWYgKHRkLT50ZF9wcmlfY2xhc3MgPT0gUFJJX1RJTUVTSEFSRSkg ew0KKwkJLyoNCisJCSAqIFdlIHVzZWQgYSB0aWNrOyBjaGFyZ2UgaXQgdG8g dGhlIHRocmVhZCBzbw0KKwkJICogdGhhdCB3ZSBjYW4gY29tcHV0ZSBvdXIg aW50ZXJhY3Rpdml0eS4NCisJCSAqLw0KKwkJdGQtPnRkX3NjaGVkLT50c19y dW50aW1lICs9IHRpY2tpbmNyOw0KKwkJc2NoZWRfaW50ZXJhY3RfdXBkYXRl KHRkKTsNCisJfQ0KIAkvKg0KIAkgKiBXZSB1c2VkIHVwIG9uZSB0aW1lIHNs aWNlLg0KIAkgKi8NCg== --2547152148-139958016-1199280694=:957-- From owner-freebsd-current@FreeBSD.ORG Wed Jan 2 14:09:52 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3856F16A41A for ; Wed, 2 Jan 2008 14:09:52 +0000 (UTC) (envelope-from stefan.lambrev@moneybookers.com) Received: from blah.sun-fish.com (blah.sun-fish.com [217.18.249.150]) by mx1.freebsd.org (Postfix) with ESMTP id 9BAAE13C4F0 for ; Wed, 2 Jan 2008 14:09:51 +0000 (UTC) (envelope-from stefan.lambrev@moneybookers.com) Received: by blah.sun-fish.com (Postfix, from userid 1002) id 49CFD1B10EE7; Wed, 2 Jan 2008 15:09:47 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on blah.cmotd.com X-Spam-Level: X-Spam-Status: No, score=-10.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, J_CHICKENPOX_33 autolearn=no version=3.2.3 Received: from hater.haters.org (hater.cmotd.com [192.168.3.125]) by blah.sun-fish.com (Postfix) with ESMTP id 511BD1B10EA4 for ; Wed, 2 Jan 2008 15:09:38 +0100 (CET) Message-ID: <477B9B22.1090703@moneybookers.com> Date: Wed, 02 Jan 2008 16:09:38 +0200 From: Stefan Lambrev User-Agent: Thunderbird 2.0.0.9 (X11/20071120) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/5339/Wed Jan 2 11:52:11 2008 on blah.cmotd.com X-Virus-Status: Clean Subject: future plans for USB stack X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2008 14:09:52 -0000 Hi, What are the future plans for USB in FreeBSD? Will usb4bsd (http://www.turbocat.net/~hselasky/usb4bsd/) replace the current usb stack in FreeBSD or there is another work to improve the usb stack? I have the problem described here: http://monkey.org/freebsd/archive/freebsd-current/200706/msg00423.html and the solution in this thread works for me too, but if someone is interested in fixing this in freebsd's usb stack I'll be happy to test patches and help debugging. The only problem so far with usb4bsd is that I can't compile sysutils/hal anymore: cc -DHAVE_CONFIG_H -I. -I. -I../.. -DPACKAGE_SYSCONF_DIR=\"/usr/local/etc\" -DPACKAGE_DATA_DIR=\"/usr/local/share\" -DPACKAGE_BIN_DIR=\"/usr/local/bin\" -DPACKAGE_LOCALE_DIR=\"/usr/local/share/locale\" -DPACKAGE_LOCALSTATEDIR=\"/usr/local/var\" -I../.. -I.. -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -I/usr/local/include/dbus-1.0 -I/usr/local/include/dbus-1.0/include -I/usr/local/include/libpolkit -I/usr/local/include -O2 -fno-strict-aliasing -pipe -march=prescott -Wall -Wchar-subscripts -Wmissing-declarations -Wnested-externs -Wpointer-arith -Wcast-align -Wsign-compare -MT hf-usb.lo -MD -MP -MF .deps/hf-usb.Tpo -c hf-usb.c -fPIC -DPIC -o .libs/hf-usb.o hf-usb.c:600: warning: 'struct usb_event' declared inside parameter list hf-usb.c:600: warning: its scope is only this definition or declaration, which is probably not what you want hf-usb.c: In function 'hf_usb_process_event': hf-usb.c:604: error: dereferencing pointer to incomplete type hf-usb.c:606: error: 'USB_EVENT_CTRLR_ATTACH' undeclared (first use in this function) hf-usb.c:606: error: (Each undeclared identifier is reported only once hf-usb.c:606: error: for each function it appears in.) hf-usb.c:607: error: dereferencing pointer to incomplete type hf-usb.c:612: error: 'USB_EVENT_CTRLR_DETACH' undeclared (first use in this function) hf-usb.c:613: error: dereferencing pointer to incomplete type hf-usb.c:618: error: 'USB_EVENT_DEVICE_ATTACH' undeclared (first use in this function) hf-usb.c:622: error: dereferencing pointer to incomplete type hf-usb.c:622: error: dereferencing pointer to incomplete type hf-usb.c:625: error: dereferencing pointer to incomplete type hf-usb.c:630: error: dereferencing pointer to incomplete type hf-usb.c:632: error: dereferencing pointer to incomplete type hf-usb.c:637: error: 'USB_EVENT_DEVICE_DETACH' undeclared (first use in this function) hf-usb.c:641: error: dereferencing pointer to incomplete type hf-usb.c:641: error: dereferencing pointer to incomplete type hf-usb.c:645: error: dereferencing pointer to incomplete type hf-usb.c:646: error: dereferencing pointer to incomplete type hf-usb.c:661: error: 'USB_EVENT_DRIVER_ATTACH' undeclared (first use in this function) hf-usb.c:665: error: 'USB_EVENT_DRIVER_DETACH' undeclared (first use in this function) hf-usb.c:670: error: dereferencing pointer to incomplete type hf-usb.c: In function 'hf_usb_event_cb': hf-usb.c:678: error: storage size of 'event' isn't known hf-usb.c:678: warning: unused variable 'event' gmake[5]: *** [hf-usb.lo] Error 1 gmake[5]: Leaving directory `/usr/ports/sysutils/hal/work/hal-0.5.8.20071224/hald/freebsd' gmake[4]: *** [all-recursive] Error 1 gmake[4]: Leaving directory `/usr/ports/sysutils/hal/work/hal-0.5.8.20071224/hald/freebsd' gmake[3]: *** [all-recursive] Error 1 gmake[3]: Leaving directory `/usr/ports/sysutils/hal/work/hal-0.5.8.20071224/hald' gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory `/usr/ports/sysutils/hal/work/hal-0.5.8.20071224/hald' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/usr/ports/sysutils/hal/work/hal-0.5.8.20071224' gmake: *** [all] Error 2 *** Error code 2 -- Best Wishes, Stefan Lambrev ICQ# 24134177 From owner-freebsd-current@FreeBSD.ORG Wed Jan 2 14:14:20 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 98B9816A419 for ; Wed, 2 Jan 2008 14:14:20 +0000 (UTC) (envelope-from roberto@keltia.freenix.fr) Received: from keltia.freenix.fr (keltia.freenix.org [82.230.37.243]) by mx1.freebsd.org (Postfix) with ESMTP id 4D44313C447 for ; Wed, 2 Jan 2008 14:14:20 +0000 (UTC) (envelope-from roberto@keltia.freenix.fr) Received: from localhost (localhost [127.0.0.1]) by keltia.freenix.fr (Postfix/TLS) with ESMTP id 14D563A461; Wed, 2 Jan 2008 15:14:19 +0100 (CET) X-Virus-Scanned: amavisd-new at keltia.freenix.fr Received: from keltia.freenix.fr ([127.0.0.1]) by localhost (keltia.freenix.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y4x4Bfba3gK6; Wed, 2 Jan 2008 15:14:16 +0100 (CET) Received: by keltia.freenix.fr (Postfix/TLS, from userid 101) id 0AB6E3A455; Wed, 2 Jan 2008 15:14:16 +0100 (CET) Date: Wed, 2 Jan 2008 15:14:15 +0100 From: Ollivier Robert To: freebsd-current@freebsd.org, current@FreeBSD.org Message-ID: <20080102141415.GA15414@keltia.freenix.fr> References: <200712301219.29839@aldan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: MacOS X / Macbook Pro - FreeBSD 6.2 / Dell D820 SMP User-Agent: Mutt/1.5.15 (2007-04-06) Cc: Subject: Re: a new way to hang 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2008 14:14:20 -0000 According to Elliot Finley: > -L has been hanging systems ever since it existed. Don't use it. No, it has been hanging systems _temporarely_ during the creation of the snapshot, afterwards, it works. If indeed, snapshot creation blocks, there is a problem, maybe there is not enough space? My own backups (still on a 6.1 machine though) work fine. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr Darwin sidhe.keltia.net Version 8.10.1: Wed May 23 16:33:00 PDT 2007 i386 From owner-freebsd-current@FreeBSD.ORG Wed Jan 2 14:30:44 2008 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E97E916A419 for ; Wed, 2 Jan 2008 14:30:44 +0000 (UTC) (envelope-from roberto@keltia.freenix.fr) Received: from keltia.freenix.fr (keltia.freenix.org [82.230.37.243]) by mx1.freebsd.org (Postfix) with ESMTP id A02D613C43E for ; Wed, 2 Jan 2008 14:30:44 +0000 (UTC) (envelope-from roberto@keltia.freenix.fr) Received: from localhost (localhost [127.0.0.1]) by keltia.freenix.fr (Postfix/TLS) with ESMTP id 14D563A461; Wed, 2 Jan 2008 15:14:19 +0100 (CET) X-Virus-Scanned: amavisd-new at keltia.freenix.fr Received: from keltia.freenix.fr ([127.0.0.1]) by localhost (keltia.freenix.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y4x4Bfba3gK6; Wed, 2 Jan 2008 15:14:16 +0100 (CET) Received: by keltia.freenix.fr (Postfix/TLS, from userid 101) id 0AB6E3A455; Wed, 2 Jan 2008 15:14:16 +0100 (CET) Date: Wed, 2 Jan 2008 15:14:15 +0100 From: Ollivier Robert To: freebsd-current@freebsd.org, current@FreeBSD.org Message-ID: <20080102141415.GA15414@keltia.freenix.fr> References: <200712301219.29839@aldan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: MacOS X / Macbook Pro - FreeBSD 6.2 / Dell D820 SMP User-Agent: Mutt/1.5.15 (2007-04-06) Cc: Subject: Re: a new way to hang 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2008 14:30:45 -0000 According to Elliot Finley: > -L has been hanging systems ever since it existed. Don't use it. No, it has been hanging systems _temporarely_ during the creation of the snapshot, afterwards, it works. If indeed, snapshot creation blocks, there is a problem, maybe there is not enough space? My own backups (still on a 6.1 machine though) work fine. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr Darwin sidhe.keltia.net Version 8.10.1: Wed May 23 16:33:00 PDT 2007 i386 From owner-freebsd-current@FreeBSD.ORG Wed Jan 2 16:15:26 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B728116A417; Wed, 2 Jan 2008 16:15:26 +0000 (UTC) (envelope-from emaste@freebsd.org) Received: from gw.sandvine.com (gw.sandvine.com [199.243.201.138]) by mx1.freebsd.org (Postfix) with ESMTP id 49FC213C46E; Wed, 2 Jan 2008 16:15:26 +0000 (UTC) (envelope-from emaste@freebsd.org) Received: from labgw2.phaedrus.sandvine.com ([192.168.3.11]) by gw.sandvine.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Jan 2008 11:03:23 -0500 Received: by labgw2.phaedrus.sandvine.com (Postfix, from userid 12627) id 271AC116DA; Wed, 2 Jan 2008 11:03:23 -0500 (EST) Date: Wed, 2 Jan 2008 11:03:23 -0500 From: Ed Maste To: Mike Silbersack Message-ID: <20080102160322.GA83957@sandvine.com> Mail-Followup-To: Ed Maste , Mike Silbersack , "Bruce M. Simpson" , Robert Watson , current@freebsd.org References: <20071228015651.X1565@odysseus.silby.com> <20071228095539.F45653@fledge.watson.org> <20071229180004.O6052@odysseus.silby.com> <477A627A.8010601@FreeBSD.org> <20080101222654.A8764@odysseus.silby.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="t0UkRYy7tHLRMCai" Content-Disposition: inline In-Reply-To: <20080101222654.A8764@odysseus.silby.com> User-Agent: Mutt/1.4.2.1i X-OriginalArrivalTime: 02 Jan 2008 16:03:23.0378 (UTC) FILETIME=[00600520:01C84D59] Cc: Robert Watson , "Bruce M. Simpson" , current@freebsd.org Subject: Re: [patch] Auto-setting hz to 100 inside QEMU/VMWare X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2008 16:15:26 -0000 --t0UkRYy7tHLRMCai Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Jan 01, 2008 at 10:27:28PM -0600, Mike Silbersack wrote: > It looks like we're going to go with an alternate implementation that > resides in the loader instead. The effect will be the same, and it should > be committed within a few days. I've attached a proof of concept patch that does this in forth in the loader. I've been using something similar for a while; this patch isi cleaned up somewhat and I've added the kenv strings from Mike's patch. I've only tried it out with qemu so far. I'd appreciate reports of any testing with other emulators, and comments from loader/forth gurus. -Ed --t0UkRYy7tHLRMCai Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="loader_vm.diff" Index: sys/boot/forth/vm.4th =================================================================== RCS file: sys/boot/forth/vm.4th diff -N sys/boot/forth/vm.4th --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ sys/boot/forth/vm.4th 2 Jan 2008 15:38:41 -0000 @@ -0,0 +1,35 @@ +: check-env? ( addr len addr len -- flag ) + getenv + dup -1 <> if + compare 0= if + true exit + then + else + drop + 2drop + then + false +; + +: is-vm? ( -- flag ) + s" QEMU " s" hint.acpi.0.oem" check-env? if + true exit + then + s" VBOX " s" hint.acpi.0.oem" check-env? if + true exit + then + s" VMware, Inc." s" smbios.system.maker" check-env? if + true exit + then + s" Parallels Software International Inc." s" smbios.bios.vendor" + check-env? if + true exit + then + false +; + +: setup-vm + is-vm? if + s" 100" s" hz" setenv + then +; Index: sys/boot/i386/loader/Makefile =================================================================== RCS file: /usr/cvs/src/sys/boot/i386/loader/Makefile,v retrieving revision 1.85 diff -u -r1.85 Makefile --- sys/boot/i386/loader/Makefile 29 May 2007 14:35:57 -0000 1.85 +++ sys/boot/i386/loader/Makefile 2 Jan 2008 15:48:06 -0000 @@ -84,7 +84,7 @@ .PATH: ${.CURDIR}/../../forth FILES= loader loader.help loader.4th support.4th loader.conf -FILES+= screen.4th frames.4th beastie.4th +FILES+= screen.4th frames.4th beastie.4th vm.4th # XXX INSTALLFLAGS_loader= -b FILESMODE_loader= ${BINMODE} -b FILESDIR_loader.conf= /boot/defaults Index: sys/boot/i386/loader/loader.rc =================================================================== RCS file: /usr/cvs/src/sys/boot/i386/loader/loader.rc,v retrieving revision 1.4 diff -u -r1.4 loader.rc --- sys/boot/i386/loader/loader.rc 30 Oct 2005 05:41:42 -0000 1.4 +++ sys/boot/i386/loader/loader.rc 2 Jan 2008 15:38:52 -0000 @@ -4,6 +4,10 @@ \ Includes additional commands include /boot/loader.4th +\ Virtual machine detection +include /boot/vm.4th +setup-vm + \ Reads and processes loader.conf variables start --t0UkRYy7tHLRMCai-- From owner-freebsd-current@FreeBSD.ORG Wed Jan 2 16:17:03 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 22DF516A4A7; Wed, 2 Jan 2008 16:17:03 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id C05BF13C4EB; Wed, 2 Jan 2008 16:17:02 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id ACF2120A0; Wed, 2 Jan 2008 17:16:53 +0100 (CET) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: -0.1/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 996A42049; Wed, 2 Jan 2008 17:16:53 +0100 (CET) Received: by ds4.des.no (Postfix, from userid 1001) id 49DA0844CD; Wed, 2 Jan 2008 17:16:53 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: "Sepherosa Ziehau" References: <86ir2hznnd.fsf@ds4.des.no> <86abnpu0wv.fsf@ds4.des.no> Date: Wed, 02 Jan 2008 17:16:53 +0100 In-Reply-To: (Sepherosa Ziehau's message of "Wed\, 2 Jan 2008 21\:18\:37 +0800") Message-ID: <86prwkqk22.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: kevlo@freebsd.org, sam@freebsd.org, current@freebsd.org, net@freebsd.org Subject: Re: if_ral regression X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2008 16:17:03 -0000 "Sepherosa Ziehau" writes: > http://people.freebsd.org/~sephe/rt2560_test.diff Thank you, I'll try that. Could you explain what the RT2560_BBP_BUSY loop is about? DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Wed Jan 2 16:24:28 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8266216A41B for ; Wed, 2 Jan 2008 16:24:28 +0000 (UTC) (envelope-from taosecurity@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.245]) by mx1.freebsd.org (Postfix) with ESMTP id 3F29E13C442 for ; Wed, 2 Jan 2008 16:24:28 +0000 (UTC) (envelope-from taosecurity@gmail.com) Received: by an-out-0708.google.com with SMTP id c14so1148444anc.13 for ; Wed, 02 Jan 2008 08:24:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=z533rXxHMzG02cErw7U222hhdhy2Rv/pHBjsQtHJtTM=; b=jtjL0DuT/8hl9s0npvDCoOBKRJEsnIJBfvBJ9cNkIrD2vSecwnSTDAKfWMak7CFBtUN8BqWr+xls/xQwm+VKIrLVlXnwoD0/FH6xIuKO0gGUy9CPunb+3chnDWEvmF39BYgOfJ+WERZ+TF+4ZUmaqY3f0VCSnC+JwJHS97pCSbk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=fnR1Sk/rSB0GsuDx9Ef0F6elK00X9M3HAJaVGpHnS6hPKB0axZL7mL9707AXhD/evlfTMifZIJKY6M7xCJD1OqIT24pOJ8wdLJ5aex1BS31d6w+SUbGDgvmem6SJGAZvg9fE9peBECrTogFKiG3pJh/puVPkBFNqnymswUeBLEw= Received: by 10.100.172.17 with SMTP id u17mr21004522ane.27.1199289488243; Wed, 02 Jan 2008 07:58:08 -0800 (PST) Received: by 10.100.249.11 with HTTP; Wed, 2 Jan 2008 07:58:08 -0800 (PST) Message-ID: <120ef0530801020758k48d90199s25edd13dbaf46721@mail.gmail.com> Date: Wed, 2 Jan 2008 10:58:08 -0500 From: "Richard Bejtlich" To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: 7.0-RC1 fails at mountroot; 7.0-BETA4 was ok X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2008 16:24:28 -0000 Hello, I was running FreeBSD 7.0-BETA4 on a Dell Poweredge 750 and tried to use freebsd-update to upgrade to 7.0-RC1. I have successfully used freebsd-update before, e.g. (albeit a different machine) http://taosecurity.blogspot.com/2007/11/updating-freebsd-70-beta2-to-70-beta3.html I followed these steps on the Dell. fetch http://www.daemonology.net/freebsd-update/freebsd-update-upgrade.tgz tar -xf freebsd-update-upgrade.tgz sh freebsd-update.sh -f freebsd-update.conf -r 7.0-RC1 upgrade sh freebsd-update.sh -f freebsd-update.conf install shutdown -r now Upon rebooting I encountered this error: Trying to mount root from ufs:/dev/ad2s1a Manual root filesystem specification: ...edited... mountroot> If I issue the ? command I see mountroot>? List of GEOM managed disk devices: acd0 fd0 I verified by booting the BETA4 CD that ad2s1a is the right location for the / partition. I next tried installing RC1 using a CD, but it failed to find any hard drive. I finished by reinstalling BETA4 from CD, which found the hard drive. ad2: 38146MB at ata1-master SATA150 $ df -h Filesystem Size Used Avail Capacity Mounted on /dev/ad2s1a 496M 127M 329M 28% / devfs 1.0K 1.0K 0B 100% /dev /dev/ad2s1e 989M 22K 910M 0% /home /dev/ad2s1h 22G 4.0K 20G 0% /nsm1 /dev/ad2s1f 989M 12K 910M 0% /tmp /dev/ad2s1d 4.8G 755M 3.7G 17% /usr /dev/ad2s1g 5.4G 242K 4.9G 0% /var What info can I provide to help troubleshoot this problem? Thank you, Richard From owner-freebsd-current@FreeBSD.ORG Wed Jan 2 16:33:15 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0FD8616A418 for ; Wed, 2 Jan 2008 16:33:15 +0000 (UTC) (envelope-from jhary@unsane.co.uk) Received: from unsane.co.uk (unsane-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:1f1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 853C313C465 for ; Wed, 2 Jan 2008 16:33:14 +0000 (UTC) (envelope-from jhary@unsane.co.uk) Received: from prawn.unsane.co.uk (150.117-84-212.staticip.namesco.net [212.84.117.150]) (authenticated bits=0) by unsane.co.uk (8.14.0/8.14.0) with ESMTP id m02GWLFK036221 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Jan 2008 16:32:24 GMT (envelope-from jhary@unsane.co.uk) Message-ID: <477BBCC1.6020900@unsane.co.uk> Date: Wed, 02 Jan 2008 16:33:05 +0000 From: Vince User-Agent: Thunderbird 2.0.0.9 (X11/20071116) MIME-Version: 1.0 To: Stefan Lambrev References: <477B9B22.1090703@moneybookers.com> In-Reply-To: <477B9B22.1090703@moneybookers.com> X-Enigmail-Version: 0.95.2 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: future plans for USB stack X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2008 16:33:15 -0000 Stefan Lambrev wrote: > Hi, > > What are the future plans for USB in FreeBSD? > Will usb4bsd (http://www.turbocat.net/~hselasky/usb4bsd/) replace the > current usb stack in FreeBSD > or there is another work to improve the usb stack? > I believe this is planned to be the furture for the usb stack. Currently it appears to be in perforce http://perforce.freebsd.org/branchView.cgi?BRANCH=usb no idea if theres a patch set or tarball for the general public, but its being activley worked on. the freebsd-usb list might be a better place to ask. Vince > I have the problem described here: > http://monkey.org/freebsd/archive/freebsd-current/200706/msg00423.html > and the solution in this thread works for me too, but if someone is > interested in fixing this in freebsd's usb stack > I'll be happy to test patches and help debugging. > > The only problem so far with usb4bsd is that I can't compile > sysutils/hal anymore: > > cc -DHAVE_CONFIG_H -I. -I. -I../.. > -DPACKAGE_SYSCONF_DIR=\"/usr/local/etc\" > -DPACKAGE_DATA_DIR=\"/usr/local/share\" > -DPACKAGE_BIN_DIR=\"/usr/local/bin\" > -DPACKAGE_LOCALE_DIR=\"/usr/local/share/locale\" > -DPACKAGE_LOCALSTATEDIR=\"/usr/local/var\" -I../.. -I.. > -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include > -I/usr/local/include/dbus-1.0 -I/usr/local/include/dbus-1.0/include > -I/usr/local/include/libpolkit -I/usr/local/include -O2 > -fno-strict-aliasing -pipe -march=prescott -Wall -Wchar-subscripts > -Wmissing-declarations -Wnested-externs -Wpointer-arith -Wcast-align > -Wsign-compare -MT hf-usb.lo -MD -MP -MF .deps/hf-usb.Tpo -c hf-usb.c > -fPIC -DPIC -o .libs/hf-usb.o > hf-usb.c:600: warning: 'struct usb_event' declared inside parameter list > hf-usb.c:600: warning: its scope is only this definition or declaration, > which is probably not what you want > hf-usb.c: In function 'hf_usb_process_event': > hf-usb.c:604: error: dereferencing pointer to incomplete type > hf-usb.c:606: error: 'USB_EVENT_CTRLR_ATTACH' undeclared (first use in > this function) > hf-usb.c:606: error: (Each undeclared identifier is reported only once > hf-usb.c:606: error: for each function it appears in.) > hf-usb.c:607: error: dereferencing pointer to incomplete type > hf-usb.c:612: error: 'USB_EVENT_CTRLR_DETACH' undeclared (first use in > this function) > hf-usb.c:613: error: dereferencing pointer to incomplete type > hf-usb.c:618: error: 'USB_EVENT_DEVICE_ATTACH' undeclared (first use in > this function) > hf-usb.c:622: error: dereferencing pointer to incomplete type > hf-usb.c:622: error: dereferencing pointer to incomplete type > hf-usb.c:625: error: dereferencing pointer to incomplete type > hf-usb.c:630: error: dereferencing pointer to incomplete type > hf-usb.c:632: error: dereferencing pointer to incomplete type > hf-usb.c:637: error: 'USB_EVENT_DEVICE_DETACH' undeclared (first use in > this function) > hf-usb.c:641: error: dereferencing pointer to incomplete type > hf-usb.c:641: error: dereferencing pointer to incomplete type > hf-usb.c:645: error: dereferencing pointer to incomplete type > hf-usb.c:646: error: dereferencing pointer to incomplete type > hf-usb.c:661: error: 'USB_EVENT_DRIVER_ATTACH' undeclared (first use in > this function) > hf-usb.c:665: error: 'USB_EVENT_DRIVER_DETACH' undeclared (first use in > this function) > hf-usb.c:670: error: dereferencing pointer to incomplete type > hf-usb.c: In function 'hf_usb_event_cb': > hf-usb.c:678: error: storage size of 'event' isn't known > hf-usb.c:678: warning: unused variable 'event' > gmake[5]: *** [hf-usb.lo] Error 1 > gmake[5]: Leaving directory > `/usr/ports/sysutils/hal/work/hal-0.5.8.20071224/hald/freebsd' > gmake[4]: *** [all-recursive] Error 1 > gmake[4]: Leaving directory > `/usr/ports/sysutils/hal/work/hal-0.5.8.20071224/hald/freebsd' > gmake[3]: *** [all-recursive] Error 1 > gmake[3]: Leaving directory > `/usr/ports/sysutils/hal/work/hal-0.5.8.20071224/hald' > gmake[2]: *** [all] Error 2 > gmake[2]: Leaving directory > `/usr/ports/sysutils/hal/work/hal-0.5.8.20071224/hald' > gmake[1]: *** [all-recursive] Error 1 > gmake[1]: Leaving directory > `/usr/ports/sysutils/hal/work/hal-0.5.8.20071224' > gmake: *** [all] Error 2 > *** Error code 2 > From owner-freebsd-current@FreeBSD.ORG Wed Jan 2 16:41:43 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 66BA016A418 for ; Wed, 2 Jan 2008 16:41:43 +0000 (UTC) (envelope-from stefan.lambrev@moneybookers.com) Received: from blah.sun-fish.com (blah.sun-fish.com [217.18.249.150]) by mx1.freebsd.org (Postfix) with ESMTP id F39CE13C4D3 for ; Wed, 2 Jan 2008 16:41:42 +0000 (UTC) (envelope-from stefan.lambrev@moneybookers.com) Received: by blah.sun-fish.com (Postfix, from userid 1002) id 9AD8A1B10EF1; Wed, 2 Jan 2008 17:41:41 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on blah.cmotd.com X-Spam-Level: X-Spam-Status: No, score=-10.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, J_CHICKENPOX_33 autolearn=no version=3.2.3 Received: from hater.haters.org (hater.cmotd.com [192.168.3.125]) by blah.sun-fish.com (Postfix) with ESMTP id 2B5D91B10ED2; Wed, 2 Jan 2008 17:41:38 +0100 (CET) Message-ID: <477BBEC2.6070204@moneybookers.com> Date: Wed, 02 Jan 2008 18:41:38 +0200 From: Stefan Lambrev User-Agent: Thunderbird 2.0.0.9 (X11/20071120) MIME-Version: 1.0 To: Vince References: <477B9B22.1090703@moneybookers.com> <477BBCC1.6020900@unsane.co.uk> In-Reply-To: <477BBCC1.6020900@unsane.co.uk> Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/5340/Wed Jan 2 14:37:52 2008 on blah.cmotd.com X-Virus-Status: Clean Cc: freebsd-current@freebsd.org Subject: Re: future plans for USB stack X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2008 16:41:43 -0000 Hi, Vince wrote: > Stefan Lambrev wrote: > >> Hi, >> >> What are the future plans for USB in FreeBSD? >> Will usb4bsd (http://www.turbocat.net/~hselasky/usb4bsd/) replace the >> current usb stack in FreeBSD >> or there is another work to improve the usb stack? >> >> > I believe this is planned to be the furture for the usb stack. Currently > it appears to be in perforce > http://perforce.freebsd.org/branchView.cgi?BRANCH=usb > > no idea if theres a patch set or tarball for the general public, but its > being activley worked on. the freebsd-usb list might be a better place > to ask. > Thanks for the prompt reply. I'll repost my questions to freebsd-usb :) > Vince > > >> I have the problem described here: >> http://monkey.org/freebsd/archive/freebsd-current/200706/msg00423.html >> and the solution in this thread works for me too, but if someone is >> interested in fixing this in freebsd's usb stack >> I'll be happy to test patches and help debugging. >> >> The only problem so far with usb4bsd is that I can't compile >> sysutils/hal anymore: >> >> cc -DHAVE_CONFIG_H -I. -I. -I../.. >> -DPACKAGE_SYSCONF_DIR=\"/usr/local/etc\" >> -DPACKAGE_DATA_DIR=\"/usr/local/share\" >> -DPACKAGE_BIN_DIR=\"/usr/local/bin\" >> -DPACKAGE_LOCALE_DIR=\"/usr/local/share/locale\" >> -DPACKAGE_LOCALSTATEDIR=\"/usr/local/var\" -I../.. -I.. >> -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include >> -I/usr/local/include/dbus-1.0 -I/usr/local/include/dbus-1.0/include >> -I/usr/local/include/libpolkit -I/usr/local/include -O2 >> -fno-strict-aliasing -pipe -march=prescott -Wall -Wchar-subscripts >> -Wmissing-declarations -Wnested-externs -Wpointer-arith -Wcast-align >> -Wsign-compare -MT hf-usb.lo -MD -MP -MF .deps/hf-usb.Tpo -c hf-usb.c >> -fPIC -DPIC -o .libs/hf-usb.o >> hf-usb.c:600: warning: 'struct usb_event' declared inside parameter list >> hf-usb.c:600: warning: its scope is only this definition or declaration, >> which is probably not what you want >> hf-usb.c: In function 'hf_usb_process_event': >> hf-usb.c:604: error: dereferencing pointer to incomplete type >> hf-usb.c:606: error: 'USB_EVENT_CTRLR_ATTACH' undeclared (first use in >> this function) >> hf-usb.c:606: error: (Each undeclared identifier is reported only once >> hf-usb.c:606: error: for each function it appears in.) >> hf-usb.c:607: error: dereferencing pointer to incomplete type >> hf-usb.c:612: error: 'USB_EVENT_CTRLR_DETACH' undeclared (first use in >> this function) >> hf-usb.c:613: error: dereferencing pointer to incomplete type >> hf-usb.c:618: error: 'USB_EVENT_DEVICE_ATTACH' undeclared (first use in >> this function) >> hf-usb.c:622: error: dereferencing pointer to incomplete type >> hf-usb.c:622: error: dereferencing pointer to incomplete type >> hf-usb.c:625: error: dereferencing pointer to incomplete type >> hf-usb.c:630: error: dereferencing pointer to incomplete type >> hf-usb.c:632: error: dereferencing pointer to incomplete type >> hf-usb.c:637: error: 'USB_EVENT_DEVICE_DETACH' undeclared (first use in >> this function) >> hf-usb.c:641: error: dereferencing pointer to incomplete type >> hf-usb.c:641: error: dereferencing pointer to incomplete type >> hf-usb.c:645: error: dereferencing pointer to incomplete type >> hf-usb.c:646: error: dereferencing pointer to incomplete type >> hf-usb.c:661: error: 'USB_EVENT_DRIVER_ATTACH' undeclared (first use in >> this function) >> hf-usb.c:665: error: 'USB_EVENT_DRIVER_DETACH' undeclared (first use in >> this function) >> hf-usb.c:670: error: dereferencing pointer to incomplete type >> hf-usb.c: In function 'hf_usb_event_cb': >> hf-usb.c:678: error: storage size of 'event' isn't known >> hf-usb.c:678: warning: unused variable 'event' >> gmake[5]: *** [hf-usb.lo] Error 1 >> gmake[5]: Leaving directory >> `/usr/ports/sysutils/hal/work/hal-0.5.8.20071224/hald/freebsd' >> gmake[4]: *** [all-recursive] Error 1 >> gmake[4]: Leaving directory >> `/usr/ports/sysutils/hal/work/hal-0.5.8.20071224/hald/freebsd' >> gmake[3]: *** [all-recursive] Error 1 >> gmake[3]: Leaving directory >> `/usr/ports/sysutils/hal/work/hal-0.5.8.20071224/hald' >> gmake[2]: *** [all] Error 2 >> gmake[2]: Leaving directory >> `/usr/ports/sysutils/hal/work/hal-0.5.8.20071224/hald' >> gmake[1]: *** [all-recursive] Error 1 >> gmake[1]: Leaving directory >> `/usr/ports/sysutils/hal/work/hal-0.5.8.20071224' >> gmake: *** [all] Error 2 >> *** Error code 2 >> >> > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > -- Best Wishes, Stefan Lambrev ICQ# 24134177 From owner-freebsd-current@FreeBSD.ORG Wed Jan 2 17:50:53 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1036216A41A for ; Wed, 2 Jan 2008 17:50:53 +0000 (UTC) (envelope-from morten@lightworkings.dk) Received: from mail.tobocom.net (mail.tobocom.net [89.221.166.157]) by mx1.freebsd.org (Postfix) with SMTP id 9218213C46E for ; Wed, 2 Jan 2008 17:50:51 +0000 (UTC) (envelope-from morten@lightworkings.dk) Received: from atlantis.local ([85.80.153.38]) by mail.tobocom.net with hMailServer ; Wed, 2 Jan 2008 18:50:49 +0100 Message-ID: <477BCEF6.5000607@lightworkings.dk> Date: Wed, 02 Jan 2008 18:50:46 +0100 From: =?ISO-8859-1?Q?Morten_Str=E5rup?= User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <1497D115-2534-4799-9D8E-18A267DF0B62@mipster.net> In-Reply-To: <1497D115-2534-4799-9D8E-18A267DF0B62@mipster.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: ServerWorks/Broadcom HT1000 chipset errata saga X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2008 17:50:53 -0000 wrote: > BTW, I've had PCI-X problems with a Marvel MV88SX6081 SATA controller > on a M/B WITHOUT the HT1000 chipset (Tyan S2881UG2NR). The M/B worked > flawlessly under 7.0-BETA1 & BETA2. I added the Marvell controller > and EVERYTHING on the PCI-X bus flaked out. I'm seeing Ierrs and > Oerrs (netstat -i) on the built-in bge interfaces, ZFS checksum errors > on disks attached to the Marvel controller, etc. > > I wasn't sure from reading the thread whether Soren thought the > problem went beyond the HT1000 chipset or not. The problem seems to > manifest itself only when I use the disks attached to the Marvel > controller. I'm applying the patch now to see if it fixes the problem. > For what it's worth as mentioned in this thread: http://lists.freebsd.org/pipermail/freebsd-current/2007-December/081541.html I've experienced things similar to what is mentioned in the HT1000 Problem Report with an Nvidia Nforce 570 MCP SLI chipset. In this message I've posted the output of pciconf -lv: http://lists.freebsd.org/pipermail/freebsd-current/2007-December/081547.html Kind regards Morten Strårup From owner-freebsd-current@FreeBSD.ORG Wed Jan 2 18:31:44 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3972316A469 for ; Wed, 2 Jan 2008 18:31:44 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id E1F9213C4D1 for ; Wed, 2 Jan 2008 18:31:43 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 70AF849A44; Wed, 2 Jan 2008 13:31:43 -0500 (EST) Date: Wed, 2 Jan 2008 18:31:43 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Ed Maste In-Reply-To: <20080102160322.GA83957@sandvine.com> Message-ID: <20080102182732.N30578@fledge.watson.org> References: <20071228015651.X1565@odysseus.silby.com> <20071228095539.F45653@fledge.watson.org> <20071229180004.O6052@odysseus.silby.com> <477A627A.8010601@FreeBSD.org> <20080101222654.A8764@odysseus.silby.com> <20080102160322.GA83957@sandvine.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Mike Silbersack , "Bruce M. Simpson" , current@freebsd.org Subject: Re: [patch] Auto-setting hz to 100 inside QEMU/VMWare X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2008 18:31:44 -0000 On Wed, 2 Jan 2008, Ed Maste wrote: > On Tue, Jan 01, 2008 at 10:27:28PM -0600, Mike Silbersack wrote: > >> It looks like we're going to go with an alternate implementation that >> resides in the loader instead. The effect will be the same, and it should >> be committed within a few days. > > I've attached a proof of concept patch that does this in forth in the > loader. I've been using something similar for a while; this patch isi > cleaned up somewhat and I've added the kenv strings from Mike's patch. > > I've only tried it out with qemu so far. I'd appreciate reports of any > testing with other emulators, and comments from loader/forth gurus. With this patch, is one forced to use a HZ of 100 when running under a VM unless one modifies the loader scripts? There are times when I experiment with alternative HZ settings in VMs, and as such it would be nice to have an intentional way to turn off auto-setting of HZ, and/oor specify what the VM HZ should be, using loader.conf. I.e.: vmadjusthz_enable="NO" and vmadjusthz_hz="50" Allowing me to either manually disable the override of kern.hz, or to specify what the replacement value should be. One other variation I'd sort of been thinking about was using the loader to set a kernel environmental variable indicating that we're in a VM, but then letting the kernel decide what to do about it, per my previous suggestion to silby. That way we could define a kernel option in GENERIC the same way we do HZ: options VMHZ="100" The loader would make the decision as to which would be used, but the logic to implement the HZ change would be in the kernel. And loader.conf's kern.hz would still be able to override it... I just want to make sure that we retain all the current flexibility to modify HZ at boot-time while having the default be more sensible. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Wed Jan 2 18:40:55 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7180B16A481 for ; Wed, 2 Jan 2008 18:40:55 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 447A113C458 for ; Wed, 2 Jan 2008 18:40:55 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id C842149605; Wed, 2 Jan 2008 13:40:54 -0500 (EST) Date: Wed, 2 Jan 2008 18:40:54 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Ed Maste In-Reply-To: <20080102182732.N30578@fledge.watson.org> Message-ID: <20080102183522.T30578@fledge.watson.org> References: <20071228015651.X1565@odysseus.silby.com> <20071228095539.F45653@fledge.watson.org> <20071229180004.O6052@odysseus.silby.com> <477A627A.8010601@FreeBSD.org> <20080101222654.A8764@odysseus.silby.com> <20080102160322.GA83957@sandvine.com> <20080102182732.N30578@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Mike Silbersack , "Bruce M. Simpson" , current@freebsd.org Subject: Re: [patch] Auto-setting hz to 100 inside QEMU/VMWare X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2008 18:40:55 -0000 On Wed, 2 Jan 2008, Robert Watson wrote: >> I've only tried it out with qemu so far. I'd appreciate reports of any >> testing with other emulators, and comments from loader/forth gurus. > > With this patch, is one forced to use a HZ of 100 when running under a VM > unless one modifies the loader scripts? There are times when I experiment > with alternative HZ settings in VMs, and as such it would be nice to have an > intentional way to turn off auto-setting of HZ, and/oor specify what the VM > HZ should be, using loader.conf. On a similar note, it would be nice if there were a kenv/sysctl hw.virtualized that was derived from the loader's decision (or in some other way), which could then be used to key other configuration choices than HZ. For example, in the future we might want to change the way we did idle loops, power management, process acounting, etc. This could be used to key a HZ selection in kernel rather than hard-coding knowledge of HZ into the loader environment. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Wed Jan 2 19:14:11 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 823DB16A419; Wed, 2 Jan 2008 19:14:11 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 3639E13C455; Wed, 2 Jan 2008 19:14:11 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 43EEF20A0; Wed, 2 Jan 2008 20:14:03 +0100 (CET) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: -0.1/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 2CD9B2089; Wed, 2 Jan 2008 20:14:03 +0100 (CET) Received: by ds4.des.no (Postfix, from userid 1001) id 14D2784490; Wed, 2 Jan 2008 20:14:03 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: "Sepherosa Ziehau" References: <86ir2hznnd.fsf@ds4.des.no> <86abnpu0wv.fsf@ds4.des.no> Date: Wed, 02 Jan 2008 20:14:03 +0100 In-Reply-To: (Sepherosa Ziehau's message of "Wed\, 2 Jan 2008 21\:18\:37 +0800") Message-ID: <86abnovy4k.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: kevlo@freebsd.org, sam@freebsd.org, current@freebsd.org, net@freebsd.org Subject: Re: if_ral regression X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2008 19:14:11 -0000 "Sepherosa Ziehau" writes: > http://people.freebsd.org/~sephe/rt2560_test.diff > > Hope it will have some effect. I built a new kernel with the patch applied, and it seems to help, though it's a bit early to say for sure. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Wed Jan 2 19:18:05 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9A74E16A417 for ; Wed, 2 Jan 2008 19:18:05 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 54AD913C4D1 for ; Wed, 2 Jan 2008 19:18:05 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 4C0F42099; Wed, 2 Jan 2008 20:17:55 +0100 (CET) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: -0.1/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id C7D242049; Wed, 2 Jan 2008 20:17:54 +0100 (CET) Received: by ds4.des.no (Postfix, from userid 1001) id B0ABA84490; Wed, 2 Jan 2008 20:17:54 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Vince References: <477B9B22.1090703@moneybookers.com> <477BBCC1.6020900@unsane.co.uk> Date: Wed, 02 Jan 2008 20:17:54 +0100 In-Reply-To: <477BBCC1.6020900@unsane.co.uk> (Vince's message of "Wed\, 02 Jan 2008 16\:33\:05 +0000") Message-ID: <8663ycvxy5.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, Stefan Lambrev Subject: Re: future plans for USB stack X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2008 19:18:05 -0000 Vince writes: > Stefan Lambrev writes: > > What are the future plans for USB in FreeBSD? Will usb4bsd > > (http://www.turbocat.net/~hselasky/usb4bsd/) replace the current usb > > stack in FreeBSD or there is another work to improve the usb stack? > I believe this is planned to be the furture for the usb stack. Not without a lot of work. There are a number of architectural and code quality issues which the author has repeatedly refused to address. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Wed Jan 2 19:27:14 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B82E216A417; Wed, 2 Jan 2008 19:27:14 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.delphij.net (delphij-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:2c9::2]) by mx1.freebsd.org (Postfix) with ESMTP id 7561913C45B; Wed, 2 Jan 2008 19:27:13 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (unknown [202.108.54.204]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.delphij.net (Postfix) with ESMTP id 0CF3428448; Thu, 3 Jan 2008 03:27:11 +0800 (CST) Received: from localhost (unknown [202.108.54.204]) by tarsier.geekcn.org (Postfix) with ESMTP id DF6F3EDADD0; Thu, 3 Jan 2008 03:27:10 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([202.108.54.204]) by localhost (mail.geekcn.org [202.108.54.204]) (amavisd-new, port 10024) with ESMTP id hxP8RNf2e1oR; Thu, 3 Jan 2008 03:27:03 +0800 (CST) Received: from charlie.delphij.net (71.5.7.139.ptr.us.xo.net [71.5.7.139]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id 478AEEDADC9; Thu, 3 Jan 2008 03:27:02 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:subject:x-enigmail-version:openpgp:content-type; b=RCy/u6GeAdi/wRe7lhKYJyUU/sK1PDwKgeAXNuoWopkENZQvsDUrgh9DVxwDMhLYd xIYGuNxFm8v3jhe0EwcRg== Message-ID: <477BE583.6080202@delphij.net> Date: Wed, 02 Jan 2008 11:26:59 -0800 From: Xin LI Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.9 (X11/20071125) MIME-Version: 1.0 To: freebsd-rc@FreeBSD.org, FreeBSD Current X-Enigmail-Version: 0.95.5 OpenPGP: id=18EDEBA0; url=http://www.delphij.net/delphij.asc Content-Type: multipart/mixed; boundary="------------080003070301000505080207" Cc: Subject: [RFC] rc.d script for binding static arp pairs and logging options X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2008 19:27:14 -0000 This is a multi-part message in MIME format. --------------080003070301000505080207 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Here is a rc.d script that I use on my own server, which provides two functionalities: - Bind ARP pairs specified in rc.conf (*); - Set ARP logging options (+). * Similar to routing settings, one need to set up some sort of "ARP pairs" like this: static_arp_pairs="gw" arp_gw="172.16.1.1 00:1c:58:6a:7b:49" + By setting one or more of the following options to "NO" it would set appropriate sysctl for arp logging settings to zero to disable logging: log_arp_permanent_modify log_arp_movements log_arp_wrong_iface This script could be useful for those who use FreeBSD in a uncontrollable network (i.e. your network administrator does not care about viruses that attacks the network with fake ARP broadcasts). I wonder whether this script would be useful for general consumption? Other comments are also welcome :-) Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHe+WCi+vbBBjt66ARAvA/AJ9zv5Wtif9DPgDPT89ZOOoueu+w9gCeK3gY 4GEETsKg53j19QLFd3IZKkc= =rLKv -----END PGP SIGNATURE----- --------------080003070301000505080207 Content-Type: text/plain; name="arp" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="arp" #!/bin/sh # # Copyright (c) 2008 Xin LI # All rights reserved. # # Redistribution and use in source and binary forms, with or without # modification, are permitted provided that the following conditions # are met: # 1. Redistributions of source code must retain the above copyright # notice, this list of conditions and the following disclaimer. # 2. Redistributions in binary form must reproduce the above copyright # notice, this list of conditions and the following disclaimer in the # documentation and/or other materials provided with the distribution. # # THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND # ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE # IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE # ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE # FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL # DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS # OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) # HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT # LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY # OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF # SUCH DAMAGE. # # Configure static ARP table and logging options # # $FreeBSD$ # # PROVIDE: arp # REQUIRE: netif # KEYWORD: nojail . /etc/rc.subr name="arp" start_cmd="arp_start" stop_cmd="arp_stop" extra_commands="options static" static_cmd="static_start" options_cmd="options_start" arp_start() { options_start static_start } arp_stop() { static_stop } options_start() { echo -n 'Additional ARP logging options:' if [ -n ${log_arp_perment_modify} ]; then case ${log_arp_permanent_modify} in [Nn][Oo]) echo -n ' do not' sysctl net.link.ether.inet.log_arp_permanent_modify=0 >/dev/null ;; *) sysctl net.link.ether.inet.log_arp_permanent_modify=1 >/dev/null ;; esac echo -n ' log arp replies from MACs different than the one in the permanent arp entry;' fi if [ -n ${log_arp_movements} ]; then case ${log_arp_movements} in [Nn][Oo]) echo -n ' do not' sysctl net.link.ether.inet.log_arp_movements=0 >/dev/null ;; *) sysctl net.link.ether.inet.log_arp_movements=1 >/dev/null ;; esac echo -n ' log arp replies from MACs different than the one in the cache;' fi if [ -n ${log_arp_wrong_iface} ]; then case ${log_arp_wrong_iface} in [Nn][Oo]) echo -n ' do not' sysctl net.link.ether.inet.log_arp_wrong_iface=0 >/dev/null ;; *) sysctl net.link.ether.inet.log_arp_wrong_iface=1 >/dev/null ;; esac echo -n ' log arp packets arriving on the wrong interface' fi echo '.' } static_start() { if [ -n "${static_arp_pairs}" ]; then echo -n 'Binding static ARP pair:' for e in ${static_arp_pairs}; do echo -n " ${e}" eval arp_args=\$arp_${e} arp -S ${arp_args} >/dev/null 2>&1 done echo '.' fi } static_stop() { if [ -n "${static_arp_pairs}" ]; then echo -n 'Unbinding static ARP pair:' for e in ${static_arp_pairs}; do echo -n " ${e}" eval arp_args=\$arp_${e} arp_args=`echo ${arp_args} | sed -e s,..:..:..:..:..:..,,g` arp -d ${arp_args} >/dev/null 2>&1 done echo '.' fi } load_rc_config $name run_rc_command "$1" --------------080003070301000505080207-- From owner-freebsd-current@FreeBSD.ORG Wed Jan 2 21:04:24 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 923A416A418 for ; Wed, 2 Jan 2008 21:04:24 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id A74DB13C45A for ; Wed, 2 Jan 2008 21:04:23 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JAAl5-00041q-9P for freebsd-current@freebsd.org; Wed, 02 Jan 2008 21:04:15 +0000 Received: from 89-172-55-17.adsl.net.t-com.hr ([89.172.55.17]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 02 Jan 2008 21:04:15 +0000 Received: from ivoras by 89-172-55-17.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 02 Jan 2008 21:04:15 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Wed, 02 Jan 2008 22:04:06 +0100 Lines: 223 Message-ID: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigC5F77083C0D896FAE604737F" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 89-172-55-17.adsl.net.t-com.hr User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) X-Enigmail-Version: 0.95.5 Sender: news Subject: FreeBSD on Asus EEE PC X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2008 21:04:24 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC5F77083C0D896FAE604737F Content-Type: multipart/mixed; boundary="------------060607070709070301020503" This is a multi-part message in MIME format. --------------060607070709070301020503 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, If anyone's interested, here's dmesg and pciconf for Asus' EEE PC. Apparently everything works except the network and the wireless cards. --------------060607070709070301020503 Content-Type: text/plain; name="eee-pciconf.txt" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="eee-pciconf.txt" aG9zdGIwQHBjaTA6MDowOgljbGFzcz0weDA2MDAwMCBjYXJkPTB4ODJkOTEwNDMgY2hpcD0w eDI1OTA4MDg2IHJldj0weDA0IGhkcj0weDAwCiAgICBjbGFzcyAgICA9IGJyaWRnZQogICAg c3ViY2xhc3MgPSBIT1NULVBDSQphZ3AwQHBjaTA6MjowOgljbGFzcz0weDAzMDAwMCBjYXJk PTB4ODJkOTEwNDMgY2hpcD0weDI1OTI4MDg2IHJldj0weDA0IGhkcj0weDAwCiAgICBjbGFz cyAgICA9IGRpc3BsYXkKICAgIHN1YmNsYXNzID0gVkdBCm5vbmUwQHBjaTA6MjoxOgljbGFz cz0weDAzODAwMCBjYXJkPTB4ODJkOTEwNDMgY2hpcD0weDI3OTI4MDg2IHJldj0weDA0IGhk cj0weDAwCiAgICBjbGFzcyAgICA9IGRpc3BsYXkKbm9uZTFAcGNpMDoyNzowOgljbGFzcz0w eDA0MDMwMCBjYXJkPTB4ODJhMTEwNDMgY2hpcD0weDI2Njg4MDg2IHJldj0weDA0IGhkcj0w eDAwCiAgICBjbGFzcyAgICA9IG11bHRpbWVkaWEKcGNpYjFAcGNpMDoyODowOgljbGFzcz0w eDA2MDQwMCBjYXJkPTB4MDAwMDAwNDAgY2hpcD0weDI2NjA4MDg2IHJldj0weDA0IGhkcj0w eDAxCiAgICBjbGFzcyAgICA9IGJyaWRnZQogICAgc3ViY2xhc3MgPSBQQ0ktUENJCnBjaWIy QHBjaTA6Mjg6MToJY2xhc3M9MHgwNjA0MDAgY2FyZD0weDAwMDAwMDQwIGNoaXA9MHgyNjYy ODA4NiByZXY9MHgwNCBoZHI9MHgwMQogICAgY2xhc3MgICAgPSBicmlkZ2UKICAgIHN1YmNs YXNzID0gUENJLVBDSQpwY2liM0BwY2kwOjI4OjI6CWNsYXNzPTB4MDYwNDAwIGNhcmQ9MHgw MDAwMDA0MCBjaGlwPTB4MjY2NDgwODYgcmV2PTB4MDQgaGRyPTB4MDEKICAgIGNsYXNzICAg ID0gYnJpZGdlCiAgICBzdWJjbGFzcyA9IFBDSS1QQ0kKdWhjaTBAcGNpMDoyOTowOgljbGFz cz0weDBjMDMwMCBjYXJkPTB4ODJkODEwNDMgY2hpcD0weDI2NTg4MDg2IHJldj0weDA0IGhk cj0weDAwCiAgICBjbGFzcyAgICA9IHNlcmlhbCBidXMKICAgIHN1YmNsYXNzID0gVVNCCnVo Y2kxQHBjaTA6Mjk6MToJY2xhc3M9MHgwYzAzMDAgY2FyZD0weDgyZDgxMDQzIGNoaXA9MHgy NjU5ODA4NiByZXY9MHgwNCBoZHI9MHgwMAogICAgY2xhc3MgICAgPSBzZXJpYWwgYnVzCiAg ICBzdWJjbGFzcyA9IFVTQgp1aGNpMkBwY2kwOjI5OjI6CWNsYXNzPTB4MGMwMzAwIGNhcmQ9 MHg4MmQ4MTA0MyBjaGlwPTB4MjY1YTgwODYgcmV2PTB4MDQgaGRyPTB4MDAKICAgIGNsYXNz ICAgID0gc2VyaWFsIGJ1cwogICAgc3ViY2xhc3MgPSBVU0IKdWhjaTNAcGNpMDoyOTozOglj bGFzcz0weDBjMDMwMCBjYXJkPTB4ODJkODEwNDMgY2hpcD0weDI2NWI4MDg2IHJldj0weDA0 IGhkcj0weDAwCiAgICBjbGFzcyAgICA9IHNlcmlhbCBidXMKICAgIHN1YmNsYXNzID0gVVNC CmVoY2kwQHBjaTA6Mjk6NzoJY2xhc3M9MHgwYzAzMjAgY2FyZD0weDgyZDgxMDQzIGNoaXA9 MHgyNjVjODA4NiByZXY9MHgwNCBoZHI9MHgwMAogICAgY2xhc3MgICAgPSBzZXJpYWwgYnVz CiAgICBzdWJjbGFzcyA9IFVTQgpwY2liNEBwY2kwOjMwOjA6CWNsYXNzPTB4MDYwNDAxIGNh cmQ9MHgwMDAwMDA1MCBjaGlwPTB4MjQ0ODgwODYgcmV2PTB4ZDQgaGRyPTB4MDEKICAgIGNs YXNzICAgID0gYnJpZGdlCiAgICBzdWJjbGFzcyA9IFBDSS1QQ0kKaXNhYjBAcGNpMDozMTow OgljbGFzcz0weDA2MDEwMCBjYXJkPTB4ODJkODEwNDMgY2hpcD0weDI2NDE4MDg2IHJldj0w eDA0IGhkcj0weDAwCiAgICBjbGFzcyAgICA9IGJyaWRnZQogICAgc3ViY2xhc3MgPSBQQ0kt SVNBCmF0YXBjaTBAcGNpMDozMToyOgljbGFzcz0weDAxMDE4MCBjYXJkPTB4ODJkODEwNDMg Y2hpcD0weDI2NTM4MDg2IHJldj0weDA0IGhkcj0weDAwCiAgICBjbGFzcyAgICA9IG1hc3Mg c3RvcmFnZQogICAgc3ViY2xhc3MgPSBBVEEKbm9uZTJAcGNpMDozMTozOgljbGFzcz0weDBj MDUwMCBjYXJkPTB4ODJkODEwNDMgY2hpcD0weDI2NmE4MDg2IHJldj0weDA0IGhkcj0weDAw CiAgICBjbGFzcyAgICA9IHNlcmlhbCBidXMKICAgIHN1YmNsYXNzID0gU01CdXMKbm9uZTNA cGNpMzowOjA6CWNsYXNzPTB4MDIwMDAwIGNhcmQ9MHg4MjMzMTA0MyBjaGlwPTB4MjA0ODE5 NjkgcmV2PTB4YTAgaGRyPTB4MDAKICAgIGNsYXNzICAgID0gbmV0d29yawogICAgc3ViY2xh c3MgPSBldGhlcm5ldAo= --------------060607070709070301020503 Content-Type: text/plain; name="eee-dmesg7.txt" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="eee-dmesg7.txt" Q29weXJpZ2h0IChjKSAxOTkyLTIwMDcgVGhlIEZyZWVCU0QgUHJvamVjdC4KQ29weXJpZ2h0 IChjKSAxOTc5LCAxOTgwLCAxOTgzLCAxOTg2LCAxOTg4LCAxOTg5LCAxOTkxLCAxOTkyLCAx OTkzLCAxOTk0CglUaGUgUmVnZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlh LiBBbGwgcmlnaHRzIHJlc2VydmVkLgpGcmVlQlNEIGlzIGEgcmVnaXN0ZXJlZCB0cmFkZW1h cmsgb2YgVGhlIEZyZWVCU0QgRm91bmRhdGlvbi4KRnJlZUJTRCA3LjAtQkVUQTQgIzE6IEZy aSBEZWMgIDcgMDE6Mzc6NTUgQ0VUIDIwMDcKICAgIHJvb3RAZmluc3RhbGwuY29zbW9zOi91 c3Ivb2JqL3Vzci9zcmMvc3lzL0dFTkVSSUMKVGltZWNvdW50ZXIgImk4MjU0IiBmcmVxdWVu Y3kgMTE5MzE4MiBIeiBxdWFsaXR5IDAKQ1BVOiBJbnRlbChSKSBDZWxlcm9uKFIpIE0gcHJv Y2Vzc29yICAgICAgICAgIDkwME1IeiAoNjMyLjU5LU1IeiA2ODYtY2xhc3MgQ1BVKQogIE9y aWdpbiA9ICJHZW51aW5lSW50ZWwiICBJZCA9IDB4NmQ2ICBTdGVwcGluZyA9IDYKICBGZWF0 dXJlcz0weGFmZTlmYmJmPEZQVSxWTUUsREUsUFNFLFRTQyxNU1IsTUNFLENYOCxBUElDLFNF UCxNVFJSLFBHRSxNQ0EsQ01PVixQQVQsQ0xGTFVTSCxEVFMsQUNQSSxNTVgsRlhTUixTU0Us U1NFMixTUyxUTSxQQkU+CnJlYWwgbWVtb3J5ICA9IDUyNzk1ODAxNiAoNTAzIE1CKQphdmFp bCBtZW1vcnkgPSA1MDI3MTAyNzIgKDQ3OSBNQikKQUNQSSBBUElDIFRhYmxlOiA8QSBNIEkg IE9FTUFQSUMgPgppb2FwaWMwIDxWZXJzaW9uIDIuMD4gaXJxcyAwLTIzIG9uIG1vdGhlcmJv YXJkCmtiZDEgYXQga2JkbXV4MAphdGhfaGFsOiAwLjkuMjAuMyAoQVI1MjEwLCBBUjUyMTEs IEFSNTIxMiwgUkY1MTExLCBSRjUxMTIsIFJGMjQxMywgUkY1NDEzKQphY3BpMDogPEEgTSBJ IE9FTVJTRFQ+IG9uIG1vdGhlcmJvYXJkCmFjcGkwOiBbSVRIUkVBRF0KYWNwaTA6IFBvd2Vy IEJ1dHRvbiAoZml4ZWQpCmFjcGkwOiByZXNlcnZhdGlvbiBvZiAwLCBhMDAwMCAoMykgZmFp bGVkCmFjcGkwOiByZXNlcnZhdGlvbiBvZiAxMDAwMDAsIDFmNzAwMDAwICgzKSBmYWlsZWQK VGltZWNvdW50ZXIgIkFDUEktc2FmZSIgZnJlcXVlbmN5IDM1Nzk1NDUgSHogcXVhbGl0eSA4 NTAKYWNwaV90aW1lcjA6IDwyNC1iaXQgdGltZXIgYXQgMy41Nzk1NDVNSHo+IHBvcnQgMHg4 MDgtMHg4MGIgb24gYWNwaTAKYWNwaV9lYzA6IDxFbWJlZGRlZCBDb250cm9sbGVyOiBHUEUg MHgxOD4gcG9ydCAweDYyLDB4NjYgb24gYWNwaTAKY3B1MDogPEFDUEkgQ1BVPiBvbiBhY3Bp MApwNHRjYzA6IDxDUFUgRnJlcXVlbmN5IFRoZXJtYWwgQ29udHJvbD4gb24gY3B1MApwY2li MDogPEFDUEkgSG9zdC1QQ0kgYnJpZGdlPiBwb3J0IDB4Y2Y4LTB4Y2ZmIG9uIGFjcGkwCnBj aTA6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIwCnZnYXBjaTA6IDxWR0EtY29tcGF0aWJsZSBk aXNwbGF5PiBwb3J0IDB4ZWMwMC0weGVjMDcgbWVtIDB4ZjdmMDAwMDAtMHhmN2Y3ZmZmZiww eGQwMDAwMDAwLTB4ZGZmZmZmZmYsMHhmN2VjMDAwMC0weGY3ZWZmZmZmIGlycSAxNiBhdCBk ZXZpY2UgMi4wIG9uIHBjaTAKYWdwMDogPEludGVsIDgyOTE1R00gKDkxNUdNIEdNQ0gpIFNW R0EgY29udHJvbGxlcj4gb24gdmdhcGNpMAphZ3AwOiBkZXRlY3RlZCA3OTMyayBzdG9sZW4g bWVtb3J5CmFncDA6IGFwZXJ0dXJlIHNpemUgaXMgMjU2TQp2Z2FwY2kxOiA8VkdBLWNvbXBh dGlibGUgZGlzcGxheT4gbWVtIDB4ZjdmODAwMDAtMHhmN2ZmZmZmZiBhdCBkZXZpY2UgMi4x IG9uIHBjaTAKcGNpMDogPG11bHRpbWVkaWE+IGF0IGRldmljZSAyNy4wIChubyBkcml2ZXIg YXR0YWNoZWQpCnBjaWIxOiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gaXJxIDE2IGF0IGRldmlj ZSAyOC4wIG9uIHBjaTAKcGNpNDogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjEKcGNpYjI6IDxB Q1BJIFBDSS1QQ0kgYnJpZGdlPiBpcnEgMTcgYXQgZGV2aWNlIDI4LjEgb24gcGNpMApwY2kz OiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liMgpwY2kzOiA8bmV0d29yaywgZXRoZXJuZXQ+IGF0 IGRldmljZSAwLjAgKG5vIGRyaXZlciBhdHRhY2hlZCkKcGNpYjM6IDxBQ1BJIFBDSS1QQ0kg YnJpZGdlPiBpcnEgMTggYXQgZGV2aWNlIDI4LjIgb24gcGNpMApwY2kxOiA8QUNQSSBQQ0kg YnVzPiBvbiBwY2liMwphdGgwOiA8QXRoZXJvcyA1NDI0LzI0MjQ+IG1lbSAweGZiZWYwMDAw LTB4ZmJlZmZmZmYgaXJxIDE4IGF0IGRldmljZSAwLjAgb24gcGNpMQphdGgwOiBbSVRIUkVB RF0KYXRoMDogdW5hYmxlIHRvIGF0dGFjaCBoYXJkd2FyZTsgSEFMIHN0YXR1cyAxMwpkZXZp Y2VfYXR0YWNoOiBhdGgwIGF0dGFjaCByZXR1cm5lZCA2CnVoY2kwOiA8SW50ZWwgODI4MDFG Qi9GUi9GVy9GUlcgKElDSDYpIFVTQiBjb250cm9sbGVyIFVTQi1BPiBwb3J0IDB4ZTQwMC0w eGU0MWYgaXJxIDIzIGF0IGRldmljZSAyOS4wIG9uIHBjaTAKdWhjaTA6IFtHSUFOVC1MT0NL RURdCnVoY2kwOiBbSVRIUkVBRF0KdXNiMDogPEludGVsIDgyODAxRkIvRlIvRlcvRlJXIChJ Q0g2KSBVU0IgY29udHJvbGxlciBVU0ItQT4gb24gdWhjaTAKdXNiMDogVVNCIHJldmlzaW9u IDEuMAp1aHViMDogPEludGVsIFVIQ0kgcm9vdCBodWIsIGNsYXNzIDkvMCwgcmV2IDEuMDAv MS4wMCwgYWRkciAxPiBvbiB1c2IwCnVodWIwOiAyIHBvcnRzIHdpdGggMiByZW1vdmFibGUs IHNlbGYgcG93ZXJlZAp1aGNpMTogPEludGVsIDgyODAxRkIvRlIvRlcvRlJXIChJQ0g2KSBV U0IgY29udHJvbGxlciBVU0ItQj4gcG9ydCAweGU0ODAtMHhlNDlmIGlycSAxOSBhdCBkZXZp Y2UgMjkuMSBvbiBwY2kwCnVoY2kxOiBbR0lBTlQtTE9DS0VEXQp1aGNpMTogW0lUSFJFQURd CnVzYjE6IDxJbnRlbCA4MjgwMUZCL0ZSL0ZXL0ZSVyAoSUNINikgVVNCIGNvbnRyb2xsZXIg VVNCLUI+IG9uIHVoY2kxCnVzYjE6IFVTQiByZXZpc2lvbiAxLjAKdWh1YjE6IDxJbnRlbCBV SENJIHJvb3QgaHViLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNi MQp1aHViMTogMiBwb3J0cyB3aXRoIDIgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKdWhjaTI6 IDxJbnRlbCA4MjgwMUZCL0ZSL0ZXL0ZSVyAoSUNINikgVVNCIGNvbnRyb2xsZXIgVVNCLUM+ IHBvcnQgMHhlODAwLTB4ZTgxZiBpcnEgMTggYXQgZGV2aWNlIDI5LjIgb24gcGNpMAp1aGNp MjogW0dJQU5ULUxPQ0tFRF0KdWhjaTI6IFtJVEhSRUFEXQp1c2IyOiA8SW50ZWwgODI4MDFG Qi9GUi9GVy9GUlcgKElDSDYpIFVTQiBjb250cm9sbGVyIFVTQi1DPiBvbiB1aGNpMgp1c2Iy OiBVU0IgcmV2aXNpb24gMS4wCnVodWIyOiA8SW50ZWwgVUhDSSByb290IGh1YiwgY2xhc3Mg OS8wLCByZXYgMS4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYjIKdWh1YjI6IDIgcG9ydHMgd2l0 aCAyIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCnVoY2kzOiA8SW50ZWwgODI4MDFGQi9GUi9G Vy9GUlcgKElDSDYpIFVTQiBjb250cm9sbGVyIFVTQi1EPiBwb3J0IDB4ZTg4MC0weGU4OWYg aXJxIDE2IGF0IGRldmljZSAyOS4zIG9uIHBjaTAKdWhjaTM6IFtHSUFOVC1MT0NLRURdCnVo Y2kzOiBbSVRIUkVBRF0KdXNiMzogPEludGVsIDgyODAxRkIvRlIvRlcvRlJXIChJQ0g2KSBV U0IgY29udHJvbGxlciBVU0ItRD4gb24gdWhjaTMKdXNiMzogVVNCIHJldmlzaW9uIDEuMAp1 aHViMzogPEludGVsIFVIQ0kgcm9vdCBodWIsIGNsYXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwg YWRkciAxPiBvbiB1c2IzCnVodWIzOiAyIHBvcnRzIHdpdGggMiByZW1vdmFibGUsIHNlbGYg cG93ZXJlZAplaGNpMDogPEludGVsIDgyODAxRkIgKElDSDYpIFVTQiAyLjAgY29udHJvbGxl cj4gbWVtIDB4ZjdlYjdjMDAtMHhmN2ViN2ZmZiBpcnEgMjMgYXQgZGV2aWNlIDI5Ljcgb24g cGNpMAplaGNpMDogW0dJQU5ULUxPQ0tFRF0KZWhjaTA6IFtJVEhSRUFEXQp1c2I0OiBFSENJ IHZlcnNpb24gMS4wCnVzYjQ6IGNvbXBhbmlvbiBjb250cm9sbGVycywgMiBwb3J0cyBlYWNo OiB1c2IwIHVzYjEgdXNiMiB1c2IzCnVzYjQ6IDxJbnRlbCA4MjgwMUZCIChJQ0g2KSBVU0Ig Mi4wIGNvbnRyb2xsZXI+IG9uIGVoY2kwCnVzYjQ6IFVTQiByZXZpc2lvbiAyLjAKdWh1YjQ6 IDxJbnRlbCBFSENJIHJvb3QgaHViLCBjbGFzcyA5LzAsIHJldiAyLjAwLzEuMDAsIGFkZHIg MT4gb24gdXNiNAp1aHViNDogOCBwb3J0cyB3aXRoIDggcmVtb3ZhYmxlLCBzZWxmIHBvd2Vy ZWQKdW1hc3MwOiA8QWNlciBNUDM0MCwgY2xhc3MgMC8wLCByZXYgMi4wMC8wLjMyLCBhZGRy IDI+IG9uIHVodWI0CnVtYXNzMDogR2V0IE1heCBMdW4gbm90IHN1cHBvcnRlZCAoU1RBTExF RCkKdW1hc3MxOiA8UExFWFRPUiBQTEVYVE9SIFVTQiBTdG9yYWdlIEFkYXB0ZXIsIGNsYXNz IDAvMCwgcmV2IDIuMDAvMS4wMSwgYWRkciAzPiBvbiB1aHViNAp1bWFzczI6IDxFTkUgVUI2 MjI1LCBjbGFzcyAwLzAsIHJldiAyLjAwLzEuMDAsIGFkZHIgND4gb24gdWh1YjQKcGNpYjQ6 IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMzAuMCBvbiBwY2kwCnBjaTU6IDxB Q1BJIFBDSSBidXM+IG9uIHBjaWI0CmlzYWIwOiA8UENJLUlTQSBicmlkZ2U+IGF0IGRldmlj ZSAzMS4wIG9uIHBjaTAKaXNhMDogPElTQSBidXM+IG9uIGlzYWIwCmF0YXBjaTA6IDxJbnRl bCBJQ0g2TSBTQVRBMTUwIGNvbnRyb2xsZXI+IHBvcnQgMHgxZjAtMHgxZjcsMHgzZjYsMHgx NzAtMHgxNzcsMHgzNzYsMHhmZmEwLTB4ZmZhZiBhdCBkZXZpY2UgMzEuMiBvbiBwY2kwCmF0 YTA6IDxBVEEgY2hhbm5lbCAwPiBvbiBhdGFwY2kwCmF0YTA6IFtJVEhSRUFEXQphdGExOiA8 QVRBIGNoYW5uZWwgMT4gb24gYXRhcGNpMAphdGExOiBbSVRIUkVBRF0KcGNpMDogPHNlcmlh bCBidXMsIFNNQnVzPiBhdCBkZXZpY2UgMzEuMyAobm8gZHJpdmVyIGF0dGFjaGVkKQphY3Bp X2xpZDA6IDxDb250cm9sIE1ldGhvZCBMaWQgU3dpdGNoPiBvbiBhY3BpMAphY3BpX2J1dHRv bjA6IDxTbGVlcCBCdXR0b24+IG9uIGFjcGkwCmFjcGlfYnV0dG9uMTogPFBvd2VyIEJ1dHRv bj4gb24gYWNwaTAKYWNwaV90ejA6IDxUaGVybWFsIFpvbmU+IG9uIGFjcGkwCmJhdHRlcnkw OiA8QUNQSSBDb250cm9sIE1ldGhvZCBCYXR0ZXJ5PiBvbiBhY3BpMAphY3BpX2FjYWQwOiA8 QUMgQWRhcHRlcj4gb24gYWNwaTAKYXRrYmRjMDogPEtleWJvYXJkIGNvbnRyb2xsZXIgKGk4 MDQyKT4gcG9ydCAweDYwLDB4NjQgaXJxIDEgb24gYWNwaTAKYXRrYmQwOiA8QVQgS2V5Ym9h cmQ+IGlycSAxIG9uIGF0a2JkYzAKa2JkMCBhdCBhdGtiZDAKYXRrYmQwOiBbR0lBTlQtTE9D S0VEXQphdGtiZDA6IFtJVEhSRUFEXQpwc20wOiA8UFMvMiBNb3VzZT4gaXJxIDEyIG9uIGF0 a2JkYzAKcHNtMDogW0dJQU5ULUxPQ0tFRF0KcHNtMDogW0lUSFJFQURdCnBzbTA6IG1vZGVs IEdlbmVyaWMgUFMvMiBtb3VzZSwgZGV2aWNlIElEIDAKcG10aW1lcjAgb24gaXNhMApvcm0w OiA8SVNBIE9wdGlvbiBST00+IGF0IGlvbWVtIDB4YzAwMDAtMHhjZjdmZiBwbnBpZCBPUk0w MDAwIG9uIGlzYTAKcHBjMDogcGFyYWxsZWwgcG9ydCBub3QgZm91bmQuCnNjMDogPFN5c3Rl bSBjb25zb2xlPiBhdCBmbGFncyAweDEwMCBvbiBpc2EwCnNjMDogVkdBIDwxNiB2aXJ0dWFs IGNvbnNvbGVzLCBmbGFncz0weDMwMD4Kc2lvMDogY29uZmlndXJlZCBpcnEgNCBub3QgaW4g Yml0bWFwIG9mIHByb2JlZCBpcnFzIDAKc2lvMDogcG9ydCBtYXkgbm90IGJlIGVuYWJsZWQK c2lvMDogY29uZmlndXJlZCBpcnEgNCBub3QgaW4gYml0bWFwIG9mIHByb2JlZCBpcnFzIDAK c2lvMDogcG9ydCBtYXkgbm90IGJlIGVuYWJsZWQKc2lvMCBhdCBwb3J0IDB4M2Y4LTB4M2Zm IGlycSA0IGZsYWdzIDB4MTAgb24gaXNhMApzaW8wOiB0eXBlIDgyNTAgb3Igbm90IHJlc3Bv bmRpbmcKc2lvMDogW0ZJTFRFUl0Kc2lvMTogY29uZmlndXJlZCBpcnEgMyBub3QgaW4gYml0 bWFwIG9mIHByb2JlZCBpcnFzIDAKc2lvMTogcG9ydCBtYXkgbm90IGJlIGVuYWJsZWQKdmdh MDogPEdlbmVyaWMgSVNBIFZHQT4gYXQgcG9ydCAweDNjMC0weDNkZiBpb21lbSAweGEwMDAw LTB4YmZmZmYgb24gaXNhMApUaW1lY291bnRlciAiVFNDIiBmcmVxdWVuY3kgNjMyNTg4NTUy IEh6IHF1YWxpdHkgODAwClRpbWVjb3VudGVycyB0aWNrIGV2ZXJ5IDEuMDAwIG1zZWMKYWQy OiBGQUlMVVJFIC0gU0VUX01VTFRJIHN0YXR1cz01MTxSRUFEWSxEU0MsRVJST1I+IGVycm9y PTQ8QUJPUlRFRD4KYWQyOiAzODE1TUIgPFNJTElDT05NT1RJT04gU00yMjNBQyA+IGF0IGF0 YTEtbWFzdGVyIFVETUE2NgpHRU9NX0xBQkVMOiBMYWJlbCBmb3IgcHJvdmlkZXIgYWQyczEg aXMgZXh0MmZzL1NZU1RFTS4KR0VPTV9MQUJFTDogTGFiZWwgZm9yIHByb3ZpZGVyIGFkMnMy IGlzIGV4dDJmcy9VU0VSLgpHRU9NX0xBQkVMOiBMYWJlbCBmb3IgcHJvdmlkZXIgYWQyczMg aXMgbXNkb3Nmcy9CSU9TLgpjZDAgYXQgdW1hc3Mtc2ltMSBidXMgMSB0YXJnZXQgMCBsdW4g MApjZDA6IDxQTEVYVE9SIERWRFIgICAgUFgtNjA4Q1UgMS40ND4gUmVtb3ZhYmxlIENELVJP TSBTQ1NJLTAgZGV2aWNlIApjZDA6IDQwLjAwME1CL3MgdHJhbnNmZXJzCmNkMDogY2QgcHJl c2VudCBbMjI4MzYxIHggMjA0OCBieXRlIHJlY29yZHNdCmRhMCBhdCB1bWFzcy1zaW0wIGJ1 cyAwIHRhcmdldCAwIGx1biAwCmRhMDogPEFjZXIgTVAzNDAgMS4wMD4gRml4ZWQgRGlyZWN0 IEFjY2VzcyBTQ1NJLTAgZGV2aWNlIApkYTA6IDQwLjAwME1CL3MgdHJhbnNmZXJzCmRhMDog MTkwNzNNQiAoMzkwNjMwMjQgNTEyIGJ5dGUgc2VjdG9yczogMjU1SCA2M1MvVCAyNDMxQykK ZGExIGF0IHVtYXNzLXNpbTIgYnVzIDIgdGFyZ2V0IDAgbHVuIDAKZGExOiA8VVNCMi4wIENh cmRSZWFkZXIgU0QwIDAxMDA+IFJlbW92YWJsZSBEaXJlY3QgQWNjZXNzIFNDU0ktMCBkZXZp Y2UgCmRhMTogNDAuMDAwTUIvcyB0cmFuc2ZlcnMKZGExOiBBdHRlbXB0IHRvIHF1ZXJ5IGRl dmljZSBzaXplIGZhaWxlZDogTk9UIFJFQURZLCBNZWRpdW0gbm90IHByZXNlbnQKR0VPTV9M QUJFTDogTGFiZWwgZm9yIHByb3ZpZGVyIGNkMCBpcyBpc285NjYwL0ZyZWVCU0Q3LgpHRU9N X0xBQkVMOiBMYWJlbCBmb3IgcHJvdmlkZXIgZGEwczEgaXMgbXNkb3Nmcy9BQ0VSIE1QMzQw LgpUcnlpbmcgdG8gbW91bnQgcm9vdCBmcm9tIGNkOTY2MDovZGV2L2lzbzk2NjAvRnJlZUJT RDcKbWQ2MC51emlwOiA0NDgwMCB4IDE2Mzg0IGJsb2NrcwppcGZ3MiAoK2lwdjYpIGluaXRp YWxpemVkLCBkaXZlcnQgbG9hZGFibGUsIHJ1bGUtYmFzZWQgZm9yd2FyZGluZyBkaXNhYmxl ZCwgZGVmYXVsdCB0byBkZW55LCBsb2dnaW5nIGRpc2FibGVkCkdFT01fTEFCRUw6IExhYmVs IG1zZG9zZnMvQUNFUiBNUDM0MCByZW1vdmVkLgo= --------------060607070709070301020503-- --------------enigC5F77083C0D896FAE604737F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHe/xGldnAQVacBcgRAh6kAJwOuiCrwympJQAbeA3WkfuJRaAO1QCguP1m QFwDKWZXSdVGduI/3/WS61o= =HLI9 -----END PGP SIGNATURE----- --------------enigC5F77083C0D896FAE604737F-- From owner-freebsd-current@FreeBSD.ORG Wed Jan 2 21:09:15 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 087DA16A468; Wed, 2 Jan 2008 21:09:15 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from smtp-3.dlr.de (smtp-3.dlr.de [195.37.61.187]) by mx1.freebsd.org (Postfix) with ESMTP id 9539A13C43E; Wed, 2 Jan 2008 21:09:12 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from [192.168.2.100] ([172.21.151.2]) by smtp-3.dlr.de with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 Jan 2008 21:55:55 +0100 Message-ID: <477BFA5C.60602@dlr.de> Date: Wed, 02 Jan 2008 21:55:56 +0100 From: Hartmut Brandt Organization: German Aerospace Center User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: d@delphij.net References: <477BE583.6080202@delphij.net> In-Reply-To: <477BE583.6080202@delphij.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Jan 2008 20:55:55.0480 (UTC) FILETIME=[DE3E3D80:01C84D81] Cc: FreeBSD Current , freebsd-rc@FreeBSD.org Subject: Re: [RFC] rc.d script for binding static arp pairs and logging options X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2008 21:09:15 -0000 Xin LI wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > Here is a rc.d script that I use on my own server, which provides two > functionalities: > > - Bind ARP pairs specified in rc.conf (*); Not having looked at the actual scripts just a comment: while the ARP and the routing tables are still unified, static arp entries can be done with the normal static_routes rc stuff. As far as I know this is going to change, so your script will be needed sooner or later. The functionality is needed for sure. harti > - Set ARP logging options (+). > > * Similar to routing settings, one need to set up some sort of "ARP > pairs" like this: > > static_arp_pairs="gw" > arp_gw="172.16.1.1 00:1c:58:6a:7b:49" > > + By setting one or more of the following options to "NO" it would set > appropriate sysctl for arp logging settings to zero to disable logging: > > log_arp_permanent_modify > log_arp_movements > log_arp_wrong_iface > > This script could be useful for those who use FreeBSD in a > uncontrollable network (i.e. your network administrator does not care > about viruses that attacks the network with fake ARP broadcasts). > > I wonder whether this script would be useful for general consumption? > Other comments are also welcome :-) > > Cheers, > - -- > Xin LI http://www.delphij.net/ > FreeBSD - The Power to Serve! > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.4 (FreeBSD) > > iD8DBQFHe+WCi+vbBBjt66ARAvA/AJ9zv5Wtif9DPgDPT89ZOOoueu+w9gCeK3gY > 4GEETsKg53j19QLFd3IZKkc= > =rLKv > -----END PGP SIGNATURE----- > > > ------------------------------------------------------------------------ > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Wed Jan 2 21:12:33 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 289CD16A469 for ; Wed, 2 Jan 2008 21:12:33 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.180]) by mx1.freebsd.org (Postfix) with ESMTP id F20E513C4F5 for ; Wed, 2 Jan 2008 21:12:32 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so9723400waf.3 for ; Wed, 02 Jan 2008 13:12:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=Ml5DwHspXGYG3CM0223SO7tUVB9Qxf7qVTU8XEqhAAY=; b=O1Fd3ZwABkOchOPeD9MvPsbDIUFEJQ5LqvIzm7ZUjdKf1JSK5eu9AtJ2MGlvJI12jLgUxpzSzgwZ6liO8HybFQu4x1y7BB68PUovUqqS9jDP4062dQh3TGRvVrOxcSBpcWctj2dLKhufxiSnZZIohfIZ1NW/y4iZPWejAyjP6C0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=KJesZoZ0CR7kBI67ukOi9YbzGSBo85v6ZjKhm9HKP8Vdr1nZDVTPpEzuX1VsZqPAgQ52l4mfR4q1MUGeZ3KrxJeDSSAx6u6vjfRq5tdW9viwu66WX1HMfnJ0mVMAF7hs6SZbwwDILvHEfJj4YYVhP2xSBsps3GkY+E43UlupN+s= Received: by 10.114.179.1 with SMTP id b1mr15304348waf.143.1199308351884; Wed, 02 Jan 2008 13:12:31 -0800 (PST) Received: by 10.114.255.11 with HTTP; Wed, 2 Jan 2008 13:12:31 -0800 (PST) Message-ID: Date: Wed, 2 Jan 2008 13:12:31 -0800 From: "Kip Macy" To: "Ivan Voras" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: Cc: freebsd-current@freebsd.org Subject: Re: FreeBSD on Asus EEE PC X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2008 21:12:33 -0000 Do you know what network chip it uses? -Kip On Jan 2, 2008 1:04 PM, Ivan Voras wrote: > Hi, > > If anyone's interested, here's dmesg and pciconf for Asus' EEE PC. > Apparently everything works except the network and the wireless cards. > > hostb0@pci0:0:0: class=0x060000 card=0x82d91043 chip=0x25908086 rev=0x04 hdr=0x00 > class = bridge > subclass = HOST-PCI > agp0@pci0:2:0: class=0x030000 card=0x82d91043 chip=0x25928086 rev=0x04 hdr=0x00 > class = display > subclass = VGA > none0@pci0:2:1: class=0x038000 card=0x82d91043 chip=0x27928086 rev=0x04 hdr=0x00 > class = display > none1@pci0:27:0: class=0x040300 card=0x82a11043 chip=0x26688086 rev=0x04 hdr=0x00 > class = multimedia > pcib1@pci0:28:0: class=0x060400 card=0x00000040 chip=0x26608086 rev=0x04 hdr=0x01 > class = bridge > subclass = PCI-PCI > pcib2@pci0:28:1: class=0x060400 card=0x00000040 chip=0x26628086 rev=0x04 hdr=0x01 > class = bridge > subclass = PCI-PCI > pcib3@pci0:28:2: class=0x060400 card=0x00000040 chip=0x26648086 rev=0x04 hdr=0x01 > class = bridge > subclass = PCI-PCI > uhci0@pci0:29:0: class=0x0c0300 card=0x82d81043 chip=0x26588086 rev=0x04 hdr=0x00 > class = serial bus > subclass = USB > uhci1@pci0:29:1: class=0x0c0300 card=0x82d81043 chip=0x26598086 rev=0x04 hdr=0x00 > class = serial bus > subclass = USB > uhci2@pci0:29:2: class=0x0c0300 card=0x82d81043 chip=0x265a8086 rev=0x04 hdr=0x00 > class = serial bus > subclass = USB > uhci3@pci0:29:3: class=0x0c0300 card=0x82d81043 chip=0x265b8086 rev=0x04 hdr=0x00 > class = serial bus > subclass = USB > ehci0@pci0:29:7: class=0x0c0320 card=0x82d81043 chip=0x265c8086 rev=0x04 hdr=0x00 > class = serial bus > subclass = USB > pcib4@pci0:30:0: class=0x060401 card=0x00000050 chip=0x24488086 rev=0xd4 hdr=0x01 > class = bridge > subclass = PCI-PCI > isab0@pci0:31:0: class=0x060100 card=0x82d81043 chip=0x26418086 rev=0x04 hdr=0x00 > class = bridge > subclass = PCI-ISA > atapci0@pci0:31:2: class=0x010180 card=0x82d81043 chip=0x26538086 rev=0x04 hdr=0x00 > class = mass storage > subclass = ATA > none2@pci0:31:3: class=0x0c0500 card=0x82d81043 chip=0x266a8086 rev=0x04 hdr=0x00 > class = serial bus > subclass = SMBus > none3@pci3:0:0: class=0x020000 card=0x82331043 chip=0x20481969 rev=0xa0 hdr=0x00 > class = network > subclass = ethernet > > Copyright (c) 1992-2007 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 is a registered trademark of The FreeBSD Foundation. > FreeBSD 7.0-BETA4 #1: Fri Dec 7 01:37:55 CET 2007 > root@finstall.cosmos:/usr/obj/usr/src/sys/GENERIC > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel(R) Celeron(R) M processor 900MHz (632.59-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0x6d6 Stepping = 6 > Features=0xafe9fbbf > real memory = 527958016 (503 MB) > avail memory = 502710272 (479 MB) > ACPI APIC Table: > ioapic0 irqs 0-23 on motherboard > kbd1 at kbdmux0 > ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) > acpi0: on motherboard > acpi0: [ITHREAD] > acpi0: Power Button (fixed) > acpi0: reservation of 0, a0000 (3) failed > acpi0: reservation of 100000, 1f700000 (3) failed > Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 > acpi_ec0: port 0x62,0x66 on acpi0 > cpu0: on acpi0 > p4tcc0: on cpu0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > vgapci0: port 0xec00-0xec07 mem 0xf7f00000-0xf7f7ffff,0xd0000000-0xdfffffff,0xf7ec0000-0xf7efffff irq 16 at device 2.0 on pci0 > agp0: on vgapci0 > agp0: detected 7932k stolen memory > agp0: aperture size is 256M > vgapci1: mem 0xf7f80000-0xf7ffffff at device 2.1 on pci0 > pci0: at device 27.0 (no driver attached) > pcib1: irq 16 at device 28.0 on pci0 > pci4: on pcib1 > pcib2: irq 17 at device 28.1 on pci0 > pci3: on pcib2 > pci3: at device 0.0 (no driver attached) > pcib3: irq 18 at device 28.2 on pci0 > pci1: on pcib3 > ath0: mem 0xfbef0000-0xfbefffff irq 18 at device 0.0 on pci1 > ath0: [ITHREAD] > ath0: unable to attach hardware; HAL status 13 > device_attach: ath0 attach returned 6 > uhci0: port 0xe400-0xe41f irq 23 at device 29.0 on pci0 > uhci0: [GIANT-LOCKED] > uhci0: [ITHREAD] > usb0: on uhci0 > usb0: USB revision 1.0 > uhub0: on usb0 > uhub0: 2 ports with 2 removable, self powered > uhci1: port 0xe480-0xe49f irq 19 at device 29.1 on pci0 > uhci1: [GIANT-LOCKED] > uhci1: [ITHREAD] > usb1: on uhci1 > usb1: USB revision 1.0 > uhub1: on usb1 > uhub1: 2 ports with 2 removable, self powered > uhci2: port 0xe800-0xe81f irq 18 at device 29.2 on pci0 > uhci2: [GIANT-LOCKED] > uhci2: [ITHREAD] > usb2: on uhci2 > usb2: USB revision 1.0 > uhub2: on usb2 > uhub2: 2 ports with 2 removable, self powered > uhci3: port 0xe880-0xe89f irq 16 at device 29.3 on pci0 > uhci3: [GIANT-LOCKED] > uhci3: [ITHREAD] > usb3: on uhci3 > usb3: USB revision 1.0 > uhub3: on usb3 > uhub3: 2 ports with 2 removable, self powered > ehci0: mem 0xf7eb7c00-0xf7eb7fff irq 23 at device 29.7 on pci0 > ehci0: [GIANT-LOCKED] > ehci0: [ITHREAD] > usb4: EHCI version 1.0 > usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 > usb4: on ehci0 > usb4: USB revision 2.0 > uhub4: on usb4 > uhub4: 8 ports with 8 removable, self powered > umass0: on uhub4 > umass0: Get Max Lun not supported (STALLED) > umass1: on uhub4 > umass2: on uhub4 > pcib4: at device 30.0 on pci0 > pci5: on pcib4 > isab0: at device 31.0 on pci0 > isa0: on isab0 > atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 31.2 on pci0 > ata0: on atapci0 > ata0: [ITHREAD] > ata1: on atapci0 > ata1: [ITHREAD] > pci0: at device 31.3 (no driver attached) > acpi_lid0: on acpi0 > acpi_button0: on acpi0 > acpi_button1: on acpi0 > acpi_tz0: on acpi0 > battery0: on acpi0 > acpi_acad0: on acpi0 > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > atkbd0: [ITHREAD] > psm0: irq 12 on atkbdc0 > psm0: [GIANT-LOCKED] > psm0: [ITHREAD] > psm0: model Generic PS/2 mouse, device ID 0 > pmtimer0 on isa0 > orm0: at iomem 0xc0000-0xcf7ff pnpid ORM0000 on isa0 > ppc0: parallel port not found. > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=0x300> > sio0: configured irq 4 not in bitmap of probed irqs 0 > sio0: port may not be enabled > sio0: configured irq 4 not in bitmap of probed irqs 0 > sio0: port may not be enabled > sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 > sio0: type 8250 or not responding > sio0: [FILTER] > sio1: configured irq 3 not in bitmap of probed irqs 0 > sio1: port may not be enabled > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > Timecounter "TSC" frequency 632588552 Hz quality 800 > Timecounters tick every 1.000 msec > ad2: FAILURE - SET_MULTI status=51 error=4 > ad2: 3815MB at ata1-master UDMA66 > GEOM_LABEL: Label for provider ad2s1 is ext2fs/SYSTEM. > GEOM_LABEL: Label for provider ad2s2 is ext2fs/USER. > GEOM_LABEL: Label for provider ad2s3 is msdosfs/BIOS. > cd0 at umass-sim1 bus 1 target 0 lun 0 > cd0: Removable CD-ROM SCSI-0 device > cd0: 40.000MB/s transfers > cd0: cd present [228361 x 2048 byte records] > da0 at umass-sim0 bus 0 target 0 lun 0 > da0: Fixed Direct Access SCSI-0 device > da0: 40.000MB/s transfers > da0: 19073MB (39063024 512 byte sectors: 255H 63S/T 2431C) > da1 at umass-sim2 bus 2 target 0 lun 0 > da1: Removable Direct Access SCSI-0 device > da1: 40.000MB/s transfers > da1: Attempt to query device size failed: NOT READY, Medium not present > GEOM_LABEL: Label for provider cd0 is iso9660/FreeBSD7. > GEOM_LABEL: Label for provider da0s1 is msdosfs/ACER MP340. > Trying to mount root from cd9660:/dev/iso9660/FreeBSD7 > md60.uzip: 44800 x 16384 blocks > ipfw2 (+ipv6) initialized, divert loadable, rule-based forwarding disabled, default to deny, logging disabled > GEOM_LABEL: Label msdosfs/ACER MP340 removed. > > From owner-freebsd-current@FreeBSD.ORG Wed Jan 2 21:12:43 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 925E016A4CD for ; Wed, 2 Jan 2008 21:12:43 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 48B5C13C4CE for ; Wed, 2 Jan 2008 21:12:43 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JAAtC-0004UJ-OW for freebsd-current@freebsd.org; Wed, 02 Jan 2008 21:12:38 +0000 Received: from 89-172-55-17.adsl.net.t-com.hr ([89.172.55.17]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 02 Jan 2008 21:12:38 +0000 Received: from ivoras by 89-172-55-17.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 02 Jan 2008 21:12:38 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Wed, 02 Jan 2008 22:12:26 +0100 Lines: 29 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig0CD27F661B30024D58DE074E" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 89-172-55-17.adsl.net.t-com.hr User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) In-Reply-To: X-Enigmail-Version: 0.95.5 Sender: news Subject: Re: FreeBSD on Asus EEE PC X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2008 21:12:43 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0CD27F661B30024D58DE074E Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ivan Voras wrote: > Apparently everything works except the network and the wireless cards. =2E.. the intended meaning was "everything I expected to work". The video= camera obviously doesn't work, but I think audio should, if it's AC97. --------------enig0CD27F661B30024D58DE074E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHe/46ldnAQVacBcgRAn31AKDPhyEBHYrQyJtgicvOjhL1pRHn+gCgpDEf 6fHmvk94IR6K5cHBXwl+zKQ= =gDo2 -----END PGP SIGNATURE----- --------------enig0CD27F661B30024D58DE074E-- From owner-freebsd-current@FreeBSD.ORG Wed Jan 2 21:26:20 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1F22B16A418 for ; Wed, 2 Jan 2008 21:26:20 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id BAEFA13C478 for ; Wed, 2 Jan 2008 21:26:19 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JAB6N-0005GH-UW for freebsd-current@freebsd.org; Wed, 02 Jan 2008 21:26:16 +0000 Received: from 89-172-55-17.adsl.net.t-com.hr ([89.172.55.17]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 02 Jan 2008 21:26:15 +0000 Received: from ivoras by 89-172-55-17.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 02 Jan 2008 21:26:15 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Wed, 02 Jan 2008 22:26:06 +0100 Lines: 44 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig65C56630FD85D32B88B60F4C" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 89-172-55-17.adsl.net.t-com.hr User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) In-Reply-To: X-Enigmail-Version: 0.95.5 Sender: news Subject: Re: FreeBSD on Asus EEE PC X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2008 21:26:20 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig65C56630FD85D32B88B60F4C Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Kip Macy wrote: > Do you know what network chip it uses? Not exactly, but apparently it's very well supported under Linux and Windows since Google doesn't find anything useful on the topic. I found this in the Linux drivers' source code: * Copyright(c) 2007 Atheros Corporation. All rights reserved. * Copyright(c) 2006 xiong huang * * Derived from Intel e1000 driver * Copyright(c) 1999 - 2005 Intel Corporation. All rights reserved. The Linux driver is here: http://support.asus.com/download/download.aspx?SLanguage=3Den-us&model=3D= Eee%20PC%204G(701)&type=3Dmap&mapindex=3D8 (atl2_1.0.40.4-4.tar.gz) I don't have the device anymore but will probably have it in a few weeks.= --------------enig65C56630FD85D32B88B60F4C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHfAFvldnAQVacBcgRAs+BAKD2UJpE7hdIfkrmrokVpoSectf/2wCbBCjR UxV4ENALh8kgZH1VymnP650= =2owL -----END PGP SIGNATURE----- --------------enig65C56630FD85D32B88B60F4C-- From owner-freebsd-current@FreeBSD.ORG Wed Jan 2 21:59:18 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 817DF16A468 for ; Wed, 2 Jan 2008 21:59:18 +0000 (UTC) (envelope-from emaste@freebsd.org) Received: from gw.sandvine.com (gw.sandvine.com [199.243.201.138]) by mx1.freebsd.org (Postfix) with ESMTP id 2FADE13C468 for ; Wed, 2 Jan 2008 21:59:18 +0000 (UTC) (envelope-from emaste@freebsd.org) Received: from labgw2.phaedrus.sandvine.com ([192.168.3.11]) by gw.sandvine.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Jan 2008 16:58:15 -0500 Received: by labgw2.phaedrus.sandvine.com (Postfix, from userid 12627) id 815BD11717; Wed, 2 Jan 2008 16:58:15 -0500 (EST) Date: Wed, 2 Jan 2008 16:58:15 -0500 From: Ed Maste To: Ivan Voras Message-ID: <20080102215815.GA46732@sandvine.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-OriginalArrivalTime: 02 Jan 2008 21:58:15.0727 (UTC) FILETIME=[939AA3F0:01C84D8A] Cc: freebsd-current@freebsd.org Subject: Re: FreeBSD on Asus EEE PC X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2008 21:59:18 -0000 On Wed, Jan 02, 2008 at 10:26:06PM +0100, Ivan Voras wrote: > Kip Macy wrote: > > Do you know what network chip it uses? > > Not exactly, but apparently it's very well supported under Linux and > Windows since Google doesn't find anything useful on the topic. > > I found this in the Linux drivers' source code: > > * Copyright(c) 2007 Atheros Corporation. All rights reserved. > * Copyright(c) 2006 xiong huang > * > * Derived from Intel e1000 driver > * Copyright(c) 1999 - 2005 Intel Corporation. All rights reserved. The chip is an Atheros (formerly Attansic) L2. Even though it claims to be derived from the e1000 driver, I believe they just used it as a reference on writing Linux device drivers; I don't think it's really related to the e1000 hardware at all. -Ed From owner-freebsd-current@FreeBSD.ORG Wed Jan 2 22:49:21 2008 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 23B3816A4D8 for ; Wed, 2 Jan 2008 22:49:21 +0000 (UTC) (envelope-from marcus@FreeBSD.org) Received: from creme-brulee.marcuscom.com (marcuscom-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::1279]) by mx1.freebsd.org (Postfix) with ESMTP id CFF3213C474 for ; Wed, 2 Jan 2008 22:49:20 +0000 (UTC) (envelope-from marcus@FreeBSD.org) Received: from [IPv6:2001:470:1f00:2464::4] (shumai.marcuscom.com [IPv6:2001:470:1f00:2464::4]) by creme-brulee.marcuscom.com (8.14.2/8.14.2) with ESMTP id m02MoCxi090856 for ; Wed, 2 Jan 2008 17:50:12 -0500 (EST) (envelope-from marcus@FreeBSD.org) From: Joe Marcus Clarke To: current Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-Uw68W24xTpRE9V9KVVT5" Organization: FreeBSD, Inc. Date: Wed, 02 Jan 2008 17:49:26 -0500 Message-Id: <1199314166.9913.63.camel@shumai.marcuscom.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.2 FreeBSD GNOME Team Port X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,NO_RELAYS autolearn=ham version=3.2.3 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on creme-brulee.marcuscom.com Cc: Subject: Memory problem with latest malloc.c X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2008 22:49:21 -0000 --=-Uw68W24xTpRE9V9KVVT5 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable GNOME applications use a Python driven XML parser to generate help document translations. The engine takes the English XML document and applies translations to it. The tool, xml2po, is installed as part of textproc/gnome-doc-utils. I'm currently working on porting GNOME 2.21, and one of the Evolution help doc changes triggered a memory problem on my test machine. Basically, with up to and including rev 1.154 of malloc.c, I am able to generate the help file with no errors. With all later revs including 1.160, the Python process balloons up to about 512 MB of memory, then dies. The only malloc config I've done is symlink Aj to /etc/malloc.conf. I'd be happy to provide the file an exact command used, but it might be easier to let me know if there's any debugging I could provide that would help here. Joe --=20 Joe Marcus Clarke FreeBSD GNOME Team :: gnome@FreeBSD.org FreeNode / #freebsd-gnome http://www.FreeBSD.org/gnome --=-Uw68W24xTpRE9V9KVVT5 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQBHfBT2b2iPiv4Uz4cRAkWxAKCA4ALJnvN4O6FhzejfRimeB5o7xQCfQ3cR b1uMPGtzUm9Vz7xpRMuO07g= =lVtU -----END PGP SIGNATURE----- --=-Uw68W24xTpRE9V9KVVT5-- From owner-freebsd-current@FreeBSD.ORG Wed Jan 2 22:54:29 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EDFD716A417; Wed, 2 Jan 2008 22:54:29 +0000 (UTC) (envelope-from drosih@rpi.edu) Received: from smtp5.server.rpi.edu (smtp5.server.rpi.edu [128.113.2.225]) by mx1.freebsd.org (Postfix) with ESMTP id 98F2E13C46A; Wed, 2 Jan 2008 22:54:29 +0000 (UTC) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp5.server.rpi.edu (8.13.1/8.13.1) with ESMTP id m02LpFqF028303; Wed, 2 Jan 2008 16:51:15 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Wed, 2 Jan 2008 16:51:14 -0500 To: "Kip Macy" , "Ivan Voras" From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-RPI-SA-Score: undef - spam scanning disabled X-CanItPRO-Stream: default X-Canit-Stats-ID: Bayes signature not available X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.113.2.225 Cc: freebsd-current@freebsd.org Subject: Re: FreeBSD on Asus EEE PC X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2008 22:54:30 -0000 At 1:12 PM -0800 1/2/08, Kip Macy wrote: >Do you know what network chip it uses? > > -Kip One of my friends has an Eee with freebsd working on it. I believe he had to do some work to get the network card running, but he has it working okay now. I'll see if he's following this mailing list. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu From owner-freebsd-current@FreeBSD.ORG Thu Jan 3 00:00:28 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DDE3916A419 for ; Thu, 3 Jan 2008 00:00:28 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.180]) by mx1.freebsd.org (Postfix) with ESMTP id A787613C458 for ; Thu, 3 Jan 2008 00:00:28 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so9803051waf.3 for ; Wed, 02 Jan 2008 16:00:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; bh=2FJjS2Vdv/ssQwI3l1nXP4oa4jyhHRvoywYP+BdlNG4=; b=TDfWRC1JdXc4GcFjdEmgzRzKWQuvCtR/IB+X9hoCeWVuB1M9fE8Pza0OlAxDxOBo9JpD24sBPjD58PW/7zYix2bpIoTlaWB2wu5KW8Jfnfw7UniUYeAw19zXFDszMQm2qZ5aoUacQoC/2ig1QrXzyxZugUi7x4rtfcQffrmpUvQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=to6JW7FcpQ8UQPz3KquiiiJzFLwkDvL0otUNT5K7Zbc1zaDYU7U/aB8Cv1GAppFELRhQ01daaRCJVygiQ8Zwn+HdyYyoJKeYz8IefIu8obMrfKVUAcgOFCJm6VzwC4cUeTf55/Yx5y01wXhI2bB5bK3HFp4s3JrbOa+gx2isfsk= Received: by 10.114.123.1 with SMTP id v1mr2103679wac.147.1199318427964; Wed, 02 Jan 2008 16:00:27 -0800 (PST) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTPS id n38sm24939561wag.2.2008.01.02.16.00.24 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 02 Jan 2008 16:00:27 -0800 (PST) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id m02NvxQY031839 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Jan 2008 08:57:59 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id m02Nvx3j031838; Thu, 3 Jan 2008 08:57:59 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Thu, 3 Jan 2008 08:57:59 +0900 From: Pyun YongHyeon To: Ivan Voras Message-ID: <20080102235759.GA31644@cdnetworks.co.kr> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org Subject: Re: FreeBSD on Asus EEE PC X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2008 00:00:28 -0000 On Wed, Jan 02, 2008 at 10:26:06PM +0100, Ivan Voras wrote: > Kip Macy wrote: > > Do you know what network chip it uses? > > Not exactly, but apparently it's very well supported under Linux and > Windows since Google doesn't find anything useful on the topic. > > I found this in the Linux drivers' source code: > > * Copyright(c) 2007 Atheros Corporation. All rights reserved. > * Copyright(c) 2006 xiong huang > * > * Derived from Intel e1000 driver > * Copyright(c) 1999 - 2005 Intel Corporation. All rights reserved. > > The Linux driver is here: > > http://support.asus.com/download/download.aspx?SLanguage=en-us&model=Eee%20PC%204G(701)&type=map&mapindex=8 > (atl2_1.0.40.4-4.tar.gz) > > I don't have the device anymore but will probably have it in a few weeks. > AFAIK kevlo@(Kevin Lo) is working on Attansic L1. Not sure his driver also supports fast ethernet version(Attansic F2). I don't know current status of the driver but it seems that he has a working driver. Btw, you can also use a NDIS mini port driver until native driver hits tree. -- Regards, Pyun YongHyeon From owner-freebsd-current@FreeBSD.ORG Thu Jan 3 00:42:29 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 38FA616A419 for ; Thu, 3 Jan 2008 00:42:29 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.176]) by mx1.freebsd.org (Postfix) with ESMTP id 5E9A213C458 for ; Thu, 3 Jan 2008 00:42:28 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so9829984waf.3 for ; Wed, 02 Jan 2008 16:42:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; bh=KaWTnSi3jAgMo/AbTMJgC3lP8J9aS71DmLf5L/Nbid8=; b=c5IQY5hWIHeqAKmVF9oOJts1TLKonBQalNzBb8nozftJJ1kdDibzItkYIV0zcb0eedGO1+ouoC0jK+2FgvzZ2jY0WEM2Bci460/CwBsvi4WaOBnYSsW70hKXXqw1uLDdDR6qS0RWMVyuFmEoHBDHwuekmnpG7XEccn6F/gd0Y1I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=Yc2No28zT9bOnlbkyr023UNj4Zabx+zZkRW8+baJ6lejK4B0pTb+pngN15dj3RykmuLyHkRn5XbiMOJKLtGHi/zkyEA4smBv4DNlEhmF4dh3uJnUaVbNE3wuqDEAELiOwNUHUmN2PCH/hSwRSbfrSdR950DVwJK7X1G+AgnNgVI= Received: by 10.114.37.1 with SMTP id k1mr14418112wak.6.1199320947762; Wed, 02 Jan 2008 16:42:27 -0800 (PST) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTPS id v37sm17568264wah.12.2008.01.02.16.42.22 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 02 Jan 2008 16:42:26 -0800 (PST) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id m030dcaU032016 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Jan 2008 09:39:38 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id m030dbRr032015; Thu, 3 Jan 2008 09:39:37 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Thu, 3 Jan 2008 09:39:37 +0900 From: Pyun YongHyeon To: Garance A Drosihn Message-ID: <20080103003937.GB31644@cdnetworks.co.kr> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: Kip Macy , freebsd-current@freebsd.org, Ivan Voras Subject: Re: FreeBSD on Asus EEE PC X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2008 00:42:29 -0000 On Wed, Jan 02, 2008 at 04:51:14PM -0500, Garance A Drosihn wrote: > At 1:12 PM -0800 1/2/08, Kip Macy wrote: > >Do you know what network chip it uses? > > > > -Kip > > One of my friends has an Eee with freebsd working on it. I believe > he had to do some work to get the network card running, but he has > it working okay now. I'll see if he's following this mailing list. > I'm also interesting in Atheros(Attansic) PHY. One user reported nfe(4) stability issues on CURRENT and I noticed the PHY was made by Atheros. http://lists.freebsd.org/pipermail/freebsd-current/2007-December/081560.html I even wrote a simple PHY driver for it but I need more information for the PHY hardware. You can get a latest atphy(4) at the following URL. The PHY driver doesn't take care of fast ethernet PHY so it needs more work.(Note, I don't have any Attansic hardwares so it's guess work and it may not even work at all.) http://people.freebsd.org/~yongari/atphy.diff -- Regards, Pyun YongHyeon From owner-freebsd-current@FreeBSD.ORG Wed Jan 2 23:13:37 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AFF4F16A41A; Wed, 2 Jan 2008 23:13:37 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (lefty.soaustin.net [66.135.55.46]) by mx1.freebsd.org (Postfix) with ESMTP id 9044513C448; Wed, 2 Jan 2008 23:13:37 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: by mail.soaustin.net (Postfix, from userid 502) id 4AD468C10A; Wed, 2 Jan 2008 17:13:37 -0600 (CST) Date: Wed, 2 Jan 2008 17:13:37 -0600 To: freebsd-stable@FreeBSD.org, freebsd-current@FreeBSD.org Message-ID: <20080102231337.GC5172@soaustin.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) From: linimon@lonesome.com (Mark Linimon) X-Mailman-Approved-At: Thu, 03 Jan 2008 01:03:11 +0000 Cc: linimon@FreeBSD.org Subject: HEADSUP: new wiki page: State of Packages on Sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: linimon@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2008 23:13:37 -0000 I've just posted a message with that title to sparc64@ with crosspost to ports@. If you're interested in deciding on where we're going with sparc64, I invite you to join that thread. (Please don't reply to this message; 2 lists is probably one too many). mcl From owner-freebsd-current@FreeBSD.ORG Thu Jan 3 01:36:11 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A608416A419 for ; Thu, 3 Jan 2008 01:36:11 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.178]) by mx1.freebsd.org (Postfix) with ESMTP id 0D26D13C461 for ; Thu, 3 Jan 2008 01:36:10 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so9861271waf.3 for ; Wed, 02 Jan 2008 17:36:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=BHum5ecSuowLg1BbfOV8neI2cHvy+rJGIHz5ZIKhx84=; b=EHMOFxRLJBUDmNQeIeA44A2l9ZNePBrawtaB3xjf0jzucrEyQM1BiVXsaviIrmucHIKe3L3fuTOgfA3TJnF/neOupghUo90BjuVs9SgcuIJBSdUSDBxC4tiaoIVPeLhRLbKhlGE+2WZpyOl0esbL6R3fnrcuyqR9uFYidtw1gBU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=A1fEPKheKeHucOlNTVVX+zncEd6nSgFhJgalFtTa3hs8BzZOIo3VkM2EWBlg3wFemNntz11Wkf7nFcBfQ6XuccRuYNAmdoxPfbC5Qsd/iAz/URMqXSbLRKS8IF06MIKNoNCZ4Jbca6H5iF4W9CTG8FnYntHj4bsZH+uk8rSxz50= Received: by 10.142.154.20 with SMTP id b20mr4355611wfe.172.1199324170528; Wed, 02 Jan 2008 17:36:10 -0800 (PST) Received: by 10.142.162.20 with HTTP; Wed, 2 Jan 2008 17:36:10 -0800 (PST) Message-ID: Date: Thu, 3 Jan 2008 09:36:10 +0800 From: "Sepherosa Ziehau" To: "=?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?=" In-Reply-To: <86prwkqk22.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <86ir2hznnd.fsf@ds4.des.no> <86abnpu0wv.fsf@ds4.des.no> <86prwkqk22.fsf@ds4.des.no> Cc: kevlo@freebsd.org, sam@freebsd.org, current@freebsd.org, net@freebsd.org Subject: Re: if_ral regression X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2008 01:36:11 -0000 On Jan 3, 2008 12:16 AM, Dag-Erling Sm=F8rgrav wrote: > "Sepherosa Ziehau" writes: > > http://people.freebsd.org/~sephe/rt2560_test.diff > > Thank you, I'll try that. > > Could you explain what the RT2560_BBP_BUSY loop is about? bbp read involves one write to RT2560_BBPCSR, while this register should not be touched until its RT2560_BBP_BUSY bit is off (as according to Ralink's linux driver) Best Regards, sephe --=20 Live Free or Die From owner-freebsd-current@FreeBSD.ORG Thu Jan 3 02:12:14 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A032616A418; Thu, 3 Jan 2008 02:12:14 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.delphij.net (delphij-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:2c9::2]) by mx1.freebsd.org (Postfix) with ESMTP id 41D7A13C44B; Thu, 3 Jan 2008 02:12:14 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (unknown [202.108.54.204]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.delphij.net (Postfix) with ESMTP id 6119A28448; Thu, 3 Jan 2008 10:12:12 +0800 (CST) Received: from localhost (unknown [202.108.54.204]) by tarsier.geekcn.org (Postfix) with ESMTP id 06C75EC4773; Thu, 3 Jan 2008 10:12:12 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([202.108.54.204]) by localhost (mail.geekcn.org [202.108.54.204]) (amavisd-new, port 10024) with ESMTP id g6nYOkLk6aXG; Thu, 3 Jan 2008 10:12:07 +0800 (CST) Received: from charlie.delphij.net (71.5.7.139.ptr.us.xo.net [71.5.7.139]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id 14038EB092A; Thu, 3 Jan 2008 10:12:05 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=kl25voxycPHbjGGgAMN6WbAbSuAINSAxC/htbTtSpP5JLLJNB0Ip9AXCyMus3+yPH 8LgjqEeIoiwSByYGMua5w== Message-ID: <477C4474.3000702@delphij.net> Date: Wed, 02 Jan 2008 18:12:04 -0800 From: Xin LI Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.9 (X11/20071125) MIME-Version: 1.0 To: Pawel Worach References: <477BE583.6080202@delphij.net> <477C423F.2020701@gmail.com> In-Reply-To: <477C423F.2020701@gmail.com> X-Enigmail-Version: 0.95.5 OpenPGP: id=18EDEBA0; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-rc@FreeBSD.org, FreeBSD Current , d@delphij.net Subject: Re: [RFC] rc.d script for binding static arp pairs and logging options X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2008 02:12:14 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Pawel Worach wrote: > Xin LI wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hi, >> >> Here is a rc.d script that I use on my own server, which provides two >> functionalities: >> >> - Bind ARP pairs specified in rc.conf (*); >> - Set ARP logging options (+). >> > > What about ethers(5) and arp -f, would that potentially pollute the arp > table with too much junk ? I think ethers(5) is designed for some other uses, i.e. it serves like hosts(5). It sounds like a good idea to utilize arp -f, do we have some easy way to unbind the pairs if we don't want -d -a? (Or we should not even bother to think about it?) Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHfER0i+vbBBjt66ARAktoAKDA58+Iq+0rPZq9e0uZsIIhNWO+DgCcCHrF /c/wj0lrdDaCOMc3rH9QNEw= =k0Lj -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Thu Jan 3 02:17:15 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 71FA716A41B for ; Thu, 3 Jan 2008 02:17:15 +0000 (UTC) (envelope-from kevlo@kevlo.org) Received: from ns.kevlo.org (kevlo.org [220.128.136.52]) by mx1.freebsd.org (Postfix) with ESMTP id 0B09713C468 for ; Thu, 3 Jan 2008 02:17:14 +0000 (UTC) (envelope-from kevlo@kevlo.org) Received: from [127.0.0.1] (kevlo.org [220.128.136.52]) (authenticated bits=0) by ns.kevlo.org (8.14.1/8.14.1) with ESMTP id m032G76Z039724; Thu, 3 Jan 2008 10:16:12 +0800 (CST) (envelope-from kevlo@kevlo.org) From: Kevin Lo To: pyunyh@gmail.com In-Reply-To: <20080102235759.GA31644@cdnetworks.co.kr> References: <20080102235759.GA31644@cdnetworks.co.kr> Content-Type: text/plain Date: Thu, 03 Jan 2008 10:17:14 +0800 Message-Id: <1199326634.6153.27.camel@monet> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Ivan Voras Subject: Re: FreeBSD on Asus EEE PC X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2008 02:17:15 -0000 Pyun YongHyeon wrote: > On Wed, Jan 02, 2008 at 10:26:06PM +0100, Ivan Voras wrote: > > Kip Macy wrote: > > > Do you know what network chip it uses? > > > > Not exactly, but apparently it's very well supported under Linux and > > Windows since Google doesn't find anything useful on the topic. > > > > I found this in the Linux drivers' source code: > > > > * Copyright(c) 2007 Atheros Corporation. All rights reserved. > > * Copyright(c) 2006 xiong huang > > * > > * Derived from Intel e1000 driver > > * Copyright(c) 1999 - 2005 Intel Corporation. All rights reserved. > > > > The Linux driver is here: > > > > http://support.asus.com/download/download.aspx?SLanguage=en-us&model=Eee%20PC%204G(701)&type=map&mapindex=8 > > (atl2_1.0.40.4-4.tar.gz) > > > > I don't have the device anymore but will probably have it in a few weeks. > > > > AFAIK kevlo@(Kevin Lo) is working on Attansic L1. Not sure his driver > also supports fast ethernet version(Attansic F2). I don't know current > status of the driver but it seems that he has a working driver. > Btw, you can also use a NDIS mini port driver until native driver hits > tree. Yes, I worked on Attansic L1 driver which was based on Linux atl1 driver. I sent my patch to Alex Lukin four months ago: http://unix.derkeiler.com/Mailing-Lists/FreeBSD/hackers/2007-09/msg00081.html Don't know whether he is still working on it or not. If not, I'll finish it :-) Kevin From owner-freebsd-current@FreeBSD.ORG Thu Jan 3 02:28:48 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 91B9116A41B for ; Thu, 3 Jan 2008 02:28:48 +0000 (UTC) (envelope-from pawel.worach@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.171]) by mx1.freebsd.org (Postfix) with ESMTP id 2171313C455 for ; Thu, 3 Jan 2008 02:28:47 +0000 (UTC) (envelope-from pawel.worach@gmail.com) Received: by ug-out-1314.google.com with SMTP id y2so3383131uge.37 for ; Wed, 02 Jan 2008 18:28:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=jngmgar7AhW9lKpHvJX8BBy5fZimqWFK6mWuljENo/M=; b=m6qs86VwXXdd+h7uKcl1xdetKDmDtg01LKXzlwOnZaE9fOeaB6CKmqlr21MCZ989KeqsjqX0RiKySCScPFCAu4V1RPEBb45y2nKJF//IplRXA5xVSYWlWrUQ9ZMOraRks/XGRMI2CDmaRaJHPbwPlvSHQjlQBsFDrL68BeKMCCQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=HLWOMb4VVpyncJMfyhe4fZbjFwKPxsbjjcG1EbvK9/gMTs+lLExnrRhSGQ4+aIc9/lAzP+zriCO3NVgFCh1dWPvdeIyKQ6Eq2SJt8vhZlmQQEf3Pe7OFonnJjGApvKBhCOhEF2FZz6Bk/wvfjb8ula5AFSyqblrh/taMsAfKdAo= Received: by 10.67.20.19 with SMTP id x19mr14768832ugi.48.1199325770360; Wed, 02 Jan 2008 18:02:50 -0800 (PST) Received: from ?192.168.10.200? ( [80.216.221.6]) by mx.google.com with ESMTPS id a1sm49438190ugf.78.2008.01.02.18.02.48 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 02 Jan 2008 18:02:48 -0800 (PST) Message-ID: <477C423F.2020701@gmail.com> Date: Thu, 03 Jan 2008 03:02:39 +0100 From: Pawel Worach User-Agent: Thunderbird 2.0.0.9 (X11/20071226) MIME-Version: 1.0 To: d@delphij.net References: <477BE583.6080202@delphij.net> In-Reply-To: <477BE583.6080202@delphij.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current , freebsd-rc@FreeBSD.org Subject: Re: [RFC] rc.d script for binding static arp pairs and logging options X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2008 02:28:48 -0000 Xin LI wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > Here is a rc.d script that I use on my own server, which provides two > functionalities: > > - Bind ARP pairs specified in rc.conf (*); > - Set ARP logging options (+). > What about ethers(5) and arp -f, would that potentially pollute the arp table with too much junk ? -- Pawel From owner-freebsd-current@FreeBSD.ORG Thu Jan 3 02:48:05 2008 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D16E316A419; Thu, 3 Jan 2008 02:48:05 +0000 (UTC) (envelope-from jasone@freebsd.org) Received: from canonware.com (canonware.com [64.183.146.166]) by mx1.freebsd.org (Postfix) with ESMTP id B519213C45B; Thu, 3 Jan 2008 02:48:05 +0000 (UTC) (envelope-from jasone@freebsd.org) Received: from [192.168.168.201] (unknown [192.168.168.201]) by canonware.com (Postfix) with ESMTP id 364351298B1; Wed, 2 Jan 2008 18:26:49 -0800 (PST) Message-ID: <477C47BC.1020101@freebsd.org> Date: Wed, 02 Jan 2008 18:26:04 -0800 From: Jason Evans User-Agent: Thunderbird 1.5.0.12 (X11/20071018) MIME-Version: 1.0 To: Joe Marcus Clarke References: <1199314166.9913.63.camel@shumai.marcuscom.com> In-Reply-To: <1199314166.9913.63.camel@shumai.marcuscom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current Subject: Re: Memory problem with latest malloc.c X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2008 02:48:05 -0000 Joe Marcus Clarke wrote: > GNOME applications use a Python driven XML parser to generate help > document translations. The engine takes the English XML document and > applies translations to it. The tool, xml2po, is installed as part of > textproc/gnome-doc-utils. I'm currently working on porting GNOME 2.21, > and one of the Evolution help doc changes triggered a memory problem on > my test machine. Basically, with up to and including rev 1.154 of > malloc.c, I am able to generate the help file with no errors. With all > later revs including 1.160, the Python process balloons up to about 512 > MB of memory, then dies. > > The only malloc config I've done is symlink Aj to /etc/malloc.conf. I'd > be happy to provide the file an exact command used, but it might be > easier to let me know if there's any debugging I could provide that > would help here. Revision 1.160 of malloc.c uses sbrk instead of mmap by default. The intent is to make data segment resource limits useful. So, there are two possible explanations I can think of for your problems. The first possibility is that there is still a bug in malloc that you're hitting. However, the other possibility is that the python program you're running really needs more than 512 MB of memory, and you're hitting the resource limit. It would be really helpful to me if you run your program with MALLOC_OPTIONS=dM and monitor memory usage. These flags cause mmap to be used instead of sbrk, and we can find out from that how much memory you really need. If peak memory usage is substantially different when using mmap versus sbrk, there's probably a malloc bug. This latest round of malloc changes hasn't been much fun. Thanks for your help and patience. Jason From owner-freebsd-current@FreeBSD.ORG Thu Jan 3 03:14:29 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3E39316A419 for ; Thu, 3 Jan 2008 03:14:29 +0000 (UTC) (envelope-from lists@mipster.net) Received: from omta16.mta.everyone.net (sitemail2.everyone.net [216.200.145.36]) by mx1.freebsd.org (Postfix) with ESMTP id 277E713C465 for ; Thu, 3 Jan 2008 03:14:28 +0000 (UTC) (envelope-from lists@mipster.net) Received: from dm02.mta.everyone.net (bigiplb-dsnat [172.16.0.19]) by omta16.mta.everyone.net (Postfix) with ESMTP id E94414132A; Wed, 2 Jan 2008 19:14:27 -0800 (PST) X-Eon-Dm: dm02 Received: by dm02.mta.everyone.net (EON-AUTHRELAY2 - 4b83c9a6) id dm02.4768f49e.2b7f2c; Wed, 2 Jan 2008 19:14:27 -0800 X-Eon-Sig: AQIAtXxHfFMTpKYhhAIAAAAC,9c2dcf086884ab5296dab6506ce00ea1 Message-Id: From: Nick Pope To: Travis Mikalson In-Reply-To: <477B0B07.8080703@terranova.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v915) Date: Wed, 2 Jan 2008 22:14:38 -0500 References: <1497D115-2534-4799-9D8E-18A267DF0B62@mipster.net> <9A374150-DC2A-439D-A205-E8867B663C5A@mipster.net> <477B0B07.8080703@terranova.net> X-Mailer: Apple Mail (2.915) Cc: freebsd-current@freebsd.org Subject: Re: ServerWorks/Broadcom HT1000 chipset errata saga X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2008 03:14:29 -0000 I csup'ed to latest RELENG_7_0 (RC1) and built the GENERIC kernel. =20 I'm assuming Soren's patch has made it into RC1 because, without =20 commenting out the rr232x driver, the kernel mis-detects my Supermicro =20= PCI-X SATA controller (MV88SX6081 chipset) as an rr232x. --snip-- hptrr0: port 0x7800-0x78ff mem 0xfc300000-0xfc3fffff irq 28 =20 at device 3.0 on pci1 hptrr: adapter at PCI 1:3:0, IRQ 28 --snip-- Here's pciconf -lv: [root@backup2 ~]# lspci -lv -bash: lspci: command not found [root@backup2 ~]# pciconf -lv pcib1@pci0:0:6:0: class=3D0x060400 card=3D0x00000000 = chip=3D0x74601022 =20 rev=3D0x07 hdr=3D0x01 vendor =3D 'Advanced Micro Devices (AMD)' device =3D 'AMD-8111 PCI Bridge' class =3D bridge subclass =3D PCI-PCI isab0@pci0:0:7:0: class=3D0x060100 card=3D0x74681022 = chip=3D0x74681022 =20 rev=3D0x05 hdr=3D0x00 vendor =3D 'Advanced Micro Devices (AMD)' device =3D 'AMD-8111 LPC Bridge' class =3D bridge subclass =3D PCI-ISA atapci1@pci0:0:7:1: class=3D0x01018a card=3D0x74691022 = chip=3D0x74691022 =20 rev=3D0x03 hdr=3D0x00 vendor =3D 'Advanced Micro Devices (AMD)' device =3D 'AMD-8111 UltraATA/133 Controller' class =3D mass storage subclass =3D ATA none0@pci0:0:7:2: class=3D0x0c0500 card=3D0x746a1022 = chip=3D0x746a1022 =20 rev=3D0x02 hdr=3D0x00 vendor =3D 'Advanced Micro Devices (AMD)' device =3D 'AMD-8111 SMBus 2.0 Controller' class =3D serial bus subclass =3D SMBus none1@pci0:0:7:3: class=3D0x068000 card=3D0x746b1022 = chip=3D0x746b1022 =20 rev=3D0x05 hdr=3D0x00 vendor =3D 'Advanced Micro Devices (AMD)' device =3D 'AMD-8111 ACPI System Management Controller' class =3D bridge pcib2@pci0:0:10:0: class=3D0x060400 card=3D0x00000000 = chip=3D0x74501022 =20 rev=3D0x12 hdr=3D0x01 vendor =3D 'Advanced Micro Devices (AMD)' device =3D 'AMD-8131 PCI-X Bridge' class =3D bridge subclass =3D PCI-PCI ioapic0@pci0:0:10:1: class=3D0x080010 card=3D0x36c01022 = chip=3D0x74511022 =20 rev=3D0x01 hdr=3D0x00 vendor =3D 'Advanced Micro Devices (AMD)' device =3D 'AMD-8131 PCI-X IOAPIC' class =3D base peripheral subclass =3D interrupt controller pcib3@pci0:0:11:0: class=3D0x060400 card=3D0x00000000 = chip=3D0x74501022 =20 rev=3D0x12 hdr=3D0x01 vendor =3D 'Advanced Micro Devices (AMD)' device =3D 'AMD-8131 PCI-X Bridge' class =3D bridge subclass =3D PCI-PCI ioapic1@pci0:0:11:1: class=3D0x080010 card=3D0x36c01022 = chip=3D0x74511022 =20 rev=3D0x01 hdr=3D0x00 vendor =3D 'Advanced Micro Devices (AMD)' device =3D 'AMD-8131 PCI-X IOAPIC' class =3D base peripheral subclass =3D interrupt controller hostb0@pci0:0:24:0: class=3D0x060000 card=3D0x00000000 = chip=3D0x11001022 =20 rev=3D0x00 hdr=3D0x00 vendor =3D 'Advanced Micro Devices (AMD)' device =3D '(K8) Athlon 64/Opteron HyperTransport Technology =20= Configuration' class =3D bridge subclass =3D HOST-PCI hostb1@pci0:0:24:1: class=3D0x060000 card=3D0x00000000 = chip=3D0x11011022 =20 rev=3D0x00 hdr=3D0x00 vendor =3D 'Advanced Micro Devices (AMD)' device =3D '(K8) Athlon 64/Opteron Address Map' class =3D bridge subclass =3D HOST-PCI hostb2@pci0:0:24:2: class=3D0x060000 card=3D0x00000000 = chip=3D0x11021022 =20 rev=3D0x00 hdr=3D0x00 vendor =3D 'Advanced Micro Devices (AMD)' device =3D '(K8) Athlon 64/Opteron DRAM Controller' class =3D bridge subclass =3D HOST-PCI hostb3@pci0:0:24:3: class=3D0x060000 card=3D0x00000000 = chip=3D0x11031022 =20 rev=3D0x00 hdr=3D0x00 vendor =3D 'Advanced Micro Devices (AMD)' device =3D '(K8) Athlon 64/Opteron Miscellaneous Control' class =3D bridge subclass =3D HOST-PCI hostb4@pci0:0:25:0: class=3D0x060000 card=3D0x00000000 = chip=3D0x11001022 =20 rev=3D0x00 hdr=3D0x00 vendor =3D 'Advanced Micro Devices (AMD)' device =3D '(K8) Athlon 64/Opteron HyperTransport Technology =20= Configuration' class =3D bridge subclass =3D HOST-PCI hostb5@pci0:0:25:1: class=3D0x060000 card=3D0x00000000 = chip=3D0x11011022 =20 rev=3D0x00 hdr=3D0x00 vendor =3D 'Advanced Micro Devices (AMD)' device =3D '(K8) Athlon 64/Opteron Address Map' class =3D bridge subclass =3D HOST-PCI hostb6@pci0:0:25:2: class=3D0x060000 card=3D0x00000000 = chip=3D0x11021022 =20 rev=3D0x00 hdr=3D0x00 vendor =3D 'Advanced Micro Devices (AMD)' device =3D '(K8) Athlon 64/Opteron DRAM Controller' class =3D bridge subclass =3D HOST-PCI hostb7@pci0:0:25:3: class=3D0x060000 card=3D0x00000000 = chip=3D0x11031022 =20 rev=3D0x00 hdr=3D0x00 vendor =3D 'Advanced Micro Devices (AMD)' device =3D '(K8) Athlon 64/Opteron Miscellaneous Control' class =3D bridge subclass =3D HOST-PCI ohci0@pci0:3:0:0: class=3D0x0c0310 card=3D0x74641022 = chip=3D0x74641022 =20 rev=3D0x0b hdr=3D0x00 vendor =3D 'Advanced Micro Devices (AMD)' device =3D 'AMD-8111 USB OpenHCI Host Controller' class =3D serial bus subclass =3D USB ohci1@pci0:3:0:1: class=3D0x0c0310 card=3D0x74641022 = chip=3D0x74641022 =20 rev=3D0x0b hdr=3D0x00 vendor =3D 'Advanced Micro Devices (AMD)' device =3D 'AMD-8111 USB OpenHCI Host Controller' class =3D serial bus subclass =3D USB atapci0@pci0:3:5:0: class=3D0x018000 card=3D0x31141095 = chip=3D0x31141095 =20 rev=3D0x02 hdr=3D0x00 vendor =3D 'Silicon Image Inc (Was: CMD Technology Inc)' device =3D 'Sil 3114 SATALink/SATARaid Controller' class =3D mass storage vgapci0@pci0:3:6:0: class=3D0x030000 card=3D0x80081002 = chip=3D0x47521002 =20 rev=3D0x27 hdr=3D0x00 vendor =3D 'ATI Technologies Inc' device =3D 'Rage XL PCI' class =3D display subclass =3D VGA re0@pci0:2:8:0: class=3D0x020000 card=3D0x816910ec chip=3D0x816910ec =20 rev=3D0x10 hdr=3D0x00 vendor =3D 'Realtek Semiconductor' device =3D 'RTL8110SB Single-Chip Gigabit LOM Ethernet =20 Controller' class =3D network subclass =3D ethernet bge0@pci0:2:9:0: class=3D0x020000 card=3D0x164414e4 = chip=3D0x164814e4 =20 rev=3D0x03 hdr=3D0x00 vendor =3D 'Broadcom Corporation' device =3D 'BCM5704 NetXtreme Dual Gigabit Adapter' class =3D network subclass =3D ethernet bge1@pci0:2:9:1: class=3D0x020000 card=3D0x164414e4 = chip=3D0x164814e4 =20 rev=3D0x03 hdr=3D0x00 vendor =3D 'Broadcom Corporation' device =3D 'BCM5704 NetXtreme Dual Gigabit Adapter' class =3D network subclass =3D ethernet ahd0@pci0:2:10:0: class=3D0x010000 card=3D0xffff9005 = chip=3D0x801f9005 =20 rev=3D0x10 hdr=3D0x00 vendor =3D 'Adaptec Inc' device =3D 'AIC-7902 Ultra320 SCSI Controller' class =3D mass storage subclass =3D SCSI ahd1@pci0:2:10:1: class=3D0x010000 card=3D0xffff9005 = chip=3D0x801f9005 =20 rev=3D0x10 hdr=3D0x00 vendor =3D 'Adaptec Inc' device =3D 'AIC-7902 Ultra320 SCSI Controller' class =3D mass storage subclass =3D SCSI hptrr0@pci0:1:3:0: class=3D0x010000 card=3D0x11ab11ab = chip=3D0x608111ab =20 rev=3D0x09 hdr=3D0x00 vendor =3D 'Marvell Semiconductor (Was: Galileo Technology = Ltd)' device =3D 'MV88SX6081 8-port SATA II PCI-X Controller' class =3D mass storage subclass =3D SCSI -Nick On Jan 1, 2008, at 10:54 PM, Travis Mikalson wrote: > Nick Pope wrote: >> Installed the patch, now it thinks my Marvel SATA controller is an =20= >> rr232x!! >> If I comment out rr232x driver in the kernel config, the Marvel is =20= >> detected no problem. However, as soon as I mount my zpool (using =20 >> the Marvel controller) the Ierrs start up again. >> -Nick >> On Dec 30, 2007, at 11:52 PM, =20 >> wrote: >>> BTW, I've had PCI-X problems with a Marvel MV88SX6081 SATA =20 >>> controller on a M/B WITHOUT the HT1000 chipset (Tyan S2881UG2NR). =20= >>> The M/B worked flawlessly under 7.0-BETA1 & BETA2. I added the =20 >>> Marvell controller and EVERYTHING on the PCI-X bus flaked out. =20 >>> I'm seeing Ierrs and Oerrs (netstat -i) on the built-in bge =20 >>> interfaces, ZFS checksum errors on disks attached to the Marvel =20 >>> controller, etc. >>> >>> I wasn't sure from reading the thread whether Soren thought the =20 >>> problem went beyond the HT1000 chipset or not. The problem seems =20= >>> to manifest itself only when I use the disks attached to the =20 >>> Marvel controller. I'm applying the patch now to see if it fixes =20= >>> the problem. >>> >>> -Nick > > Thanks for trying it out. I just waved this in front of S=F8ren. > > The apparently new mis-detection issue is certainly something to be =20= > concerned about. You're absolutely sure it was detected as a Marvell =20= > reliably (with rr232x still in there) before you applied that patch? > > The fact that the patch didn't do anything to solve your Marvell =20 > controller problem is too bad, also, but the mis-detection issue is =20= > of more immediate concern since this HT1000/Marvell-fixing code is =20 > being vetted for inclusion in 7.0-R. > > Have you tried that hardware combination with any other OSes to see =20= > if it's a FreeBSD-specific issue and not just a hardware-level issue? > > I haven't had a chance to confirm myself since my box with the =20 > Marvell controller in it is a long drive away from me, but S=F8ren did = =20 > get his PCI-X 8-port Marvell working perfectly fine after making =20 > these fixes. > > --=20 > TerraNovaNet Internet Services - Key Largo, FL > Voice: (305)453-4011 x101 Fax: (305)451-5991 > http://www.terranova.net/ > ---------------------------------------------- > Life's not fair, but the root password helps. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to = "freebsd-current-unsubscribe@freebsd.org=20 > " From owner-freebsd-current@FreeBSD.ORG Thu Jan 3 05:37:33 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5375216A418 for ; Thu, 3 Jan 2008 05:37:33 +0000 (UTC) (envelope-from gwright@antiope.com) Received: from QMTA04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by mx1.freebsd.org (Postfix) with ESMTP id EA06413C448 for ; Thu, 3 Jan 2008 05:37:32 +0000 (UTC) (envelope-from gwright@antiope.com) Received: from OMTA09.westchester.pa.mail.comcast.net ([76.96.62.20]) by QMTA04.westchester.pa.mail.comcast.net with comcast id YLqe1Y00A0SCNGk050dd00; Thu, 03 Jan 2008 05:26:31 +0000 Received: from [192.168.1.100] ([123.116.115.38]) by OMTA09.westchester.pa.mail.comcast.net with comcast id YVSE1Y0090pmadn3V00000; Thu, 03 Jan 2008 05:26:22 +0000 X-Authority-Analysis: v=1.0 c=1 a=GeIttaVd03IA:10 a=6I5d2MoRAAAA:8 a=zGfodBCagz04itHu6fAA:9 a=oRLdVFFdN8iKPX6VvBwA:7 a=OoygN6XzZZiPjG3NddSyJKGTFf4A:4 a=8pM5Lrggm8MA:10 a=SV7veod9ZcQA:10 a=LROfrJfmX20A:10 a=HgpzGGeNr9EA:10 a=3SmO1NJXDBsA:10 a=JH8fDtLDgvtDco9aiZ0A:9 a=He4oDvUukjSQnFtdrJUA:7 a=Vhc2fVty9fFnr8lrc5ATSXUE7M4A:4 a=37WNUvjkh6kA:10 Message-Id: <15E2F52A-9502-4B9A-BA35-C4B4CB6173EE@antiope.com> From: Gregory Wright To: JD Bronson In-Reply-To: <20071230143156.45A31602A2@cheyenne.hanadarko.com> Mime-Version: 1.0 (Apple Message framework v915) Date: Thu, 3 Jan 2008 00:26:21 -0500 References: <20071230143156.45A31602A2@cheyenne.hanadarko.com> X-Mailer: Apple Mail (2.915) Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: 7.0-RC1 bge network performance issue? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2008 05:37:33 -0000 Hi JD, On Dec 30, 2007, at 9:31 AM, JD Bronson wrote: > I am not sure how or where to ask this so I will start here.. > > I have an IBM P4-3.06ghz machine with dual 10/100 BGE nics and 1GB ram > with ATA133 IDE drives. > > I have noticed the following and wondering how I can troubleshoot > this or what's changed. > > Using ANY 6.x branch, including 6.3-RC1 I have no issues at all. > Using the same hardware/machine exactly and using 7.0-RC1 > I am seeing terrible network writes into the machine. > > my bge nics are set to 100FDX and incoming FTP rates are dismal > at around 2-3MB/sec max. > > FTP outbound rates OUT of the box are at full 11-12MB/sec. > > Using 6.3-RC1 - traffic is the same in or out of the box. > (I am not using pf) > One thing to check is whether you are getting duplicate ACKs out of your box. A good way to check is to set up netperf client on a spare machine and a netperf server on your P4/bge box. Do a TCP test while looking at the packets with Wireshark (or your favorite packet logger). The duplicate ACK problem seems to be caused by a firmware bug on some models of the bge chipset. It's not just a FreeBSD problem, it was seen on Gentoo linux as well. (Apparently later versions of the gt3 driver --- the linux equivalent of bge --- fixed this problem, but it is not immediately apparent what the magic change was.) I saw the duplicate ACK problem on both 6.x and 7.0-BETA2, but it seemed a good deal worse with 7.0. One interesting thing on my dual Opteron box was that the problem didn't happen when running at 1Gb/s, it showed up when I ran at 100 Mb/s. I suspect some subtlety in initializing the chip is behind the duplicate ACKs. Some people have suggested TCP segmentation offloading (TSO) could be the root cause. You could also check if TSO is enabled, and if it is, disable it with ifconfig (8). Best Wishes, Greg Gregory Wright Antiope Associates LLC 18 Clay Street Fair Haven, New Jersey 07704 USA gwright@antiope.com 1 (732) 924-4549 1 (732) 345-8378 [fax] > If it's any help, I have noticed the exact same issue with OpenBSD > since anything newer than 3.7 and my posts to that group with this > issue have basically been unresponded to. > > I would love to keep using FreeBSD but cant with this issue. > > NetBSD 4.0 does not exhibit this behavior at this time. > > Any thoughts? Major changes on bge? Anything? > > It simply cant be my hardware as this is not an issue under the 6.x > branch. > > Thanks, > > -JD > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org > " > From owner-freebsd-current@FreeBSD.ORG Thu Jan 3 06:00:22 2008 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BCFE116A418; Thu, 3 Jan 2008 06:00:22 +0000 (UTC) (envelope-from marcus@FreeBSD.org) Received: from creme-brulee.marcuscom.com (marcuscom-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::1279]) by mx1.freebsd.org (Postfix) with ESMTP id 8C0AE13C469; Thu, 3 Jan 2008 06:00:22 +0000 (UTC) (envelope-from marcus@FreeBSD.org) Received: from [IPv6:2001:470:1f00:2464::4] (shumai.marcuscom.com [IPv6:2001:470:1f00:2464::4]) by creme-brulee.marcuscom.com (8.14.2/8.14.2) with ESMTP id m0361FOU093507; Thu, 3 Jan 2008 01:01:15 -0500 (EST) (envelope-from marcus@FreeBSD.org) From: Joe Marcus Clarke To: Jason Evans In-Reply-To: <477C47BC.1020101@freebsd.org> References: <1199314166.9913.63.camel@shumai.marcuscom.com> <477C47BC.1020101@freebsd.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-fXfxdS28cvSaXkQrWs6n" Organization: FreeBSD, Inc. Date: Thu, 03 Jan 2008 01:00:28 -0500 Message-Id: <1199340028.64371.9.camel@shumai.marcuscom.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.2 FreeBSD GNOME Team Port X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,MIME_QP_LONG_LINE, NO_RELAYS autolearn=no version=3.2.3 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on creme-brulee.marcuscom.com Cc: current Subject: Re: Memory problem with latest malloc.c X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2008 06:00:22 -0000 --=-fXfxdS28cvSaXkQrWs6n Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2008-01-02 at 18:26 -0800, Jason Evans wrote: > Joe Marcus Clarke wrote: > > GNOME applications use a Python driven XML parser to generate help > > document translations. The engine takes the English XML document and > > applies translations to it. The tool, xml2po, is installed as part of > > textproc/gnome-doc-utils. I'm currently working on porting GNOME 2.21, > > and one of the Evolution help doc changes triggered a memory problem on > > my test machine. Basically, with up to and including rev 1.154 of > > malloc.c, I am able to generate the help file with no errors. With all > > later revs including 1.160, the Python process balloons up to about 512 > > MB of memory, then dies. > >=20 > > The only malloc config I've done is symlink Aj to /etc/malloc.conf. I'= d > > be happy to provide the file an exact command used, but it might be > > easier to let me know if there's any debugging I could provide that > > would help here. >=20 > Revision 1.160 of malloc.c uses sbrk instead of mmap by default. The=20 > intent is to make data segment resource limits useful. So, there are=20 > two possible explanations I can think of for your problems. The first=20 > possibility is that there is still a bug in malloc that you're hitting.=20 > However, the other possibility is that the python program you're=20 > running really needs more than 512 MB of memory, and you're hitting the=20 > resource limit. >=20 > It would be really helpful to me if you run your program with=20 > MALLOC_OPTIONS=3DdM and monitor memory usage. These flags cause mmap to=20 > be used instead of sbrk, and we can find out from that how much memory=20 > you really need. If peak memory usage is substantially different when=20 > using mmap versus sbrk, there's probably a malloc bug. Memory climbed up to 976 MB SZ, 974 MB RSS MB with dM -> /etc/malloc.conf. The file was eventually generated without error. Again, with Aj -> /etc/malloc.conf, the python2.5 process operating on the same file planed out at 504 MB SZ, 501 MB RSS. >=20 > This latest round of malloc changes hasn't been much fun. Thanks for=20 > your help and patience. No problem. Thanks for getting back to me. Joe --=20 Joe Marcus Clarke FreeBSD GNOME Team :: gnome@FreeBSD.org FreeNode / #freebsd-gnome http://www.FreeBSD.org/gnome --=-fXfxdS28cvSaXkQrWs6n Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQBHfHn4b2iPiv4Uz4cRAn8lAJ0dcD9m25vEIarrzycSWt6IAG3pqgCePnd+ aO5kMhL6wqPX8J46sKeb/gg= =Jg5E -----END PGP SIGNATURE----- --=-fXfxdS28cvSaXkQrWs6n-- From owner-freebsd-current@FreeBSD.ORG Thu Jan 3 06:12:03 2008 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D420816A418; Thu, 3 Jan 2008 06:12:03 +0000 (UTC) (envelope-from jasone@freebsd.org) Received: from canonware.com (canonware.com [64.183.146.166]) by mx1.freebsd.org (Postfix) with ESMTP id B46E713C43E; Thu, 3 Jan 2008 06:12:03 +0000 (UTC) (envelope-from jasone@freebsd.org) Received: from [192.168.168.201] (unknown [192.168.168.201]) by canonware.com (Postfix) with ESMTP id 9AFB91298C5; Wed, 2 Jan 2008 22:12:51 -0800 (PST) Message-ID: <477C7CB6.8080701@freebsd.org> Date: Wed, 02 Jan 2008 22:12:06 -0800 From: Jason Evans User-Agent: Thunderbird 1.5.0.12 (X11/20071018) MIME-Version: 1.0 To: Joe Marcus Clarke References: <1199314166.9913.63.camel@shumai.marcuscom.com> <477C47BC.1020101@freebsd.org> <1199340028.64371.9.camel@shumai.marcuscom.com> In-Reply-To: <1199340028.64371.9.camel@shumai.marcuscom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Robert Watson , current Subject: Re: Memory problem with latest malloc.c X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2008 06:12:03 -0000 Joe Marcus Clarke wrote: > On Wed, 2008-01-02 at 18:26 -0800, Jason Evans wrote: >> It would be really helpful to me if you run your program with >> MALLOC_OPTIONS=dM and monitor memory usage. These flags cause mmap to >> be used instead of sbrk, and we can find out from that how much memory >> you really need. If peak memory usage is substantially different when >> using mmap versus sbrk, there's probably a malloc bug. > > Memory climbed up to 976 MB SZ, 974 MB RSS MB with dM > -> /etc/malloc.conf. The file was eventually generated without error. > Again, with Aj -> /etc/malloc.conf, the python2.5 process operating on > the same file planed out at 504 MB SZ, 501 MB RSS. Okay, that indicates that there is not a problem with malloc; you're running into the data segment resource limit. It isn't possible to increase the data segment beyond 512 MB on i386, so your best bet is to use MALLOC_OPTIONS=DM for the memory-intensive program. That will cause the program use all available space in the data segment, then start using mmap as necessary. I'm sorta thinking that MALLOC_OPTIONS=DM should be the default. Robert Watson is the person who talked me into this change, so feel free to give him a hard time about the extra configuration you have to do in order to get work done. =) Thanks, Jason From owner-freebsd-current@FreeBSD.ORG Thu Jan 3 06:15:45 2008 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BA24F16A41A; Thu, 3 Jan 2008 06:15:45 +0000 (UTC) (envelope-from marcus@FreeBSD.org) Received: from creme-brulee.marcuscom.com (penna-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::1279]) by mx1.freebsd.org (Postfix) with ESMTP id 7139B13C448; Thu, 3 Jan 2008 06:15:45 +0000 (UTC) (envelope-from marcus@FreeBSD.org) Received: from [IPv6:2001:470:1f00:2464::4] (shumai.marcuscom.com [IPv6:2001:470:1f00:2464::4]) by creme-brulee.marcuscom.com (8.14.2/8.14.2) with ESMTP id m036GXmS093598; Thu, 3 Jan 2008 01:16:33 -0500 (EST) (envelope-from marcus@FreeBSD.org) From: Joe Marcus Clarke To: Jason Evans In-Reply-To: <477C7CB6.8080701@freebsd.org> References: <1199314166.9913.63.camel@shumai.marcuscom.com> <477C47BC.1020101@freebsd.org> <1199340028.64371.9.camel@shumai.marcuscom.com> <477C7CB6.8080701@freebsd.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-iX0YyCDUvry13VmnZCVM" Organization: FreeBSD, Inc. Date: Thu, 03 Jan 2008 01:15:46 -0500 Message-Id: <1199340946.64371.14.camel@shumai.marcuscom.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.2 FreeBSD GNOME Team Port X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,NO_RELAYS autolearn=ham version=3.2.3 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on creme-brulee.marcuscom.com Cc: Robert Watson , current Subject: Re: Memory problem with latest malloc.c X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2008 06:15:45 -0000 --=-iX0YyCDUvry13VmnZCVM Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2008-01-02 at 22:12 -0800, Jason Evans wrote: > Joe Marcus Clarke wrote: > > On Wed, 2008-01-02 at 18:26 -0800, Jason Evans wrote: > >> It would be really helpful to me if you run your program with=20 > >> MALLOC_OPTIONS=3DdM and monitor memory usage. These flags cause mmap = to=20 > >> be used instead of sbrk, and we can find out from that how much memory= =20 > >> you really need. If peak memory usage is substantially different when= =20 > >> using mmap versus sbrk, there's probably a malloc bug. > >=20 > > Memory climbed up to 976 MB SZ, 974 MB RSS MB with dM > > -> /etc/malloc.conf. The file was eventually generated without error. > > Again, with Aj -> /etc/malloc.conf, the python2.5 process operating on > > the same file planed out at 504 MB SZ, 501 MB RSS. >=20 > Okay, that indicates that there is not a problem with malloc; you're=20 > running into the data segment resource limit. It isn't possible to=20 > increase the data segment beyond 512 MB on i386, so your best bet is to=20 > use MALLOC_OPTIONS=3DDM for the memory-intensive program. That will caus= e=20 > the program use all available space in the data segment, then start=20 > using mmap as necessary. Yeah, I just realized that after looking at the memory usage of rev 1.154 (it's the same). I could tweak kern.maxdsiz in loader.conf, but ~ 1 GB is way too much memory for this program. I know what causes the extra memory usage, so I think I'll bug the Evolution guys. Thanks. >=20 > I'm sorta thinking that MALLOC_OPTIONS=3DDM should be the default. Rober= t=20 > Watson is the person who talked me into this change, so feel free to=20 > give him a hard time about the extra configuration you have to do in=20 > order to get work done. =3D) It may not be obvious to all users and I think many will be bit by this (i.e. POLA violation) considering maxdsiz is 512 MB on i386. Having DM the default would be a good idea IMHO. Joe --=20 Joe Marcus Clarke FreeBSD GNOME Team :: gnome@FreeBSD.org FreeNode / #freebsd-gnome http://www.FreeBSD.org/gnome --=-iX0YyCDUvry13VmnZCVM Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQBHfH2Sb2iPiv4Uz4cRAs9uAKCQ7JFF+eCVwQ84yOpTYqhA9GRRggCfdpGX VUw9LVEs0fgx6o5gRDDerpc= =CpL4 -----END PGP SIGNATURE----- --=-iX0YyCDUvry13VmnZCVM-- From owner-freebsd-current@FreeBSD.ORG Thu Jan 3 06:58:04 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E8D7316A420 for ; Thu, 3 Jan 2008 06:58:04 +0000 (UTC) (envelope-from jasone@freebsd.org) Received: from canonware.com (canonware.com [64.183.146.166]) by mx1.freebsd.org (Postfix) with ESMTP id 92E6B13C45D for ; Thu, 3 Jan 2008 06:58:04 +0000 (UTC) (envelope-from jasone@freebsd.org) Received: from [192.168.168.201] (unknown [192.168.168.201]) by canonware.com (Postfix) with ESMTP id E4C9E1298C5; Wed, 2 Jan 2008 22:39:25 -0800 (PST) Message-ID: <477C82F0.5060809@freebsd.org> Date: Wed, 02 Jan 2008 22:38:40 -0800 From: Jason Evans User-Agent: Thunderbird 1.5.0.12 (X11/20071018) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Poul-Henning Kamp Subject: sbrk(2) broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2008 06:58:05 -0000 Poul-Henning noticed today that xchat fails to start if malloc uses sbrk internally. This failure happens during the first call to malloc, with the following message: Fatal error 'Can't allocate initial thread' at line 335 in file /usr/src/lib/libthr/thread/thr_init.c (errno = 12) This can be worked around with MALLOC_OPTIONS=dM . The problem does not appear to be specific to jemalloc; I reverted src/lib/libc/stdlib/malloc.c to revision 1.92 (last phkmalloc revision), which also uses sbrk, and the failure mode is the same. The failure occurs on both i386 and amd64. It appears that sbrk(0) returns an address that is in the address range normally used by mmap. So, the first call to sbrk with a non-zero increment is fantastically wrong. On i386 (ktrace output): 1013 xchat CALL break(0x28200000) 1013 xchat RET break -1 errno 12 Cannot allocate memory On amd64 (truss ouput): break(0x800900000) ERR#12 'Cannot allocate memory' sbrk is not a true system call, so it seems like the problem should have something to do with the _end data symbol. I looked at it in gdb though and never saw an unreasonable value, despite bogus sbrk(0) results. I do not know offhand how to get the addresses of .minbrk and .curbrk (register inspection within gdb while stepping through sbrk?), which are what sbrk actually uses (see src/lib/libc/amd64/sys/sbrk.S). Perhaps the loader isn't initializing them correctly... I am quite pressed for time at the moment, and cannot look into this in any more detail for at least a couple of weeks. If anyone knows what the problem is, please let me know. Thanks, Jason From owner-freebsd-current@FreeBSD.ORG Thu Jan 3 09:47:31 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A73D116A418 for ; Thu, 3 Jan 2008 09:47:31 +0000 (UTC) (envelope-from bofh@terranova.net) Received: from tog.net (tog.net [216.89.226.5]) by mx1.freebsd.org (Postfix) with ESMTP id 80BCC13C455 for ; Thu, 3 Jan 2008 09:47:31 +0000 (UTC) (envelope-from bofh@terranova.net) Received: from [216.89.228.170] (host-216-89-228-170.wireless.terranova.net [216.89.228.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tog.net (Postfix) with ESMTP id A563129B5FB for ; Thu, 3 Jan 2008 04:47:30 -0500 (EST) Message-ID: <477CAF30.7020703@terranova.net> Date: Thu, 03 Jan 2008 04:47:28 -0500 From: Travis Mikalson Organization: TerraNovaNet Internet Services User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <1497D115-2534-4799-9D8E-18A267DF0B62@mipster.net> <9A374150-DC2A-439D-A205-E8867B663C5A@mipster.net> <477B0B07.8080703@terranova.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: ServerWorks/Broadcom HT1000 chipset errata saga X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2008 09:47:31 -0000 Nick Pope wrote: > I csup'ed to latest RELENG_7_0 (RC1) and built the GENERIC kernel. I'm > assuming Soren's patch has made it into RC1 because, without commenting > out the rr232x driver, the kernel mis-detects my Supermicro PCI-X SATA > controller (MV88SX6081 chipset) as an rr232x. No, Søren's HT1000/Marvell fixing stuff is still in HEAD only according to cvsweb. Did not make it to RELENG_7 or RELENG_7_0 yet. I think your problem is unrelated to this patchset. It wasn't making any sense that any of this code that was touched would have any effect on detection of your Marvell device anyway... From owner-freebsd-current@FreeBSD.ORG Thu Jan 3 10:27:24 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1538F16A474 for ; Thu, 3 Jan 2008 10:27:24 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id BE8B513C447 for ; Thu, 3 Jan 2008 10:27:23 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JANIH-0006au-87 for freebsd-current@freebsd.org; Thu, 03 Jan 2008 10:27:21 +0000 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 03 Jan 2008 10:27:21 +0000 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 03 Jan 2008 10:27:21 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Thu, 03 Jan 2008 11:27:06 +0100 Lines: 38 Message-ID: References: <1199314166.9913.63.camel@shumai.marcuscom.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD82D44D6098432208162C22C" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 2.0.0.9 (X11/20070801) In-Reply-To: <1199314166.9913.63.camel@shumai.marcuscom.com> X-Enigmail-Version: 0.95.5 Sender: news Subject: Re: Memory problem with latest malloc.c X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2008 10:27:24 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD82D44D6098432208162C22C Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Joe Marcus Clarke wrote: > GNOME applications use a Python driven XML parser to generate help > document translations. The engine takes the English XML document and > applies translations to it. The tool, xml2po, is installed as part of > textproc/gnome-doc-utils. I'm currently working on porting GNOME 2.21,= > and one of the Evolution help doc changes triggered a memory problem on= > my test machine. Basically, with up to and including rev 1.154 of > malloc.c, I am able to generate the help file with no errors. With all= > later revs including 1.160, the Python process balloons up to about 512= > MB of memory, then dies. What is the state of the PYMALLOC option presented when building python from ports? Do a make config to toggle it. --------------enigD82D44D6098432208162C22C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFHfLiCldnAQVacBcgRAv8rAKC83The3kmsvxwvTJ2yXydHloS92gCgoliW 6bvRxsEp60aNUS3VAI/R/5w= =caTQ -----END PGP SIGNATURE----- --------------enigD82D44D6098432208162C22C-- From owner-freebsd-current@FreeBSD.ORG Thu Jan 3 11:04:04 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A7B3816A468 for ; Thu, 3 Jan 2008 11:04:04 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.freebsd.org (Postfix) with ESMTP id 7EC6F13C468 for ; Thu, 3 Jan 2008 11:04:04 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id 0866282BB8; Thu, 3 Jan 2008 06:04:03 -0500 (EST) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute2.internal (MEProxy); Thu, 03 Jan 2008 06:04:03 -0500 X-Sasl-enc: g9+DHazHnaOjNr9tuc801TYJlhRlRejBXmLD8VebWNAF 1199358242 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 68C757E6A; Thu, 3 Jan 2008 06:04:02 -0500 (EST) Message-ID: <477CC121.1040805@FreeBSD.org> Date: Thu, 03 Jan 2008 11:04:01 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.6 (X11/20070928) MIME-Version: 1.0 To: pyunyh@gmail.com References: <20080102033939.GB27551@cdnetworks.co.kr> In-Reply-To: <20080102033939.GB27551@cdnetworks.co.kr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: CFT: sf(4) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2008 11:04:04 -0000 Pyun YongHyeon wrote: > - AIC-6915 supports Rx/Tx checksum offload as well as hardware VLAN > tag insertion/stripping if firmware is loaded into frame > processor. Unfortunately the firmware is not available under BSD > license so these additional hardware accelerations are not > available yet on FreeBSD. :-( > I think I might still have one of these cards lying around, though free time, as always, is scant. Have you tried contacting Adaptec about the licensing issue? These cards are several years old, it seems to me they should be willing to license the firmware. cheers BMS From owner-freebsd-current@FreeBSD.ORG Thu Jan 3 11:39:04 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2EF4816A41B for ; Thu, 3 Jan 2008 11:39:04 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.183]) by mx1.freebsd.org (Postfix) with ESMTP id F00C413C465 for ; Thu, 3 Jan 2008 11:39:03 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so10163973waf.3 for ; Thu, 03 Jan 2008 03:39:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; bh=FsXoDd1UJuJkYiKCTXsoHSsCqHcLakrSXNDiJ1/2mic=; b=eP1QYbZ5fOEYPCup1zmY68Z5U0VpZ+R9SLi/b9CHQX4cBKdBtCBckLMKHFt/g12hTZCIsKJ3TsC5c2x2xns/UUFNTzHRa64yv5J658QdpNlmbabVY74o/Clw/iTrKs3MrRGApGEfi7t/eh9+f6d8jVdAxMhFP6th8P4+DiBemDY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=roPsGy6sLhXi1T87M0PfENOYsgnW0KwbOVUd5EGOMNTFhXgThkWdpPiQ/u9Yey8BhM87ASE6au5mb9bvpX3Y3AQrDfT3JJtrffhA1zlNjpsHGtz+a9UgI3U7R/hVVSz1HLavt7yuFxPhxDBcvT8Ky6maa32l4Pq4dxvhYXMxmIA= Received: by 10.114.25.3 with SMTP id 3mr17114013way.22.1199360343484; Thu, 03 Jan 2008 03:39:03 -0800 (PST) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTPS id m40sm27830229wag.0.2008.01.03.03.38.59 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 03 Jan 2008 03:39:02 -0800 (PST) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id m03BaQS7033738 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Jan 2008 20:36:26 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id m03BaQ3L033737; Thu, 3 Jan 2008 20:36:26 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Thu, 3 Jan 2008 20:36:26 +0900 From: Pyun YongHyeon To: "Bruce M. Simpson" Message-ID: <20080103113626.GF31644@cdnetworks.co.kr> References: <20080102033939.GB27551@cdnetworks.co.kr> <477CC121.1040805@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <477CC121.1040805@FreeBSD.org> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@FreeBSD.org Subject: Re: CFT: sf(4) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2008 11:39:04 -0000 On Thu, Jan 03, 2008 at 11:04:01AM +0000, Bruce M. Simpson wrote: > Pyun YongHyeon wrote: > > - AIC-6915 supports Rx/Tx checksum offload as well as hardware VLAN > > tag insertion/stripping if firmware is loaded into frame > > processor. Unfortunately the firmware is not available under BSD > > license so these additional hardware accelerations are not > > available yet on FreeBSD. :-( > > > > I think I might still have one of these cards lying around, though free > time, as always, is scant. > > Have you tried contacting Adaptec about the licensing issue? These cards > are several years old, it seems to me they should be willing to license > the firmware. > I tried to contact the vendor to get e-mail support but I couldn't find who is responsible for this issue. The vendor's website requires a TSID(Technical Support Identification) number which is not available to me. Linux seems to have GPL v2 licensed firmware from Adaptec. > cheers > BMS -- Regards, Pyun YongHyeon From owner-freebsd-current@FreeBSD.ORG Thu Jan 3 08:20:43 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5DA9F16A418; Thu, 3 Jan 2008 08:20:43 +0000 (UTC) (envelope-from fjoe@samodelkin.net) Received: from neo.samodelkin.net (samodelkin.net [195.62.0.66]) by mx1.freebsd.org (Postfix) with ESMTP id EE30313C457; Thu, 3 Jan 2008 08:20:42 +0000 (UTC) (envelope-from fjoe@samodelkin.net) Received: by neo.samodelkin.net (Postfix, from userid 10117) id 030F31727D; Thu, 3 Jan 2008 13:52:14 +0600 (NOVT) Received: from husky.fjoe.local (gw.nsib.ru [217.117.80.2]) by neo.samodelkin.net (Postfix) with ESMTP id 01BD917275; Thu, 3 Jan 2008 13:52:12 +0600 (NOVT) Message-ID: <477C9429.8090801@samodelkin.net> Date: Thu, 03 Jan 2008 13:52:09 +0600 From: Max Khon User-Agent: Thunderbird 2.0.0.6 (X11/20071028) MIME-Version: 1.0 To: Sepherosa Ziehau References: <86ir2hznnd.fsf@ds4.des.no> <86abnpu0wv.fsf@ds4.des.no> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Bogosity: No, tests=bogofilter, spamicity=0.000000, version=0.16.4 X-Mailman-Approved-At: Thu, 03 Jan 2008 12:26:55 +0000 Cc: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= , sam@freebsd.org, net@freebsd.org, current@freebsd.org, kevlo@freebsd.org Subject: Re: if_ral regression X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2008 08:20:43 -0000 Hi! Sepherosa Ziehau wrote: >>> I don't whether following thingies will fix your problem: >>> [...] >> Can you provide a diff? > > http://people.freebsd.org/~sephe/rt2560_test.diff > > Hope it will have some effect. Do you have a similar patch for Ralink 2661? /fjoe From owner-freebsd-current@FreeBSD.ORG Thu Jan 3 14:37:26 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DDEF616A417; Thu, 3 Jan 2008 14:37:26 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 93A9413C45B; Thu, 3 Jan 2008 14:37:26 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 27363207E; Thu, 3 Jan 2008 15:37:18 +0100 (CET) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: -0.1/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 8DF1E2049; Thu, 3 Jan 2008 15:37:17 +0100 (CET) Received: by ds4.des.no (Postfix, from userid 1001) id 70B99844C3; Thu, 3 Jan 2008 15:37:17 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: "Sepherosa Ziehau" References: <86ir2hznnd.fsf@ds4.des.no> <86abnpu0wv.fsf@ds4.des.no> <86abnovy4k.fsf@ds4.des.no> Date: Thu, 03 Jan 2008 15:37:17 +0100 In-Reply-To: <86abnovy4k.fsf@ds4.des.no> ("Dag-Erling =?utf-8?Q?Sm=C3=B8rg?= =?utf-8?Q?rav=22's?= message of "Wed\, 02 Jan 2008 20\:14\:03 +0100") Message-ID: <86odc3dlgi.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: kevlo@freebsd.org, sam@freebsd.org, current@freebsd.org, net@freebsd.org Subject: Re: if_ral regression X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2008 14:37:27 -0000 Dag-Erling Sm=C3=B8rgrav writes: > "Sepherosa Ziehau" writes: > > http://people.freebsd.org/~sephe/rt2560_test.diff > I built a new kernel with the patch applied, and it seems to help, > though it's a bit early to say for sure. Didn't help. A large rsync over ssh stalls the connection within minutes. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Thu Jan 3 17:49:32 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1239916A419 for ; Thu, 3 Jan 2008 17:49:32 +0000 (UTC) (envelope-from hwhartman@gmail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.190]) by mx1.freebsd.org (Postfix) with ESMTP id 9FDB513C442 for ; Thu, 3 Jan 2008 17:49:31 +0000 (UTC) (envelope-from hwhartman@gmail.com) Received: by rv-out-0910.google.com with SMTP id l15so6218084rvb.43 for ; Thu, 03 Jan 2008 09:49:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=1dm7Oazd7mdEBJtlgFsDLMYOuR2e3vbafEABZgzlsrI=; b=J6JoSSaKKPn6yFNbVrcyJd/kYiRJGqyDyBXAgFC0bGrUal3thwecMfRvHE2V+jQGSNv4KOQdjlhLaXCeXfpbSm+EoZ2M1T+AG0vWALBDBjwOiLey1x1/2+ThzMd1nS4YcsbckpbqMYikcLpW5jSlTCf7fv0jWx5L2tskyKC3V8Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=l1RzlCWjwjympOgmSD9tr82AgbFNMbaEgBR6zFif7YxJw7NCyqA5+qR9fGbVe16xbuA7Y0rk4c2FIKE7lzUrU6ZS03EaxNNeAUmVz1hinTworCiMnKBu4z49YiWbhPoLHiLAXT8kB9tOMzvUQ5pTV6yfRDKFcuUV2EccnOeAJ7g= Received: by 10.140.54.6 with SMTP id c6mr8252421rva.37.1199380972534; Thu, 03 Jan 2008 09:22:52 -0800 (PST) Received: by 10.140.136.2 with HTTP; Thu, 3 Jan 2008 09:22:52 -0800 (PST) Message-ID: Date: Thu, 3 Jan 2008 09:22:52 -0800 From: "Hanns Hartman" To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: panic about half the time with WPA+WPI during startup X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2008 17:49:32 -0000 Hi All, I am running FreeBSD 7-Prerelease on an Lenovo T61. I am having problems with the WPI driver doing WPA TKIP authentication during startup. Sometimes it works perfectly with no problems, other times it kernel panics (see the kgdb output below). If you need more debugging information or if you need me to try something just let me know and I will be happy to help. Also if this email is not appropriate for this list please feel free to direct me to the appropriate one. thanks Hanns Here is how I start WPA auth on my WPI wireless card. rc.conf: ifconfig_wpi0=3D"WPA DHCP" Start of Kgdb output: Unread portion of the kernel message buffer: Copyright (c) 1992-2007 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 is a registered trademark of The FreeBSD Foundation. FreeBSD 7.0-PRERELEASE #2: Mon Dec 24 10:51:35 PST 2007 hhartman@t61-laptop.localhost:/usr/obj/usr/src/sys/MYKERNEL12_22 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz (2194.52-MHz 686-class CPU) Origin =3D "GenuineIntel" Id =3D 0x6fb Stepping =3D 11 Features=3D0xbfebfbff Features2=3D0xe3bd AMD Features=3D0x20100000 AMD Features2=3D0x1 Cores per package: 2 real memory =3D 2112552960 (2014 MB) avail memory =3D 2053394432 (1958 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ACPI Warning (tbfadt-0505): Optional field "Gpe1Block" has zero address or length: 0 102C/0 [20070320] ioapic0: Changing APIC ID to 1 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi_ec0: port 0x62,0x66 on acpi0 acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 7df00000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acp= i0 Timecounter "HPET" frequency 14318180 Hz quality 900 cpu0: on acpi0 coretemp0: on cpu0 est0: on cpu0 p4tcc0: on cpu0 cpu1: on acpi0 coretemp1: on cpu1 est1: on cpu1 p4tcc1: on cpu1 acpi_lid0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 nvidia0: port 0x2000-0x207f mem 0xd2000000-0xd2ffffff,0xe0000000-0xefffffff,0xd0000000-0xd1ffffff irq 16 at device 0.0 on pci1 nvidia0: [GIANT-LOCKED] nvidia0: [ITHREAD] em0: port 0x1840-0x1= 85f mem 0xfe200000-0xfe21ffff,0xfe225000-0xfe225fff irq 20 at device 25.0 on pc= i0 em0: Using MSI interrupt em0: Ethernet address: 00:1e:37:16:06:e1 em0: [FILTER] uhci0: port 0x1860-0x187f irq 20 at device 26.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0x1880-0x189f irq 21 at device 26.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered ehci0: mem 0xfe226c00-0xfe226fff irq 22= at device 26.7 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb2: EHCI version 1.0 usb2: companion controllers, 2 ports each: usb0 usb1 usb2: on ehci0 usb2: USB revision 2.0 uhub2: on usb2 uhub2: 4 ports with 4 removable, self powered pcm0: mem 0xfe220000-0xfe223fff irq 17 at device 27.0 on pci0 pcm0: [ITHREAD] pcib2: irq 20 at device 28.0 on pci0 pci2: on pcib2 pci2: at device 0.0 (no driver attached) pcib3: irq 21 at device 28.1 on pci0 pci3: on pcib3 wpi0: mem 0xd7dff000-0xd7dfffff irq 17 at device 0.0 on pci3 bus_dmamem_alloc failed to align memory properly. bus_dmamem_alloc failed to align memory properly. bus_dmamem_alloc failed to align memory properly. bus_dmamem_alloc failed to align memory properly. bus_dmamem_alloc failed to align memory properly. bus_dmamem_alloc failed to align memory properly. bus_dmamem_alloc failed to align memory properly. bus_dmamem_alloc failed to align memory properly. bus_dmamem_alloc failed to align memory properly. bus_dmamem_alloc failed to align memory properly. bus_dmamem_alloc failed to align memory properly. bus_dmamem_alloc failed to align memory properly. bus_dmamem_alloc failed to align memory properly. bus_dmamem_alloc failed to align memory properly. bus_dmamem_alloc failed to align memory properly. bus_dmamem_alloc failed to align memory properly. bus_dmamem_alloc failed to align memory properly. bus_dmamem_alloc failed to align memory properly. bus_dmamem_alloc failed to align memory properly. bus_dmamem_alloc failed to align memory properly. bus_dmamem_alloc failed to align memory properly. bus_dmamem_alloc failed to align memory properly. bus_dmamem_alloc failed to align memory properly. bus_dmamem_alloc failed to align memory properly. bus_dmamem_alloc failed to align memory properly. bus_dmamem_alloc failed to align memory properly. bus_dmamem_alloc failed to align memory properly. bus_dmamem_alloc failed to align memory properly. bus_dmamem_alloc failed to align memory properly. bus_dmamem_alloc failed to align memory properly. bus_dmamem_alloc failed to align memory properly. wpi0: Ethernet address: 00:1c:bf:04:2e:03 wpi0: [ITHREAD] wpi0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps wpi0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps wpi0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbp= s 36Mbps 48Mbps 54Mbps pcib4: irq 22 at device 28.2 on pci0 pci4: on pcib4 pcib5: irq 23 at device 28.3 on pci0 pci5: on pcib5 pcib6: irq 20 at device 28.4 on pci0 pci13: on pcib6 uhci2: port 0x18a0-0x18bf irq 16 at device 29.0 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb3: on uhci2 usb3: USB revision 1.0 uhub3: on usb3 uhub3: 2 ports with 2 removable, self powered uhci3: port 0x18c0-0x18df irq 17 at device 29.1 on pci0 uhci3: [GIANT-LOCKED] uhci3: [ITHREAD] usb4: on uhci3 usb4: USB revision 1.0 uhub4: on usb4 uhub4: 2 ports with 2 removable, self powered uhci4: port 0x18e0-0x18ff irq 18 at device 29.2 on pci0 uhci4: [GIANT-LOCKED] uhci4: [ITHREAD] usb5: on uhci4 usb5: USB revision 1.0 uhub5: on usb5 uhub5: 2 ports with 2 removable, self powered ehci1: mem 0xfe227000-0xfe2273ff irq 19= at device 29.7 on pci0 ehci1: [GIANT-LOCKED] ehci1: [ITHREAD] usb6: EHCI version 1.0 usb6: companion controllers, 2 ports each: usb3 usb4 usb5 usb6: on ehci1 usb6: USB revision 2.0 uhub6: on usb6 uhub6: 6 ports with 6 removable, self powered pcib7: at device 30.0 on pci0 pci21: on pcib7 cbb0: mem 0xf8100000-0xf8100fff irq 16 at devi= ce 0.0 on pci21 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 cbb0: [ITHREAD] fwohci0: <1394 Open Host Controller Interface> mem 0xf8101000-0xf81017ff ir= q 17 at device 0.1 on pci21 fwohci0: [FILTER] fwohci0: OHCI version 1.10 (ROM=3D0) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:06:1b:03:2a:15:86:fa fwohci0: Phy 1394a available S400, 1 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0x7b858000 sbp0: on firewire0 fwohci0: Initiate bus reset fwohci0: BUS reset fwohci0: node_id=3D0xc800ffc0, gen=3D1, CYCLEMASTER mode isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1830-0x183f at device 31.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] atapci1: port 0x1c48-0x1c4f,0x1c1c-0x1c1f,0x1c40-0x1c47,0x1c18-0x1c1b,0x1c20-0x1c3f mem 0xfe226000-0xfe2267ff irq 16 at device 31.2 on pci0 atapci1: [ITHREAD] atapci1: AHCI Version 01.10 controller with 3 ports detected ata2: on atapci1 ata2: [ITHREAD] ata3: on atapci1 ata3: port not implemented ata3: [ITHREAD] ata4: on atapci1 ata4: port not implemented ata4: [ITHREAD] pci0: at device 31.3 (no driver attached) acpi_dock0: on acpi0 acpi_tz0: on acpi0 acpi_tz1: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model Generic PS/2 mouse, device ID 0 battery0: on acpi0 acpi_acad0: on acpi0 acpi_ibm0: on acpi0 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcefff,0xcf000-0xcffff,0xd0000-0xd0fff,0xd1000-0xd3fff,0xe0000-0xe= ffff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ppc0: cannot reserve I/O port range sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 8250 or not responding sio0: [FILTER] sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled Timecounters tick every 1.000 msec WARNING: apm_saver module requires apm enabled firewire0: 1 nodes, maxhop <=3D 0, cable IRM =3D 0 (me) firewire0: bus manager 0 (me) acd0: CDRW at ata0-master UDMA33 ad4: 95396MB at ata2-master SATA150 pcm0: pcm0: GEOM_LABEL: Label for provider ad4s2 is msdosfs/SERVICEV001. SMP: AP CPU #1 Launched! Trying to mount root from ufs:/dev/ad4s1a WARNING: / was not properly dismounted <118>Loading configuration files. <118>kernel dumps on /dev/ad4s1b <118>Entropy harvesting: <118> interrupts <118> ethernet <118> point_to_point <118> kickstart <118>. <118>swapon: adding /dev/ad4s1b as swap device <118>Starting file system checks: <118>/dev/ad4s1a: 3029 files, 136398 used, 876617 free (985 frags, 109454 blocks, 0.1% fragmentation) <118>/dev/ad4s1e: DEFER FOR BACKGROUND CHECKING <118>/dev/ad4s1f: DEFER FOR BACKGROUND CHECKING <118>/dev/ad4s1d: DEFER FOR BACKGROUND CHECKING <118>Setting hostuuid: d98c9601-48de-11cb-8437-9f645358500e. <118>Setting hostid: 0x5068f7a9. <118>Mounting local file systems: WARNING: /tmp was not properly dismounted WARNING: /usr was not properly dismounted WARNING: /var was not properly dismounted /var: mount pending error: blocks 68 files 11 <118>. <118>Setting hostname: t61-laptop.localhost. <118>net.inet6.ip6.auto_linklocal: <118>1 <118> -> <118>0 <118> <118>Starting wpa_supplicant. <118>wpi0: no link ... <118>. <118>. <118>. <118> got link <118>DHCPREQUEST on wpi0 to 255.255.255.255 port 67 <118> Fatal trap 12: page fault while in kernel mode cpuid =3D 1; apic id =3D 01 fault virtual address =3D 0xc fault code =3D supervisor read, page not present instruction pointer =3D 0x20:0xc05da11f stack pointer =3D 0x28:0xe5a75b00 frame pointer =3D 0x28:0xe5a75b18 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, def32 1, gran 1 processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process =3D 33 (irq17: pcm0 wpi0++) trap number =3D 12 panic: page fault cpuid =3D 1 Uptime: 14s Physical memory: 1998 MB Dumping 77 MB: 62 46 30 14 #0 doadump () at pcpu.h:195 195 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:195 #1 0xc059286a in boot (howto=3D260) at /usr/src/sys/kern/kern_shutdown.c:4= 09 #2 0xc0592b3d in panic (fmt=3DVariable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:563 #3 0xc07cfd44 in trap_fatal (frame=3D0xe5a75ac0, eva=3D12) at /usr/src/sys/i386/i386/trap.c:899 #4 0xc07cff94 in trap_pfault (frame=3D0xe5a75ac0, usermode=3D0, eva=3D12) at /usr/src/sys/i386/i386/trap.c:812 #5 0xc07d08fa in trap (frame=3D0xe5a75ac0) at /usr/src/sys/i386/i386/trap.= c:490 #6 0xc07b82db in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #7 0xc05da11f in m_copydata (m=3D0x0, off=3D4, len=3D8, cp=3D0xe5a75b38 "= =D0=F2d=C5") at /usr/src/sys/kern/uipc_mbuf.c:808 #8 0xc0638952 in tkip_demic (k=3D0xc564f2d0, m=3D0xc5654700, force=3D0) at /usr/src/sys/net80211/ieee80211_crypto_tkip.c:338 #9 0xc064238e in ieee80211_input (ic=3D0xc564e008, m=3D0xc5654700, ni=3D0x= c5b66000, rssi=3D51, noise=3D0, rstamp=3D0) at ieee80211_crypto.h:186 #10 0xc07ae7f7 in wpi_intr (arg=3D0xc564e000) at /usr/src/sys/dev/wpi/if_wpi.c:1699 #11 0xc0576df2 in ithread_loop (arg=3D0xc562caf0) at /usr/src/sys/kern/kern_intr.c:1036 #12 0xc0573e01 in fork_exit (callout=3D0xc0576c51 , arg=3D0xc562caf0, frame=3D0xe5a75d38) at /usr/src/sys/kern/kern_fork.c:754 #13 0xc07b8350 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:= 205 --=20 Hanns Hartman Identity Engines Inc. - Senior Software Engineer hhartman@idengines.com Western Collegiate Cycling - Conference Director hhartman@usacycling.org From owner-freebsd-current@FreeBSD.ORG Thu Jan 3 19:21:09 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7FEB816A46E; Thu, 3 Jan 2008 19:21:09 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 3404C13C442; Thu, 3 Jan 2008 19:21:09 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id AC6D52089; Thu, 3 Jan 2008 20:21:01 +0100 (CET) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: -0.1/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 9D83C207E; Thu, 3 Jan 2008 20:21:01 +0100 (CET) Received: by ds4.des.no (Postfix, from userid 1001) id 80C838449F; Thu, 3 Jan 2008 20:21:01 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Jason Evans References: <477C82F0.5060809@freebsd.org> Date: Thu, 03 Jan 2008 20:21:01 +0100 In-Reply-To: <477C82F0.5060809@freebsd.org> (Jason Evans's message of "Wed\, 02 Jan 2008 22\:38\:40 -0800") Message-ID: <863ateemw2.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, Poul-Henning Kamp Subject: Re: sbrk(2) broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2008 19:21:09 -0000 Jason Evans writes: > [sbrk is broken] The real question is why we would revert perfectly good code (jemalloc) from using a modern interface to using one that has been obsolete for twenty years, and marked as such in the man page for seven years. If rwatson@ wants malloc() to respect resource limits, he can bloody well fix mmap(). Until he does, the datasize limit is a joke anyway, as anyone can circumvent it by either using mmap() instead of malloc() or setting _malloc_options before calling malloc(). DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Thu Jan 3 19:21:18 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BE40D16A418 for ; Thu, 3 Jan 2008 19:21:18 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail16.syd.optusnet.com.au (mail16.syd.optusnet.com.au [211.29.132.197]) by mx1.freebsd.org (Postfix) with ESMTP id 520C713C4E8 for ; Thu, 3 Jan 2008 19:21:18 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from server.vk2pj.dyndns.org (c220-239-20-82.belrs4.nsw.optusnet.com.au [220.239.20.82]) by mail16.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m03JL5B6013293 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Jan 2008 06:21:08 +1100 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.2/8.14.1) with ESMTP id m03JL5vJ051541; Fri, 4 Jan 2008 06:21:05 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.2/8.14.2/Submit) id m03JL4Wk051540; Fri, 4 Jan 2008 06:21:04 +1100 (EST) (envelope-from peter) Date: Fri, 4 Jan 2008 06:21:04 +1100 From: Peter Jeremy To: Jeff Roberson Message-ID: <20080103192104.GS947@server.vk2pj.dyndns.org> References: <20071223092332.GJ25002@server.vk2pj.dyndns.org> <476F81AF.7000505@gmail.com> <20080101190607.B957@desktop> <20080102105049.GA903@server.vk2pj.dyndns.org> <20080102033011.P957@desktop> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UPT3ojh+0CqEDtpF" Content-Disposition: inline In-Reply-To: <20080102033011.P957@desktop> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-current@freebsd.org Subject: Re: idle priority scheduling broken in 7.0-BETA4 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2008 19:21:18 -0000 --UPT3ojh+0CqEDtpF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 02, 2008 at 03:31:34AM -1000, Jeff Roberson wrote: >ah, I'm sorry. the new line with PRI_FIFO should read PRI_FIFO_BIT. I=20 >tested the patch but not with any idle prio tasks that run forever. That seems to work and I don't see any problems with it. There were seven watchdog restarts over about 3/4 hr whilst the system was doing a buildworld but this is probably not completely unreasonable. One oddity I noticed is that setiathome (unlike einstein@home) has one thread that seems to have lost the idle bit (though that thread appears to just idle). This is equivalent to a process increasing its priority so I wouldn't have expected it. PID USERNAME PRI NICE SIZE RES STATE TIME WCPU COMMAND 51503 boinc 171 i31 39944K 33052K RUN 3:43 100.00% setiathome-5.= 27.i 51503 boinc 8 19 39944K 33052K nanslp 3:43 0.00% setiathome-5.2= 7.i3 10 root 171 ki31 0K 8K RUN 2:51 0.00% idle 4 root -8 - 0K 8K - 0:54 0.00% g_down Let me know if you really want to get boinc working for yourself. --=20 Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. --UPT3ojh+0CqEDtpF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHfTWg/opHv/APuIcRAvsmAJ9yBXh2tG9Hga12f5Jt6aSTDv+l5gCfdD+B xF69o9BWnCLAIxjftaCWNFg= =rBPY -----END PGP SIGNATURE----- --UPT3ojh+0CqEDtpF-- From owner-freebsd-current@FreeBSD.ORG Thu Jan 3 20:39:47 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3366416A417 for ; Thu, 3 Jan 2008 20:39:47 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay02.kiev.sovam.com (relay02.kiev.sovam.com [62.64.120.197]) by mx1.freebsd.org (Postfix) with ESMTP id BD98313C4CE for ; Thu, 3 Jan 2008 20:39:46 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.226] (helo=deviant.kiev.zoral.com.ua) by relay02.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1JAWqn-000Gaa-AP; Thu, 03 Jan 2008 22:39:45 +0200 Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m03Kda0s010747; Thu, 3 Jan 2008 22:39:36 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id m03Kda1h010746; Thu, 3 Jan 2008 22:39:36 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 3 Jan 2008 22:39:36 +0200 From: Kostik Belousov To: Jason Evans Message-ID: <20080103203936.GX57756@deviant.kiev.zoral.com.ua> References: <477C82F0.5060809@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7+SiJqgcYR1fH3/L" Content-Disposition: inline In-Reply-To: <477C82F0.5060809@freebsd.org> User-Agent: Mutt/1.4.2.3i X-Scanner-Signature: 4fcf7b0c3bd3465242a83b332b797d78 X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 1976 [Dec 29 2007] X-SpamTest-Info: helo_type=3 X-SpamTest-Info: {received from trusted relay: not dialup} X-SpamTest-Method: none X-SpamTest-Method: Local Lists X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0255], KAS30/Release Cc: freebsd-current@freebsd.org Subject: Re: sbrk(2) broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2008 20:39:47 -0000 --7+SiJqgcYR1fH3/L Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 02, 2008 at 10:38:40PM -0800, Jason Evans wrote: > Poul-Henning noticed today that xchat fails to start if malloc uses sbrk= =20 > internally. This failure happens during the first call to malloc, with= =20 > the following message: >=20 > Fatal error 'Can't allocate initial thread' at line 335 in file=20 > /usr/src/lib/libthr/thread/thr_init.c (errno =3D 12) >=20 > This can be worked around with MALLOC_OPTIONS=3DdM . >=20 > The problem does not appear to be specific to jemalloc; I reverted=20 > src/lib/libc/stdlib/malloc.c to revision 1.92 (last phkmalloc revision),= =20 > which also uses sbrk, and the failure mode is the same. >=20 > The failure occurs on both i386 and amd64. It appears that sbrk(0)=20 > returns an address that is in the address range normally used by mmap.=20 > So, the first call to sbrk with a non-zero increment is fantastically=20 > wrong. On i386 (ktrace output): >=20 > 1013 xchat CALL break(0x28200000) > 1013 xchat RET break -1 errno 12 Cannot allocate memory >=20 > On amd64 (truss ouput): >=20 > break(0x800900000) ERR#12 'Cannot allocate memory' >=20 > sbrk is not a true system call, so it seems like the problem should have= =20 > something to do with the _end data symbol. I looked at it in gdb though= =20 > and never saw an unreasonable value, despite bogus sbrk(0) results. I=20 > do not know offhand how to get the addresses of .minbrk and .curbrk=20 > (register inspection within gdb while stepping through sbrk?), which are= =20 > what sbrk actually uses (see src/lib/libc/amd64/sys/sbrk.S). Perhaps=20 > the loader isn't initializing them correctly... >=20 > I am quite pressed for time at the moment, and cannot look into this in= =20 > any more detail for at least a couple of weeks. If anyone knows what=20 > the problem is, please let me know. I cannot say definitely what happen, but please note that the _end symbol is defined by linker script, and it shall be present in all executable and shared objects. The value you reported would be naturally the _end value for some shared object. I tried both the RELENG_7 and HEAD, and sbrk(0) correctly returns a seemingly valid value like 0x8049644. #include #include #include int main(int argc, char *argv) { void *p; p =3D sbrk(0); printf("%p\n", p); return (0); } --7+SiJqgcYR1fH3/L Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHfUgIC3+MBN1Mb4gRAt/AAJ40IuGUgbOVqW6H+DM9EqFC0AGfUQCgr1Rv 80AUbdS/QZ13Q/kR+GSqpwQ= =3IcV -----END PGP SIGNATURE----- --7+SiJqgcYR1fH3/L-- From owner-freebsd-current@FreeBSD.ORG Thu Jan 3 21:00:24 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 34E1416A46B for ; Thu, 3 Jan 2008 21:00:24 +0000 (UTC) (envelope-from peter.schuller@infidyne.com) Received: from smtp.infidyne.com (ds9.infidyne.com [88.80.6.206]) by mx1.freebsd.org (Postfix) with ESMTP id DCB1D13C4DB for ; Thu, 3 Jan 2008 21:00:23 +0000 (UTC) (envelope-from peter.schuller@infidyne.com) Received: from c-8216e555.03-51-73746f3.cust.bredbandsbolaget.se (c-8216e555.03-51-73746f3.cust.bredbandsbolaget.se [85.229.22.130]) by smtp.infidyne.com (Postfix) with ESMTP id 3B1D4755CE; Thu, 3 Jan 2008 22:00:22 +0100 (CET) From: Peter Schuller To: freebsd-current@freebsd.org Date: Thu, 3 Jan 2008 22:00:16 +0100 User-Agent: KMail/1.9.7 References: <477C82F0.5060809@freebsd.org> <863ateemw2.fsf@ds4.des.no> In-Reply-To: <863ateemw2.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart5171116.mP4KcXQ2ne"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200801032200.25650.peter.schuller@infidyne.com> Cc: Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?= , Jason Evans Subject: Re: sbrk(2) broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2008 21:00:24 -0000 --nextPart5171116.mP4KcXQ2ne Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline > The real question is why we would revert perfectly good code (jemalloc) > from using a modern interface to using one that has been obsolete for > twenty years, and marked as such in the man page for seven years. Also, may I humbly inject a user centric view here - it is pretty annoying = to=20 be limited to 500 MB of mallocable memory on 32 bit machines when you expec= t=20 3 GB to be usable (with 1 GB mapped to the kernel). I scratched my head for a long time as to why I was getting out of memory=20 errors in spite of carefully setting resource limits and ensuring virtual=20 memory was available; at some later point in time I discovered the hard-cod= ed=20 distinction between sbrk():able and mmap():able memory. I am not sure what = I=20 was supposed to find this in the documentation (I found it by chance=20 Googling). If sbrk() is indeed to be used by the default malloc, one definitely user=20 visible annoyance will be the 500 MB limit. At least with mmap() that will = be=20 2.5 GB, unless I am misstaken, which is much closer to what one might expec= t=20 and thus less likely to cause problems in the common case. Changing maxdsize to be > 500 MB is probably bad too, from a user centric=20 view, since you don't want to cause the equivalent problems for programs th= at=20 do not use malloc(), but are indeed coded with "modern virtual memory" (as= =20 the man page calls it) in mind. Better to leave this problem to those=20 programs that use sbrk() directly. Another consequence is that if the sysadmin really wants a maximum amount o= f=20 mmap():able memory, the maxdsize can presumably be lowered quite heftily=20 without affecting the vast majority of applications. With malloc() use of=20 sbrk() however, you will have mutual exclusivity between the common case=20 (malloc() users), and special purpose applications that *do* try to be nice= ,=20 modern and use mmap() instead of sbrk(). With mutual exclusivity between=20 malloc() users and sbrk() users, at least you can kinda blame the sbrk() us= er=20 for using an obsolete interface. =2D-=20 / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller ' Key retrieval: Send an E-Mail to getpgpkey@scode.org E-Mail: peter.schuller@infidyne.com Web: http://www.scode.org --nextPart5171116.mP4KcXQ2ne Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBHfUzpDNor2+l1i30RAlbsAJ909pEzkhUjnXZvBYShQfUQx6glgwCePwhB 3Czbf4ypqFjtYlq4n8yi9u8= =Cp8o -----END PGP SIGNATURE----- --nextPart5171116.mP4KcXQ2ne-- From owner-freebsd-current@FreeBSD.ORG Thu Jan 3 21:27:27 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 813B916A421; Thu, 3 Jan 2008 21:27:27 +0000 (UTC) (envelope-from jfesler@gigo.com) Received: from goat.gigo.com (goat.gigo.com [216.218.228.114]) by mx1.freebsd.org (Postfix) with ESMTP id 6F26713C455; Thu, 3 Jan 2008 21:27:27 +0000 (UTC) (envelope-from jfesler@gigo.com) Received: from goat.gigo.com (goat.gigo.com [216.218.228.114]) by goat.gigo.com (Postfix) with ESMTP id 96141B838; Thu, 3 Jan 2008 13:08:18 -0800 (PST) Date: Thu, 3 Jan 2008 13:08:18 -0800 (PST) From: Jason Fesler To: Peter Schuller In-Reply-To: <200801032200.25650.peter.schuller@infidyne.com> Message-ID: References: <477C82F0.5060809@freebsd.org> <863ateemw2.fsf@ds4.des.no> <200801032200.25650.peter.schuller@infidyne.com> User-Agent: Alpine 1.00 (BSF 882 2007-12-20) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: =?ISO-8859-15?Q?Dag-Erling_Sm=F8rgrav?= , freebsd-current@freebsd.org, Jason Evans Subject: Re: sbrk(2) broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2008 21:27:27 -0000 > Also, may I humbly inject a user centric view here - it is pretty annoying to > be limited to 500 MB of mallocable memory on 32 bit machines when you expect > 3 GB to be usable (with 1 GB mapped to the kernel). amen. :-( Has anyone tried upgrading a system from i386 to amd_64 with any success? maxdsize tweaks and reboots are disappointing at best. From owner-freebsd-current@FreeBSD.ORG Thu Jan 3 22:22:02 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 714EF16A41A; Thu, 3 Jan 2008 22:22:02 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail.speedfactory.net [66.23.216.219]) by mx1.freebsd.org (Postfix) with ESMTP id 1621613C467; Thu, 3 Jan 2008 22:22:01 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.8q) with ESMTP id 227189474-1834499 for multiple; Thu, 03 Jan 2008 17:01:54 -0500 Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id m03M3XHs031287; Thu, 3 Jan 2008 17:03:33 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Thu, 3 Jan 2008 16:52:19 -0500 User-Agent: KMail/1.9.6 References: <474D81DB.7020004@FreeBSD.org> <071130112653E.701@www.mmlab.cse.yzu.edu.tw> In-Reply-To: <071130112653E.701@www.mmlab.cse.yzu.edu.tw> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200801031652.20807.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Thu, 03 Jan 2008 17:03:38 -0500 (EST) X-Virus-Scanned: ClamAV 0.91.2/5351/Thu Jan 3 15:30:12 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Remko Lodder , Tai-hwa Liang , kib@freebsd.org Subject: Re: [Fwd: Re: kern/118258 sysctl causing panics on 7.0-xxx] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2008 22:22:02 -0000 On Thursday 29 November 2007 10:53:32 pm Tai-hwa Liang wrote: > On Wed, 28 Nov 2007, Remko Lodder wrote: > > Hello, > > > > So as per Jeff's information, can someone from the -current > > list either contact jeff or try to resolve the problems > > mentioned? :) > > This is a longstanding bug which also exists in RELENG_6. It turns out > that 'sysctl kern.ttys' after a terminal device is removed could trigger > this panic reliably. For example, do 'sysctl kern.ttys' multiple times > after detaching an USB serial-to-rs232 cable or a PCMCIA modem card. > > Alternatively, following script would demo the panic if you don't have > a physically removable terminal device: > > #!/bin/sh > # > # Warning! Running this script as root will panic your CURRENT box... > # > while true; do > kldload dcons > kldunload dcons > ls /dev > sysctl kern.ttys > sleep 1 > done > > This seems to be a race between devfs and destroy_dev(), Cc'ing kib@ > since he probably has more clues in this area. Try this patch. Also available at http://www.FreeBSD.org/~jhb/patches/ttys_sysctl.patch --- //depot/vendor/freebsd/src/sys/fs/devfs/devfs_vnops.c 2007/10/24 19:06:35 +++ //depot/user/jhb/acpipci/fs/devfs/devfs_vnops.c 2007/11/01 17:09:40 @@ -995,17 +995,20 @@ vnode_destroy_vobject(vp); + VI_LOCK(vp); dev_lock(); dev = vp->v_rdev; vp->v_rdev = NULL; if (dev == NULL) { dev_unlock(); + VI_UNLOCK(vp); return (0); } dev->si_usecount -= vp->v_usecount; dev_unlock(); + VI_UNLOCK(vp); dev_rel(dev); return (0); } --- //depot/vendor/freebsd/src/sys/kern/tty.c 2007/07/20 09:45:18 +++ //depot/user/jhb/acpipci/kern/tty.c 2007/11/13 18:59:58 @@ -3040,16 +3040,19 @@ * * XXX: This shall sleep until all threads have left the driver. */ - void ttyfree(struct tty *tp) { + struct cdev *dev; u_int unit; mtx_assert(&Giant, MA_OWNED); ttygone(tp); unit = tp->t_devunit; - destroy_dev(tp->t_mdev); + dev = tp->t_mdev; + tp->t_dev = NULL; + ttyrel(tp); + destroy_dev(dev); free_unr(tty_unit, unit); } @@ -3065,7 +3068,6 @@ tp = TAILQ_FIRST(&tty_list); if (tp != NULL) ttyref(tp); - mtx_unlock(&tty_list_mutex); while (tp != NULL) { bzero(&xt, sizeof xt); xt.xt_size = sizeof xt; @@ -3074,6 +3076,18 @@ xt.xt_cancc = tp->t_canq.c_cc; xt.xt_outcc = tp->t_outq.c_cc; XT_COPY(line); + + /* + * XXX: We hold the tty list lock while doing this to + * work around a race with pty/pts tty destruction. + * They set t_dev to NULL and then call ttyrel() to + * free the structure which will block on the list + * lock before they call destroy_dev() on the cdev + * backing t_dev. + * + * XXX: ttyfree() now does the same since it has been + * fixed to not leak ttys. + */ if (tp->t_dev != NULL) xt.xt_dev = dev2udev(tp->t_dev); XT_COPY(state); @@ -3096,6 +3110,7 @@ XT_COPY(olowat); XT_COPY(ospeedwat); #undef XT_COPY + mtx_unlock(&tty_list_mutex); error = SYSCTL_OUT(req, &xt, sizeof xt); if (error != 0) { ttyrel(tp); @@ -3108,6 +3123,7 @@ mtx_unlock(&tty_list_mutex); ttyrel(tp); tp = tp2; + mtx_lock(&tty_list_mutex); } return (0); } -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Jan 3 22:24:04 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5C87F16A468 for ; Thu, 3 Jan 2008 22:24:04 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id ED01A13C465 for ; Thu, 3 Jan 2008 22:24:03 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.samsco.home (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.8/8.13.8) with ESMTP id m03MNqiu064237; Thu, 3 Jan 2008 15:23:54 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <477D6078.5030805@samsco.org> Date: Thu, 03 Jan 2008 15:23:52 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.11) Gecko/20071128 SeaMonkey/1.1.7 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= References: <477C82F0.5060809@freebsd.org> <863ateemw2.fsf@ds4.des.no> In-Reply-To: <863ateemw2.fsf@ds4.des.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (pooker.samsco.org [168.103.85.57]); Thu, 03 Jan 2008 15:23:54 -0700 (MST) X-Spam-Status: No, score=-1.4 required=5.4 tests=ALL_TRUSTED autolearn=failed version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: freebsd-current@freebsd.org, Jason Evans Subject: Re: sbrk(2) broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2008 22:24:04 -0000 Dag-Erling Smørgrav wrote: > Jason Evans writes: >> [sbrk is broken] > > The real question is why we would revert perfectly good code (jemalloc) > from using a modern interface to using one that has been obsolete for > twenty years, and marked as such in the man page for seven years. > > If rwatson@ wants malloc() to respect resource limits, he can bloody > well fix mmap(). Until he does, the datasize limit is a joke anyway, as > anyone can circumvent it by either using mmap() instead of malloc() or > setting _malloc_options before calling malloc(). > That is a pretty damning argument in my mind. Why make such a major change right before the release when it's effectively useless? Scott From owner-freebsd-current@FreeBSD.ORG Thu Jan 3 22:46:10 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DD84216A418 for ; Thu, 3 Jan 2008 22:46:10 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail.speedfactory.net [66.23.216.219]) by mx1.freebsd.org (Postfix) with ESMTP id 7338113C4E7 for ; Thu, 3 Jan 2008 22:46:10 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.8q) with ESMTP id 227195563-1834499 for multiple; Thu, 03 Jan 2008 17:44:16 -0500 Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id m03Mk709031519; Thu, 3 Jan 2008 17:46:07 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Thu, 3 Jan 2008 17:46:14 -0500 User-Agent: KMail/1.9.6 References: <477C82F0.5060809@freebsd.org> <863ateemw2.fsf@ds4.des.no> <477D6078.5030805@samsco.org> In-Reply-To: <477D6078.5030805@samsco.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200801031746.15225.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Thu, 03 Jan 2008 17:46:07 -0500 (EST) X-Virus-Scanned: ClamAV 0.91.2/5351/Thu Jan 3 15:30:12 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?= , Jason Evans Subject: Re: sbrk(2) broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2008 22:46:10 -0000 On Thursday 03 January 2008 05:23:52 pm Scott Long wrote: > Dag-Erling Sm=F8rgrav wrote: > > Jason Evans writes: > >> [sbrk is broken] > >=20 > > The real question is why we would revert perfectly good code (jemalloc) > > from using a modern interface to using one that has been obsolete for > > twenty years, and marked as such in the man page for seven years. > >=20 > > If rwatson@ wants malloc() to respect resource limits, he can bloody > > well fix mmap(). Until he does, the datasize limit is a joke anyway, as > > anyone can circumvent it by either using mmap() instead of malloc() or > > setting _malloc_options before calling malloc(). > >=20 >=20 > That is a pretty damning argument in my mind. Why make such a major=20 > change right before the release when it's effectively useless? The motivation for the change is to preserve POLA as malloc() does honor=20 RLIMIT_DATA in previous releases (4.x, 6.x, etc.). That said, I think=20 RLIMIT_VMEM is probably more useful going forward. I know at work we have= =20 lots of hacks to deal with maxdsiz and trying to allow apps that use large= =20 malloc() and large mmap both cooperate. Having one resource limit for mall= oc=20 + mmap is probably best for the future. =2D-=20 John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Jan 3 23:09:05 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B868D16A417; Thu, 3 Jan 2008 23:09:05 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 4915D13C4D3; Thu, 3 Jan 2008 23:09:05 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.samsco.home (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.8/8.13.8) with ESMTP id m03N8xJZ064397; Thu, 3 Jan 2008 16:09:00 -0700 (MST) (envelope-from scottl@samsco.org) Message-Id: From: Scott Long To: John Baldwin In-Reply-To: <200801031746.15225.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v915) Date: Thu, 3 Jan 2008 16:08:59 -0700 References: <477C82F0.5060809@freebsd.org> <863ateemw2.fsf@ds4.des.no> <477D6078.5030805@samsco.org> <200801031746.15225.jhb@freebsd.org> X-Mailer: Apple Mail (2.915) X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (pooker.samsco.org [168.103.85.57]); Thu, 03 Jan 2008 16:09:00 -0700 (MST) X-Spam-Status: No, score=-1.4 required=5.4 tests=ALL_TRUSTED autolearn=failed version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= , freebsd-current@freebsd.org, Jason Evans Subject: Re: sbrk(2) broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2008 23:09:05 -0000 On Jan 3, 2008, at 3:46 PM, John Baldwin wrote: > On Thursday 03 January 2008 05:23:52 pm Scott Long wrote: >> Dag-Erling Sm=F8rgrav wrote: >>> Jason Evans writes: >>>> [sbrk is broken] >>> >>> The real question is why we would revert perfectly good code =20 >>> (jemalloc) >>> from using a modern interface to using one that has been obsolete =20= >>> for >>> twenty years, and marked as such in the man page for seven years. >>> >>> If rwatson@ wants malloc() to respect resource limits, he can bloody >>> well fix mmap(). Until he does, the datasize limit is a joke =20 >>> anyway, as >>> anyone can circumvent it by either using mmap() instead of =20 >>> malloc() or >>> setting _malloc_options before calling malloc(). >>> >> >> That is a pretty damning argument in my mind. Why make such a major >> change right before the release when it's effectively useless? > > The motivation for the change is to preserve POLA as malloc() does =20 > honor > RLIMIT_DATA in previous releases (4.x, 6.x, etc.). That said, I think > RLIMIT_VMEM is probably more useful going forward. I know at work =20 > we have > lots of hacks to deal with maxdsiz and trying to allow apps that use =20= > large > malloc() and large mmap both cooperate. Having one resource limit =20 > for malloc > + mmap is probably best for the future. > If it were happening on a stable branch, I'd agree more with the POLA =20= argument. The tradeoff between last minute destabilization, which is exactly =20 what happened here, and the highly imperfect and antiquated justification, is pretty =20= bogus. Scott From owner-freebsd-current@FreeBSD.ORG Thu Jan 3 23:35:45 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E940B16A417 for ; Thu, 3 Jan 2008 23:35:45 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from webaccess-cl.virtdom.com (webaccess-cl.virtdom.com [216.240.101.25]) by mx1.freebsd.org (Postfix) with ESMTP id AFB6513C468 for ; Thu, 3 Jan 2008 23:35:45 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from [192.168.1.107] (cpe-24-94-75-93.hawaii.res.rr.com [24.94.75.93]) (authenticated bits=0) by webaccess-cl.virtdom.com (8.13.6/8.13.6) with ESMTP id m03NZevX094643; Thu, 3 Jan 2008 18:35:44 -0500 (EST) (envelope-from jroberson@chesapeake.net) Date: Thu, 3 Jan 2008 13:37:06 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: Peter Jeremy In-Reply-To: <20080103192104.GS947@server.vk2pj.dyndns.org> Message-ID: <20080103133510.D957@desktop> References: <20071223092332.GJ25002@server.vk2pj.dyndns.org> <476F81AF.7000505@gmail.com> <20080101190607.B957@desktop> <20080102105049.GA903@server.vk2pj.dyndns.org> <20080102033011.P957@desktop> <20080103192104.GS947@server.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: idle priority scheduling broken in 7.0-BETA4 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2008 23:35:46 -0000 On Fri, 4 Jan 2008, Peter Jeremy wrote: > On Wed, Jan 02, 2008 at 03:31:34AM -1000, Jeff Roberson wrote: >> ah, I'm sorry. the new line with PRI_FIFO should read PRI_FIFO_BIT. I >> tested the patch but not with any idle prio tasks that run forever. > > That seems to work and I don't see any problems with it. There were > seven watchdog restarts over about 3/4 hr whilst the system was doing > a buildworld but this is probably not completely unreasonable. This is a boinc watchdog? The client just didn't get to run for too long during the buildworld? > > One oddity I noticed is that setiathome (unlike einstein@home) has one > thread that seems to have lost the idle bit (though that thread appears > to just idle). This is equivalent to a process increasing its priority > so I wouldn't have expected it. If you notice the second thread is sitting in nanosleep. In BSD there is a static priority boost after sleeping that is revoked when you wake up. This can also happen from priority propagation if you grab a lock that a high priority thread wants. > > PID USERNAME PRI NICE SIZE RES STATE TIME WCPU COMMAND > 51503 boinc 171 i31 39944K 33052K RUN 3:43 100.00% setiathome-5.27.i > 51503 boinc 8 19 39944K 33052K nanslp 3:43 0.00% setiathome-5.27.i3 > 10 root 171 ki31 0K 8K RUN 2:51 0.00% idle > 4 root -8 - 0K 8K - 0:54 0.00% g_down > > Let me know if you really want to get boinc working for yourself. If there are any further complaints I will. Is there any chance you could also try it with nice +20 or nice +10 and report how the system behaves? Thanks! Jeff > > -- > Peter Jeremy > Please excuse any delays as the result of my ISP's inability to implement > an MTA that is either RFC2821-compliant or matches their claimed behaviour. > From owner-freebsd-current@FreeBSD.ORG Thu Jan 3 23:44:30 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 135B816A419 for ; Thu, 3 Jan 2008 23:44:30 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.freebsd.org (Postfix) with ESMTP id CFA0D13C448 for ; Thu, 3 Jan 2008 23:44:29 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.14.1/8.13.7) with ESMTP id m03NY96t019295; Thu, 3 Jan 2008 15:34:09 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.14.1/8.13.4/Submit) id m03NY7Zd019292; Thu, 3 Jan 2008 15:34:07 -0800 (PST) Date: Thu, 3 Jan 2008 15:34:07 -0800 (PST) From: Matthew Dillon Message-Id: <200801032334.m03NY7Zd019292@apollo.backplane.com> To: Mikhail Teterin References: <200801012116.m01LGQhN012860@bonkers.video-collage.com> Cc: efinleywork@efinley.com, current@freebsd.org Subject: Re: a new way to hang 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2008 23:44:30 -0000 :> > I wonder, if this is also a problem on DragonFlyBSD... :> :> Since Dragonfly is FreeBSD 4 + some stuff it is unlikely that it even :> supports UFS snapshots. : :Yes, you are right. I confused the -L with the -C option... : :Thanks, : : -mi Well, that description of DragonFly isn't really accurate any more, we're about as close to FreeBSD 4 as FreeBSD 7 is.... meaning, not really all that close any more, except for the poor interrupt routing subsystem. I froze all the softupdates work in DragonFly prior to the snapshot code, and have not performed or allowed any new softupdates work to be ported over since then, only bug fixes. As much as I like the concept of softupdates, its been a huge source of bugs in the system ever since it was first introduced. The snapshot code scares me, frankly. I also removed most of the buffer cache hacks related to both it and the background writing code long ago... those scared me too. I kept the b_dep concept and implemented the per-buffer b_ops as Kirk (or someone) suggested in their comments, though, because HAMMER needs those features. DragonFly has a new filesystem called HAMMER in the works which should become production ready in a few months. All primary operations work now so it is very real, but major pieces still need to be written and others need to be rewritten and stabilized. It's in pre-alpha state now and will be early-alpha by the DFly 2.0 release later this month. It should be in a state that can be ported without having to play constant catchup in maybe 2-3 months. This filesystem has full historical capabilities... you don't even have to make snapshots per say, just sync, and you can get at any data as-of any point in the past with a simple @@ file/directory name extension. In anycase, my expectation is that HAMMER will replace UFS as our default by the end of this year. Once it gets more polished I don't expect it to be all that difficult to port. You can see the current state of the work at: http://www.dragonflybsd.org/cvsweb/src/sys/vfs/hammer/ I should have done this years ago. Ah well, I'm doing it now. -Matt From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 00:04:10 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 46F8D16A419 for ; Fri, 4 Jan 2008 00:04:10 +0000 (UTC) (envelope-from hg@queue.to) Received: from pickle.queue.to (pickle.queue.to [71.180.69.18]) by mx1.freebsd.org (Postfix) with ESMTP id C849E13C458 for ; Fri, 4 Jan 2008 00:04:09 +0000 (UTC) (envelope-from hg@queue.to) Received: (qmail 56647 invoked from network); 3 Jan 2008 18:37:28 -0500 Received: from cally.queue.to (172.16.0.6) by pickle.queue.to with ESMTP; 3 Jan 2008 18:37:28 -0500 Message-ID: <477D71B8.9050301@queue.to> Date: Thu, 03 Jan 2008 18:37:28 -0500 From: Howard Goldstein User-Agent: Thunderbird 2.0.0.9 (X11/20071116) MIME-Version: 1.0 To: drosih@rpi.edu References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 04 Jan 2008 00:09:25 +0000 Cc: freebsd-current@freebsd.org Subject: Re: FreeBSD on Asus EEE PC X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 00:04:10 -0000 Garance A Drosihn wrote: > At 1:12 PM -0800 1/2/08, Kip Macy wrote: >> Do you know what network chip it uses? >> >> -Kip > > One of my friends has an Eee with freebsd working on it. I believe > he had to do some work to get the network card running, but he has > it working okay now. I'll see if he's following this mailing list. > Dang did he keep a record of what he did? Will he share? Which FreeBSD version? Does it support the touchpad? Please shackle him to a terminal for answers to these and other pressing questions From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 00:21:27 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C626216A418 for ; Fri, 4 Jan 2008 00:21:27 +0000 (UTC) (envelope-from Benjamin.Close@clearchain.com) Received: from ipmail04.adl2.internode.on.net (ipmail04.adl2.internode.on.net [203.16.214.57]) by mx1.freebsd.org (Postfix) with ESMTP id 42C5B13C442 for ; Fri, 4 Jan 2008 00:21:27 +0000 (UTC) (envelope-from Benjamin.Close@clearchain.com) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAPwKfUd5LV3S/2dsb2JhbACBV6hh X-IronPort-AV: E=Sophos;i="4.24,241,1196602200"; d="scan'208";a="27874197" Received: from ppp121-45-93-210.lns10.adl6.internode.on.net (HELO mail.clearchain.com) ([121.45.93.210]) by ipmail04.adl2.internode.on.net with ESMTP; 04 Jan 2008 10:51:24 +1030 Received: from [192.168.155.249] (draco.internal.clearchain.com [192.168.155.249]) (authenticated bits=0) by mail.clearchain.com (8.13.8/8.13.8) with ESMTP id m040LMJ8019039 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Jan 2008 10:51:22 +1030 (CST) (envelope-from Benjamin.Close@clearchain.com) Message-ID: <477D7BFE.9040609@clearchain.com> Date: Fri, 04 Jan 2008 10:51:18 +1030 From: Benjamin Close User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Hanns Hartman References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.92, clamav-milter version 0.92 on pegasus.clearchain.com X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (mail.clearchain.com [192.168.154.1]); Fri, 04 Jan 2008 10:51:22 +1030 (CST) Cc: freebsd-current@freebsd.org Subject: Re: panic about half the time with WPA+WPI during startup X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 00:21:27 -0000 Hanns Hartman wrote: > Hi All, > I am running FreeBSD 7-Prerelease on an Lenovo T61. I > am having problems with the WPI driver doing WPA TKIP authentication during > startup. Sometimes it works perfectly with no problems, other times it > kernel panics (see the kgdb output below). > > If you need more debugging information or if you need me to try > something just let me know and I will be happy to help. Also if this > email is not appropriate for this list please feel free to direct me > to the appropriate one. > > thanks > Hanns > > Here is how I start WPA auth on my WPI wireless card. > > Hi Hans, Can you try the p4 version of the driver and see if you still have the same problems. Details about how to get it are at: http://www.clearchain.com/wiki/wpi/ Cheers, Benjamin From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 00:26:32 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6153816A417; Fri, 4 Jan 2008 00:26:32 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 2A80313C461; Fri, 4 Jan 2008 00:26:32 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id E3EFB483F4; Thu, 3 Jan 2008 19:26:31 -0500 (EST) Date: Fri, 4 Jan 2008 00:26:31 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= In-Reply-To: <863ateemw2.fsf@ds4.des.no> Message-ID: <20080104002002.L30578@fledge.watson.org> References: <477C82F0.5060809@freebsd.org> <863ateemw2.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="621616949-1713681321-1199406391=:30578" Cc: freebsd-current@freebsd.org, Jason Evans , Poul-Henning Kamp Subject: Re: sbrk(2) broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 00:26:32 -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. --621616949-1713681321-1199406391=:30578 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Thu, 3 Jan 2008, Dag-Erling Sm=F8rgrav wrote: > Jason Evans writes: >> [sbrk is broken] > > The real question is why we would revert perfectly good code (jemalloc) f= rom=20 > using a modern interface to using one that has been obsolete for twenty= =20 > years, and marked as such in the man page for seven years. > > If rwatson@ wants malloc() to respect resource limits, he can bloody well= =20 > fix mmap(). Until he does, the datasize limit is a joke anyway, as anyon= e=20 > can circumvent it by either using mmap() instead of malloc() or setting= =20 > _malloc_options before calling malloc(). The issue here was that there were a number of reports that out-of-control= =20 applications were toasting systems that weren't getting toasted under 6.x. = I=20 experienced this on my web server, but the ports build cluster has been=20 running into it for months. The symptom is that a single application exhau= sts=20 swap, causing all sorts of things to break (tm), killing of other large=20 processes, etc. To be clear, in the new world order, instead of getting NU= LL=20 back from malloc(3), SIGKILL is delivered to large processes. When I e-mailed Jason Evans and Alan Cox about it, I suggested that we=20 actually teach malloc(3) to enforce an allocation limit itself by querying = a=20 limit once at process startup, and then using its own accounting to decide= =20 when to start failing requests. As an alternative model that would require= =20 some more infrastructural changes, I suggested a new mmap() flag that hinte= d=20 to the kernel that the page should count against a swap/anonymous memory=20 limit, but that we should avoid more serious changes at the last minute bef= ore=20 a release. Alan suggested the the model Jason ended up implementing as a= =20 lower risk way to restore the 6.x resource limits non-disruptively. As it= =20 turned out, this proved much more complicated than expected. The right answer is presumably to introduce a new LIMIT_SWAP, which limits = the=20 allocation of anonymous memory by processes, and size it to something like = 90%=20 of swap space by default. Since that won't be happening before 7.0, I beli= eve=20 the consensus is to simply not MFC the changes for 7 and proceed with the= =20 release. However, having a resource limit on swap use in order to prevent = the=20 above scenario is actually quite important: SIGKILL of arbitrary processes = is=20 not a good way to deal with one run-away process, and the virtual memory si= ze=20 limit, while also useful, prevents you from limiting the allocation of swap= =20 without also limiting memory mapping. So wouldn't help, for example, to li= mit=20 swap used by a web cache that memory mapped cache files. Robert N M Watson Computer Laboratory University of Cambridge --621616949-1713681321-1199406391=:30578-- From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 00:31:57 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 394C516A418; Fri, 4 Jan 2008 00:31:57 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 0C93D13C459; Fri, 4 Jan 2008 00:31:57 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id C4F9947BDB; Thu, 3 Jan 2008 19:31:56 -0500 (EST) Date: Fri, 4 Jan 2008 00:31:56 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Scott Long In-Reply-To: Message-ID: <20080104002715.N30578@fledge.watson.org> References: <477C82F0.5060809@freebsd.org> <863ateemw2.fsf@ds4.des.no> <477D6078.5030805@samsco.org> <200801031746.15225.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= , freebsd-current@freebsd.org, Jason Evans Subject: Re: sbrk(2) broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 00:31:57 -0000 On Thu, 3 Jan 2008, Scott Long wrote: >>> That is a pretty damning argument in my mind. Why make such a major >>> change right before the release when it's effectively useless? >> >> The motivation for the change is to preserve POLA as malloc() does honor >> RLIMIT_DATA in previous releases (4.x, 6.x, etc.). That said, I think >> RLIMIT_VMEM is probably more useful going forward. I know at work we have >> lots of hacks to deal with maxdsiz and trying to allow apps that use large >> malloc() and large mmap both cooperate. Having one resource limit for >> malloc + mmap is probably best for the future. The reason I'm more of a fan of introducing LIMIT_SWAP is that I'd like to be able to specifically avoid swap exhaustion by a process without preventing it from memory mapping large files. > If it were happening on a stable branch, I'd agree more with the POLA > argument. The tradeoff between last minute destabilization, which is exactly > what happened here, and the highly imperfect and antiquated justification, > is pretty bogus. When Alan proposed this as the approach, it was presumably under the assumption that it would be non-disruptive. As it has proven highly disruptive, it's obviously not getting MFC'd for the release. Instead we'll have to work on a solution for after .0, but make sure to document that the default swap resource limits effectively enforced in all prior FreeBSD releases are *not* enforced on 7.0, and that administrators wanting to prevent users from exhausting swap accidentally with something like the following: int main(int argc, char *argv[]) { char *c; while (1) { c = malloc(getpagsize()); if (c == NULL) err(-1, "malloc"); *c = 'a'; } } will need to now manually set the virtual memory limit in login.conf. Note that the above strongly resembles frequently run CGI scripts written by many naive CGI script authors, so is something that we'd like to be robust against in the same way we prefer to be robust against: int main(int argc, char *argv[]) { while (1) { fork(); } } Smacking the user is obviously a good idea, but taking down the multi-user web server is not. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 01:56:24 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5EB9B16A417 for ; Fri, 4 Jan 2008 01:56:24 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.delphij.net (delphij-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:2c9::2]) by mx1.freebsd.org (Postfix) with ESMTP id 76BC513C45B for ; Fri, 4 Jan 2008 01:56:23 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (unknown [202.108.54.204]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.delphij.net (Postfix) with ESMTP id B73DF28481 for ; Fri, 4 Jan 2008 09:56:21 +0800 (CST) Received: from localhost (unknown [202.108.54.204]) by tarsier.geekcn.org (Postfix) with ESMTP id 5B83EEDB284; Fri, 4 Jan 2008 09:56:21 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([202.108.54.204]) by localhost (mail.geekcn.org [202.108.54.204]) (amavisd-new, port 10024) with ESMTP id NMtfgMtCh+ep; Fri, 4 Jan 2008 09:56:19 +0800 (CST) Received: from charlie.delphij.net (71.5.7.139.ptr.us.xo.net [71.5.7.139]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id 169D3EDB32A; Fri, 4 Jan 2008 09:56:00 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:subject:x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=EG/HWp6k3mn6GuOaYy6GKuJ+68q2AAYoCUahQeoT3AwMOYlK/8tnzLC2+j53n/J1P PL0h+NxMXWSOBjVFk+OPA== Message-ID: <477D922F.2040308@delphij.net> Date: Thu, 03 Jan 2008 17:55:59 -0800 From: Xin LI Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.9 (X11/20071125) MIME-Version: 1.0 To: FreeBSD Current X-Enigmail-Version: 0.95.5 OpenPGP: id=18EDEBA0; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Strange kernel trap 12 with vm_page_splay() on FreeBSD/i386 SMP 7.0-RC1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 01:56:24 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Recently I have encountered a strange kernel trap 12, which always end up at vm_page_splay() like this, the fault va and IP vary from time to time: Fatal trap 12: page fault while in kernel mode cpuid = 3; apic id = 03 fault virtual address = 0xfff9a4b5 fault code = supervisor read, page not present instruction pointer = 0x20:0xc073eec7 stack pointer = 0x28:0xe66fa94c frame pointer = 0x28:0xe66fa9a4 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 = 1123 (mysqld) trap number = 12 panic: page fault cpuid = 3 Uptime: 10m6s Physical memory: 1015 MB Dumping 130 MB: 115 99 83 67 51 35 19 3 And the backtrace was: #0 doadump () at pcpu.h:195 #1 0xc0566b37 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #2 0xc0566df9 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:563 #3 0xc0777eec in trap_fatal (frame=0xe66fa90c, eva=4294550709) at /usr/src/sys/i386/i386/trap.c:899 #4 0xc0778150 in trap_pfault (frame=0xe66fa90c, usermode=0, eva=4294550709) at /usr/src/sys/i386/i386/trap.c:812 #5 0xc0778aa2 in trap (frame=0xe66fa90c) at /usr/src/sys/i386/i386/trap.c:490 #6 0xc075f47b in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #7 0xc073eec7 in vm_page_splay (pindex=Unhandled dwarf expression opcode 0x93 ) at /usr/src/sys/vm/vm_page.c:576 #8 0xc073efad in vm_page_lookup (object=0xc4513a2c, pindex=Unhandled dwarf expression opcode 0x93 ) at /usr/src/sys/vm/vm_page.c:759 #9 0xc05ca4f6 in allocbuf (bp=0xd7d20f20, size=16384) at /usr/src/sys/kern/vfs_bio.c:2884 #10 0xc05cddcd in getblk (vp=0xc44a5330, blkno=4379, size=16384, slpflag=0, slptimeo=0, flags=Variable "flags" is not available. ) at /usr/src/sys/kern/vfs_bio.c:2662 #11 0xc05d08d7 in cluster_read (vp=0xc44a5330, filesize=104590932, lblkno=4380, size=16384, cred=0x0, totread=5240, seqcount=0, bpp=0xe66fab80) at /usr/src/sys/kern/vfs_cluster.c:118 #12 0xc0717d20 in ffs_read (ap=0xe66fabc8) at /usr/src/sys/ufs/ffs/ffs_vnops.c:511 #13 0xc0782c72 in VOP_READ_APV (vop=0xc07f7140, a=0xe66fabc8) at vnode_if.c:637 #14 0xc05ee5f4 in vn_read (fp=0xc3e09c60, uio=0xe66fac60, active_cred=0xc4142500, flags=0, td=0xc41d9880) at vnode_if.h:344 #15 0xc059b5e6 in dofileread (td=0xc41d9880, fd=106, fp=0xc3e09c60, auio=0xe66fac60, offset=-1, flags=0) at file.h:242 #16 0xc059b958 in kern_readv (td=0xc41d9880, fd=106, auio=0xe66fac60) at /usr/src/sys/kern/sys_generic.c:192 #17 0xc059ba3f in read (td=0xc41d9880, uap=0xe66facfc) at /usr/src/sys/kern/sys_generic.c:108 #18 0xc0778489 in syscall (frame=0xe66fad38) at /usr/src/sys/i386/i386/trap.c:1035 #19 0xc075f4e0 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:196 #20 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) Another one: #0 doadump () at pcpu.h:195 #1 0xc0566b37 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #2 0xc0566df9 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:563 #3 0xc0777eec in trap_fatal (frame=0xe68fd90c, eva=9437986) at /usr/src/sys/i386/i386/trap.c:899 #4 0xc0778150 in trap_pfault (frame=0xe68fd90c, usermode=0, eva=9437986) at /usr/src/sys/i386/i386/trap.c:812 #5 0xc0778aa2 in trap (frame=0xe68fd90c) at /usr/src/sys/i386/i386/trap.c:490 #6 0xc075f47b in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #7 0xc073ef09 in vm_page_splay (pindex=Unhandled dwarf expression opcode 0x93 ) at /usr/src/sys/vm/vm_page.c:590 #8 0xc073efad in vm_page_lookup (object=0xc4623934, pindex=Unhandled dwarf expression opcode 0x93 ) at /usr/src/sys/vm/vm_page.c:759 #9 0xc05ca4f6 in allocbuf (bp=0xd7d0b640, size=16384) at /usr/src/sys/kern/vfs_bio.c:2884 #10 0xc05cddcd in getblk (vp=0xc4827aa0, blkno=63, size=16384, slpflag=0, slptimeo=0, flags=Variable "flags" is not available. ) at /usr/src/sys/kern/vfs_bio.c:2662 #11 0xc05d08d7 in cluster_read (vp=0xc4827aa0, filesize=3393192, lblkno=64, size=16384, cred=0x0, totread=15352, seqcount=0, bpp=0xe68fdb80) at /usr/src/sys/kern/vfs_cluster.c:118 #12 0xc0717d20 in ffs_read (ap=0xe68fdbc8) at /usr/src/sys/ufs/ffs/ffs_vnops.c:511 #13 0xc0782c72 in VOP_READ_APV (vop=0xc07f7140, a=0xe68fdbc8) at vnode_if.c:637 #14 0xc05ee5f4 in vn_read (fp=0xc45941b0, uio=0xe68fdc60, active_cred=0xc3e35000, flags=0, td=0xc4f05660) at vnode_if.h:344 #15 0xc059b5e6 in dofileread (td=0xc4f05660, fd=176, fp=0xc45941b0, auio=0xe68fdc60, offset=-1, flags=0) at file.h:242 #16 0xc059b958 in kern_readv (td=0xc4f05660, fd=176, auio=0xe68fdc60) at /usr/src/sys/kern/sys_generic.c:192 #17 0xc059ba3f in read (td=0xc4f05660, uap=0xe68fdcfc) at /usr/src/sys/kern/sys_generic.c:108 #18 0xc0778489 in syscall (frame=0xe68fdd38) at /usr/src/sys/i386/i386/trap.c:1035 #19 0xc075f4e0 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:196 #20 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) Because this is observed on two servers, it smells like a software issue, but I have not yet completely ruled hardware factor out. Anyone has some debugging hints for this? Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHfZIvi+vbBBjt66ARAqqnAJ9QgJnKER7GmxmehDUeG4oUI+9JBgCfdjrv 0RGvBHUAUUp8si/Mc9Z6qck= =DD59 -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 02:24:04 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A75AE16A468 for ; Fri, 4 Jan 2008 02:24:04 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.177]) by mx1.freebsd.org (Postfix) with ESMTP id 611AD13C467 for ; Fri, 4 Jan 2008 02:24:04 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: by py-out-1112.google.com with SMTP id u52so10835381pyb.10 for ; Thu, 03 Jan 2008 18:24:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=yM6JjChj0ISeitgb+6UqXjZKJ1FbxW+KalJl3zCz4iI=; b=wA8f4JNQDx1vpM6NBVc0DVmMZ+y6aLTfNGXQ0f9ko8be5bcihaCsPME6HcdNOWYvxoIpAcH48Dus/wJDNwWt7ytyffRtsf0vcz7fqJN+ghkC858URbBfFi/TSisG2zSXEXw8ibMr0fRxdEbefQzlMqaSzduOV8ZIr/Dp8OgnVzI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=yBuSUQWvglqCxVGUt2AXVE0RslB7yE1XAnIm0McSXy6p1sG4M5rZj3eL6HTmZJKsLnJbIMvpKYM8S2PPAJFQ0xwEmlsaNGfS9WMnLDWKHGU2F3GsnrPygWn8WJa5l6viz+UJ5NGfuArTW0SbdGOPedLy1pzdY4sITy7BrvTiJx4= Received: by 10.142.229.4 with SMTP id b4mr3717456wfh.125.1199413442890; Thu, 03 Jan 2008 18:24:02 -0800 (PST) Received: by 10.142.162.20 with HTTP; Thu, 3 Jan 2008 18:24:02 -0800 (PST) Message-ID: Date: Fri, 4 Jan 2008 10:24:02 +0800 From: "Sepherosa Ziehau" To: "=?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?=" In-Reply-To: <86odc3dlgi.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <86ir2hznnd.fsf@ds4.des.no> <86abnpu0wv.fsf@ds4.des.no> <86abnovy4k.fsf@ds4.des.no> <86odc3dlgi.fsf@ds4.des.no> Cc: kevlo@freebsd.org, sam@freebsd.org, current@freebsd.org, net@freebsd.org Subject: Re: if_ral regression X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 02:24:04 -0000 On Jan 3, 2008 10:37 PM, Dag-Erling Sm=F8rgrav wrote: > Dag-Erling Sm=F8rgrav writes: > > "Sepherosa Ziehau" writes: > > > http://people.freebsd.org/~sephe/rt2560_test.diff > > I built a new kernel with the patch applied, and it seems to help, > > though it's a bit early to say for sure. > > Didn't help. A large rsync over ssh stalls the connection within > minutes. Are you also using freebsd as STA too? If yes, would you have time to gather following information on the STA side before after and during the rsyncing: 1) wlandebug -i sta_iface +input 2) tcpdump -ni sta_iface -y ieee802_11 -w dump.bin Best Regards, sephe --=20 Live Free or Die From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 04:32:59 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B560416A41A for ; Fri, 4 Jan 2008 04:32:59 +0000 (UTC) (envelope-from weongyo.jeong@gmail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.184]) by mx1.freebsd.org (Postfix) with ESMTP id 7DE2713C4F4 for ; Fri, 4 Jan 2008 04:32:59 +0000 (UTC) (envelope-from weongyo.jeong@gmail.com) Received: by rv-out-0910.google.com with SMTP id l15so6404446rvb.43 for ; Thu, 03 Jan 2008 20:32:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:date:to:cc:subject:message-id:mail-followup-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent:organization:x-operation-sytem:from; bh=rkLLLB0lY92dNrN4BV1vyZdNHWMyPX+1+199LPU2kJc=; b=QR675HN2OyKFpA85xGXVcMAn7oca2ogbySRsEzpQFp2QzgPKkQXBOkgKCJ0t8bl5Geda+AjhEiIOILqOLz8UUaEOJKgoD23xJv0VAsyjPGQC6aNQh2Vx6aUCNdlpwDL25xwBzGwJ4Sg9hoglByKcf1NfGwX0Gii/YGaTcd6/Dbs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:to:cc:subject:message-id:mail-followup-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent:organization:x-operation-sytem:from; b=kXxqFGFDtf/8nMfIgAJgx+dQsWAUG8QY4so2CMIB2XVVou9OLymkQECE8exBrN6xUoGVrmY+AuuxREMqcQlrogDt6egpiadCwSFTOMFVeIp6pVn24mwq83dd46sJxH4nP4U/leSan4Dtb4kGOau+mT1ObRL3GVD3/Zcexr1HBdg= Received: by 10.141.2.19 with SMTP id e19mr8562328rvi.221.1199421179047; Thu, 03 Jan 2008 20:32:59 -0800 (PST) Received: from freebsd.weongyo.org ( [211.53.35.67]) by mx.google.com with ESMTPS id g6sm3276196rvb.25.2008.01.03.20.32.55 (version=SSLv3 cipher=OTHER); Thu, 03 Jan 2008 20:32:58 -0800 (PST) Received: by freebsd.weongyo.org (sSMTP sendmail emulation); Fri, 4 Jan 2008 13:32:44 +0900 Date: Fri, 4 Jan 2008 13:32:44 +0900 To: Sepherosa Ziehau Message-ID: <20080104043244.GA9641@freebsd.weongyo.org> Mail-Followup-To: Sepherosa Ziehau , Dag-Erling =?UTF8?Q?Sm=F8rgrav?= , kevlo@freebsd.org, sam@freebsd.org, current@freebsd.org, net@freebsd.org References: <86ir2hznnd.fsf@ds4.des.no> <20080102023831.GA53242@freebsd.weongyo.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Organization: CDNetworks. X-Operation-Sytem: FreeBSD From: Weongyo Jeong Cc: Dag-Erling =?UTF8?Q?Sm=F8rgrav?= , sam@freebsd.org, net@freebsd.org, current@freebsd.org, kevlo@freebsd.org Subject: Re: if_ral regression X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 04:32:59 -0000 On Wed, Jan 02, 2008 at 09:28:30PM +0800, Sepherosa Ziehau wrote: > On Jan 2, 2008 10:38 AM, Weongyo Jeong wrote: > > > > > Even with these in place in dfly, I still have strange TX performance > > > regression in sta mode (drop from 20Mb/s to 3Mb/s under very well > > > condition) on certain hardwares after 20sec~30sec TCP_STREAM netperf > > > testing; didn't have enough time to dig, however, all of the tested > > > hardwares stayed connected during testing (I usually run netperf > > > stream test for 12 hours or more). > > > > I also saw some regression in TX performance during porting malo(4). > > Have you tried to turn bgscan off completely? My problem seems to be > hardware (I suspect rf) related. The TX performance regression does > not happen with UDP stream which only uses 802.11 ack, i.e. hardware > seems to have touble to switch between data RX and data TX at high > freq. Oops. It seems this problem is a different one because I always encounter system crashes (I can't enter DDB, no keyboard works and no messages on screen) within a hour with HEAD when I tested netperf(1) TX tests using malo(4) that the tested driver was never crashed before during testing netperf(1) tests for several hours. Before 1~2 months ago, it wasn't happen. It looks weird and I'm also going to dig it. > > Problems were fixed after removing following lines in *_start: > > > > /* > > * Cancel any background scan. > > */ > > if (ic->ic_flags & IEEE80211_F_SCAN) > > ieee80211_cancel_scan(ic); > > > > and (optionally) > > > > if (m->m_flags & M_TXCB) > > ... > > ieee80211_process_callback(ni, m, 0); /* XXX status? > > ... > > I don't think you can remove TXCB processing in drivers :) Yes, indeed. :-) regards, Weongyo Jeong From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 05:51:34 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 196CC16A419; Fri, 4 Jan 2008 05:51:34 +0000 (UTC) (envelope-from fjoe@samodelkin.net) Received: from neo.samodelkin.net (samodelkin.net [195.62.0.66]) by mx1.freebsd.org (Postfix) with ESMTP id AA15013C465; Fri, 4 Jan 2008 05:51:33 +0000 (UTC) (envelope-from fjoe@samodelkin.net) Received: by neo.samodelkin.net (Postfix, from userid 10117) id 4CD7817305; Fri, 4 Jan 2008 11:51:31 +0600 (NOVT) Received: from husky.fjoe.local (gw.nsib.ru [217.117.80.2]) by neo.samodelkin.net (Postfix) with ESMTP id E42E8172F1; Fri, 4 Jan 2008 11:51:30 +0600 (NOVT) Message-ID: <477DC95D.9010701@samodelkin.net> Date: Fri, 04 Jan 2008 11:51:25 +0600 From: Max Khon User-Agent: Thunderbird 2.0.0.6 (X11/20071028) MIME-Version: 1.0 To: =?UTF-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= References: <86ir2hznnd.fsf@ds4.des.no> <86abnpu0wv.fsf@ds4.des.no> <86abnovy4k.fsf@ds4.des.no> <86odc3dlgi.fsf@ds4.des.no> In-Reply-To: <86odc3dlgi.fsf@ds4.des.no> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Bogosity: No, tests=bogofilter, spamicity=0.000000, version=0.16.4 Cc: Sepherosa Ziehau , kevlo@freebsd.org, sam@freebsd.org, current@freebsd.org, net@freebsd.org Subject: Re: if_ral regression X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 05:51:34 -0000 Hi! Dag-Erling SmÞrgrav wrote: >>> http://people.freebsd.org/~sephe/rt2560_test.diff >> I built a new kernel with the patch applied, and it seems to help, >> though it's a bit early to say for sure. > > Didn't help. A large rsync over ssh stalls the connection within > minutes. Have you tried to turn off bgscan? /fjoe From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 06:28:11 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 654DE16A417 for ; Fri, 4 Jan 2008 06:28:10 +0000 (UTC) (envelope-from ianf@clue.co.za) Received: from munchkin.clue.co.za (munchkin.clue.co.za [66.219.59.160]) by mx1.freebsd.org (Postfix) with ESMTP id D964D13C459 for ; Fri, 4 Jan 2008 06:28:09 +0000 (UTC) (envelope-from ianf@clue.co.za) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=20070313; d=clue.co.za; h=Received:Received:Received:To:cc:From:Subject:In-Reply-To:X-Attribution:Date:Message-Id; b=oJjEmL4BNqVo/QVHBXu+lRqdypc1AeXS89+WyshXLjrJ2vfMusF4LJnvHq5/JibPJf/ouNRnXcewtYK/v5tlrKrD65DovRt4Pxrtvwq2YsmhL52m/EiHvvIuT9LJhtqxl6tOTzuj2X3BLILHxZPh470U1bSyhNfPttZM+0+BBI4VX3AdTnDZ0CFMfyCytVOUiRbX70QA1NYPoCo/6id8O29ESqUamdoJZxJ4toLTC2MfIarQb+zlv4i9h08d0dz/; Received: from uucp by munchkin.clue.co.za with local-rmail (Exim 4.67) (envelope-from ) id 1JAg2K-0008HS-L0; Fri, 04 Jan 2008 06:28:08 +0000 Received: from ianf.clue.co.za ([10.0.0.6] helo=clue.co.za) by urchin.clue.co.za with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1JAg1t-0006bU-RL; Fri, 04 Jan 2008 06:27:41 +0000 Received: from localhost ([127.0.0.1] helo=clue.co.za) by clue.co.za with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JAg1t-0000Yt-0f; Fri, 04 Jan 2008 08:27:41 +0200 To: Robert Watson From: Ian FREISLICH In-Reply-To: Message from Robert Watson of "Fri, 04 Jan 2008 00:26:31 GMT." <20080104002002.L30578@fledge.watson.org> X-Attribution: BOFH Date: Fri, 04 Jan 2008 08:27:41 +0200 Message-Id: Cc: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= , freebsd-current@freebsd.org, Jason Evans , Poul-Henning Kamp Subject: Re: sbrk(2) broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 06:28:11 -0000 Robert Watson wrote: > to break (tm), killing of other large processes, etc. To be clear, > in the new world order, instead of getting NULL back from malloc(3), > SIGKILL is delivered to large processes. I'm not sure that I like that very much. At least the way that it has been explained here so correct me if I misunderstood. I have long lived processes that continuously handle very valuable data and potentially get very large (several GB). I'd like that process to be able to make a rational decision about what happens to its memory contents when an allocation fails rather than having the proverbial rug pulled out from under it. Rug pulling at any point can cost an annual salary or two. Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 07:32:20 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 06CE616A418 for ; Fri, 4 Jan 2008 07:32:20 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail10.syd.optusnet.com.au (mail10.syd.optusnet.com.au [211.29.132.191]) by mx1.freebsd.org (Postfix) with ESMTP id 90DE813C469 for ; Fri, 4 Jan 2008 07:32:19 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from server.vk2pj.dyndns.org (c220-239-20-82.belrs4.nsw.optusnet.com.au [220.239.20.82]) by mail10.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m047W7QA018485 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Jan 2008 18:32:08 +1100 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.2/8.14.1) with ESMTP id m047W6mK055405; Fri, 4 Jan 2008 18:32:06 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.2/8.14.2/Submit) id m047W6vP055404; Fri, 4 Jan 2008 18:32:06 +1100 (EST) (envelope-from peter) Date: Fri, 4 Jan 2008 18:32:06 +1100 From: Peter Jeremy To: Jeff Roberson Message-ID: <20080104073206.GY947@server.vk2pj.dyndns.org> References: <20071223092332.GJ25002@server.vk2pj.dyndns.org> <476F81AF.7000505@gmail.com> <20080101190607.B957@desktop> <20080102105049.GA903@server.vk2pj.dyndns.org> <20080102033011.P957@desktop> <20080103192104.GS947@server.vk2pj.dyndns.org> <20080103133510.D957@desktop> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TybLhxa8M7aNoW+V" Content-Disposition: inline In-Reply-To: <20080103133510.D957@desktop> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-current@freebsd.org Subject: Re: idle priority scheduling broken in 7.0-BETA4 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 07:32:20 -0000 --TybLhxa8M7aNoW+V Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 03, 2008 at 01:37:06PM -1000, Jeff Roberson wrote: >On Fri, 4 Jan 2008, Peter Jeremy wrote: >> That seems to work and I don't see any problems with it. There were >> seven watchdog restarts over about 3/4 hr whilst the system was doing >> a buildworld but this is probably not completely unreasonable. > >This is a boinc watchdog? The client just didn't get to run for too long= =20 >during the buildworld? Yes. Sorry for leaving out the necessary context. It looks like there are a couple of cases where buildworld manages to get CPU bound for a significant period. I don't see this as a problem. >If there are any further complaints I will. Is there any chance you could= =20 >also try it with nice +20 or nice +10 and report how the system behaves? I tried 'nice +20' before I tried idprio and it also behaved correctly. I haven't tried any other values. The real idle kthread has managed to clock up another minute of CPU time in the past 10 or so hours. Again, this seems reasonable. Thanks for the patch. --=20 Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. --TybLhxa8M7aNoW+V Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHfeD2/opHv/APuIcRAjR/AKCoBkSJjHivI1EzqpkyQ79HFjFrrgCguD1J 05UKyyWywcRYPwUdf/9RMyw= =mmkE -----END PGP SIGNATURE----- --TybLhxa8M7aNoW+V-- From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 08:51:26 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5657F16A417; Fri, 4 Jan 2008 08:51:26 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 0DE0213C44B; Fri, 4 Jan 2008 08:51:26 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id AF30F20BB; Fri, 4 Jan 2008 09:51:18 +0100 (CET) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: -0.1/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 9B2A32099; Fri, 4 Jan 2008 09:51:18 +0100 (CET) Received: by ds4.des.no (Postfix, from userid 1001) id 80866844CD; Fri, 4 Jan 2008 09:51:18 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: "Sepherosa Ziehau" References: <86ir2hznnd.fsf@ds4.des.no> <86abnpu0wv.fsf@ds4.des.no> <86abnovy4k.fsf@ds4.des.no> <86odc3dlgi.fsf@ds4.des.no> Date: Fri, 04 Jan 2008 09:51:18 +0100 In-Reply-To: (Sepherosa Ziehau's message of "Fri\, 4 Jan 2008 10\:24\:02 +0800") Message-ID: <86lk76c6t5.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: kevlo@freebsd.org, sam@freebsd.org, current@freebsd.org, net@freebsd.org Subject: Re: if_ral regression X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 08:51:26 -0000 "Sepherosa Ziehau" writes: > Are you also using freebsd as STA too? If yes, would you have time to > gather following information on the STA side before after and during > the rsyncing: > 1) wlandebug -i sta_iface +input > 2) tcpdump -ni sta_iface -y ieee802_11 -w dump.bin I'll have to pull out an old laptop to do that, my current one runs Ubuntu. Hopefully, I'll have the results for you later today. I imagine you want to see the output from wlandebug both when the AP is working and when it is stuck? DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 08:52:37 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 981C016A41B; Fri, 4 Jan 2008 08:52:37 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 4EA2013C467; Fri, 4 Jan 2008 08:52:37 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 3228320BB; Fri, 4 Jan 2008 09:52:29 +0100 (CET) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: -0.2/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 1F3482099; Fri, 4 Jan 2008 09:52:28 +0100 (CET) Received: by ds4.des.no (Postfix, from userid 1001) id CC56D844CD; Fri, 4 Jan 2008 09:52:28 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Max Khon References: <86ir2hznnd.fsf@ds4.des.no> <86abnpu0wv.fsf@ds4.des.no> <86abnovy4k.fsf@ds4.des.no> <86odc3dlgi.fsf@ds4.des.no> <477DC95D.9010701@samodelkin.net> Date: Fri, 04 Jan 2008 09:52:28 +0100 In-Reply-To: <477DC95D.9010701@samodelkin.net> (Max Khon's message of "Fri\, 04 Jan 2008 11\:51\:25 +0600") Message-ID: <86hchuc6r7.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Sepherosa Ziehau , kevlo@freebsd.org, sam@freebsd.org, current@freebsd.org, net@freebsd.org Subject: Re: if_ral regression X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 08:52:37 -0000 Max Khon writes: > Have you tried to turn off bgscan? bgscan is obviously not running since the broken ral is in the AP. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 09:07:31 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0B00A16A41A; Fri, 4 Jan 2008 09:07:31 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id BA38813C44B; Fri, 4 Jan 2008 09:07:30 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 6883C2089; Fri, 4 Jan 2008 10:07:22 +0100 (CET) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: -0.2/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 593B72049; Fri, 4 Jan 2008 10:07:22 +0100 (CET) Received: by ds4.des.no (Postfix, from userid 1001) id 3EC6E844CD; Fri, 4 Jan 2008 10:07:22 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Jason Fesler References: <477C82F0.5060809@freebsd.org> <863ateemw2.fsf@ds4.des.no> <200801032200.25650.peter.schuller@infidyne.com> Date: Fri, 04 Jan 2008 10:07:22 +0100 In-Reply-To: (Jason Fesler's message of "Thu\, 3 Jan 2008 13\:08\:18 -0800 \(PST\)") Message-ID: <8663yac62d.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, Peter Schuller , Jason Evans Subject: Re: sbrk(2) broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 09:07:31 -0000 Jason Fesler writes: >> Also, may I humbly inject a user centric view here - it is pretty annoyi= ng to >> be limited to 500 MB of mallocable memory on 32 bit machines when you ex= pect >> 3 GB to be usable (with 1 GB mapped to the kernel). > > amen. :-( Has anyone tried upgrading a system from i386 to amd_64 > with any success? "Sidegrading" is supposed to work now in HEAD; with a little hacking, you can build an amd64 world and kernel on the i386 world, install the kernel, reboot, and install world. AFAIK, the required hacking involves copying /libexec/ld-elf.so.1 to /libexec/ld-elf32.so.1 before rebooting so the new kernel will be able to run the old binaries. It should also be possible to install an amd64 world *before* rebooting, in which case you don't need the aforementioned hackery (installworld will do it for you) but you may have trouble doing anything at all after installworld since your new world will not run on the old kernel. The install process itself doesn't care, since it copies all the i386 binaries and libraries it needs before installing anything. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 09:33:02 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 17D0A16A418; Fri, 4 Jan 2008 09:33:02 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id C619713C45B; Fri, 4 Jan 2008 09:33:01 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 971C020BC; Fri, 4 Jan 2008 10:32:53 +0100 (CET) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: -0.2/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 891F020A0; Fri, 4 Jan 2008 10:32:53 +0100 (CET) Received: by ds4.des.no (Postfix, from userid 1001) id 4B36B844CD; Fri, 4 Jan 2008 10:32:53 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Robert Watson References: <477C82F0.5060809@freebsd.org> <863ateemw2.fsf@ds4.des.no> <20080104002002.L30578@fledge.watson.org> Date: Fri, 04 Jan 2008 10:32:53 +0100 In-Reply-To: <20080104002002.L30578@fledge.watson.org> (Robert Watson's message of "Fri\, 4 Jan 2008 00\:26\:31 +0000 \(GMT\)") Message-ID: <86wsqqaqbe.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, Jason Evans , Poul-Henning Kamp Subject: Re: sbrk(2) broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 09:33:02 -0000 Robert Watson writes: > The right answer is presumably to introduce a new LIMIT_SWAP, which > limits the allocation of anonymous memory by processes, and size it to > something like 90% of swap space by default. Not a good solution on its own. You need a per-process limit as well, otherwise a malloc() bomb will still cause other processes to fail randomly. > Since that won't be happening before 7.0, I believe the consensus is > to simply not MFC the changes for 7 and proceed with the release. Thank you :) DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 09:51:43 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A382016A417 for ; Fri, 4 Jan 2008 09:51:43 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail03.syd.optusnet.com.au (mail03.syd.optusnet.com.au [211.29.132.184]) by mx1.freebsd.org (Postfix) with ESMTP id 3B32013C4E3 for ; Fri, 4 Jan 2008 09:51:43 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from server.vk2pj.dyndns.org (c220-239-20-82.belrs4.nsw.optusnet.com.au [220.239.20.82]) by mail03.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m049pX9b011833 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Jan 2008 20:51:34 +1100 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.2/8.14.1) with ESMTP id m049pXDl056087; Fri, 4 Jan 2008 20:51:33 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.2/8.14.2/Submit) id m049pWWq056086; Fri, 4 Jan 2008 20:51:32 +1100 (EST) (envelope-from peter) Date: Fri, 4 Jan 2008 20:51:32 +1100 From: Peter Jeremy To: Ian FREISLICH Message-ID: <20080104095132.GC947@server.vk2pj.dyndns.org> References: <20080104002002.L30578@fledge.watson.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GV0iVqYguTV4Q9ER" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-current@freebsd.org Subject: Re: sbrk(2) broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 09:51:43 -0000 --GV0iVqYguTV4Q9ER Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 04, 2008 at 08:27:41AM +0200, Ian FREISLICH wrote: >I have long lived processes that continuously handle very valuable >data and potentially get very large (several GB). I'd like that >process to be able to make a rational decision about what happens to its >memory contents when an allocation fails rather than having the >proverbial rug pulled out from under it. Rug pulling at any point=20 >can cost an annual salary or two. If you google for freebsd+sigdanger, you will find that this topic was first discussed nearly 10 years ago. Unfortunately, no progress appears to have been made, though it crops up every few years. --=20 Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. --GV0iVqYguTV4Q9ER Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHfgGk/opHv/APuIcRAq5uAKCRVg6oSCk3pAtapDSsyL437xaQnwCfZrH3 wtY4Xm0mGdNFTsBVK/OzQsY= =hte+ -----END PGP SIGNATURE----- --GV0iVqYguTV4Q9ER-- From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 10:19:31 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A297916A419; Fri, 4 Jan 2008 10:19:31 +0000 (UTC) (envelope-from avatar@mmlab.cse.yzu.edu.tw) Received: from www.mmlab.cse.yzu.edu.tw (www.mmlab.cse.yzu.edu.tw [140.138.150.166]) by mx1.freebsd.org (Postfix) with ESMTP id 157B713C43E; Fri, 4 Jan 2008 10:19:30 +0000 (UTC) (envelope-from avatar@mmlab.cse.yzu.edu.tw) Received: by www.mmlab.cse.yzu.edu.tw (qmail, from userid 1000) id 362FA8CA013; Fri, 4 Jan 2008 18:19:29 +0800 (CST) Received: from localhost (localhost [127.0.0.1]) by www.mmlab.cse.yzu.edu.tw (qmail) with ESMTP id 3323C8C9F35; Fri, 4 Jan 2008 18:19:29 +0800 (CST) Date: Fri, 4 Jan 2008 18:19:28 +0800 (CST) From: Tai-hwa Liang To: John Baldwin In-Reply-To: <200801031652.20807.jhb@freebsd.org> Message-ID: <0801041816427.55589@www.mmlab.cse.yzu.edu.tw> References: <474D81DB.7020004@FreeBSD.org> <071130112653E.701@www.mmlab.cse.yzu.edu.tw> <200801031652.20807.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Remko Lodder , freebsd-current@freebsd.org, kib@freebsd.org Subject: Re: [Fwd: Re: kern/118258 sysctl causing panics on 7.0-xxx] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 10:19:31 -0000 On Thu, 3 Jan 2008, John Baldwin wrote: > On Thursday 29 November 2007 10:53:32 pm Tai-hwa Liang wrote: >> On Wed, 28 Nov 2007, Remko Lodder wrote: >>> Hello, >>> >>> So as per Jeff's information, can someone from the -current >>> list either contact jeff or try to resolve the problems >>> mentioned? :) >> >> This is a longstanding bug which also exists in RELENG_6. It turns out >> that 'sysctl kern.ttys' after a terminal device is removed could trigger >> this panic reliably. For example, do 'sysctl kern.ttys' multiple times >> after detaching an USB serial-to-rs232 cable or a PCMCIA modem card. >> >> Alternatively, following script would demo the panic if you don't have >> a physically removable terminal device: >> >> #!/bin/sh >> # >> # Warning! Running this script as root will panic your CURRENT box... >> # >> while true; do >> kldload dcons >> kldunload dcons >> ls /dev >> sysctl kern.ttys >> sleep 1 >> done >> >> This seems to be a race between devfs and destroy_dev(), Cc'ing kib@ >> since he probably has more clues in this area. > > Try this patch. Also available at > http://www.FreeBSD.org/~jhb/patches/ttys_sysctl.patch With this patch, -CURRENT no longer boots and panics as follows: Unread portion of the kernel message buffer: <118>Configuring syscons: <118> keyrate Sleeping thread (tid 100048, pid 307) owns a non-sleepable lock sched_switch(c3b97a50,0,1,394c04af,12,...) at sched_switch+0x146 mi_switch(1,0,c3b97a50,f888caa8,c051788a,...) at mi_switch+0x137 sleepq_switch(c3b97a50,0,c06945ef,19b,c065bdc0,...) at sleepq_switch+0x7e sleepq_catch_signals(0,c3b97a50,f888cae8,c04b38d0,c3c999a8,...) at sleepq_catch_signals+0x24a sleepq_wait_sig(c3c999a8,c3c99990,c0694a50,101,0,...) at sleepq_wait_sig+0x15 _cv_wait_sig(c3c999a8,c3c99990,c103c800,0,f888cb74,...) at _cv_wait_sig+0x180 seltdwait(c3f551d4,1,c3a9f200,c3b97a50,c3f59e58,...) at seltdwait+0xd6 poll(c3b97a50,f888ccfc,c,12,88cd2c,...) at poll+0x489 syscall(f888cd38) at syscall+0x317 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (209, FreeBSD ELF32, poll), eip = 0x28112baf, esp = 0xbfbfee1c, ebp = 0xbfbfee48 --- panic: sleeping thread KDB: enter: panic panic: from debugger Uptime: 8s Physical memory: 1014 MB Dumping 55 MB: 40 24 8 #0 doadump () at pcpu.h:195 195 pcpu.h: No such file or directory. in pcpu.h (kgdb) where #0 doadump () at pcpu.h:195 #1 0xc04ea575 in boot (howto=260) at ../../../kern/kern_shutdown.c:417 #2 0xc04ea797 in panic (fmt=Variable "fmt" is not available. ) at ../../../kern/kern_shutdown.c:571 #3 0xc0446da7 in db_panic (addr=Could not find the frame base for "db_panic". ) at ../../../ddb/db_command.c:444 #4 0xc044751c in db_command (last_cmdp=0xc06dd754, cmd_table=0x0, dopager=1) at ../../../ddb/db_command.c:411 #5 0xc044762a in db_command_loop () at ../../../ddb/db_command.c:464 #6 0xc044908d in db_trap (type=3, code=0) at ../../../ddb/db_main.c:228 #7 0xc0510034 in kdb_trap (type=3, code=0, tf=0xf88df8dc) at ../../../kern/subr_kdb.c:510 #8 0xc0667bc7 in trap (frame=0xf88df8dc) at ../../../i386/i386/trap.c:647 #9 0xc065584b in calltrap () at ../../../i386/i386/exception.s:146 #10 0xc051019a in kdb_enter (why=0xc0692272 "panic", msg=0xc0692272 "panic") at cpufunc.h:60 #11 0xc04ea77d in panic (fmt=0xc06949df "sleeping thread") at ../../../kern/kern_shutdown.c:555 #12 0xc051a34d in propagate_priority (td=0xc3b97a50) at ../../../kern/subr_turnstile.c:222 #13 0xc051ad59 in turnstile_wait (ts=0xc3a9b870, owner=0xc3b97a50, queue=Variable "queue" is not available.) at ../../../kern/subr_turnstile.c:739 #14 0xc04dcedd in _mtx_lock_sleep (m=0xc06f7640, tid=3290042896, opts=0, file=0x0, line=0) at ../../../kern/kern_mutex.c:404 #15 0xc0529ead in ttyrel (tp=0xc3c88c00) at ../../../kern/tty.c:2855 #16 0xc052c08a in tty_close (tp=0xc3c88c00) at ../../../kern/tty.c:346 #17 0xc048d9ff in scclose (dev=0xc3c87100, flag=1, mode=8192, td=0xc41a1210) at ../../../dev/syscons/syscons.c:585 #18 0xc04b55d3 in giant_close (dev=0xc3c87100, fflag=1, devtype=8192, td=0xc41a1210) at ../../../kern/kern_conf.c:327 #19 0xc0493353 in devfs_close (ap=0xf88dfaac) at ../../../fs/devfs/devfs_vnops.c:372 #20 0xc06717f2 in VOP_CLOSE_APV (vop=0xc06b8160, a=0xf88dfaac) at vnode_if.c:424 #21 0xc0574cf7 in vn_close (vp=0xc423e000, flags=1, file_cred=0xc3a9f200, td=0xc41a1210) at vnode_if.h:228 #22 0xc0574e34 in vn_closefile (fp=0xc3f563dc, td=0xc41a1210) at ../../../kern/vfs_vnops.c:872 #23 0xc0491ae9 in devfs_close_f (fp=0xc3f563dc, td=0xc41a1210) at ../../../fs/devfs/devfs_vnops.c:384 #24 0xc04b8f73 in _fdrop (fp=0xc3f563dc, td=0xc41a1210) at file.h:268 #25 0xc04ba458 in closef (fp=0xc3f563dc, td=0xc41a1210) at ../../../kern/kern_descrip.c:1945 #26 0xc04bb4f5 in fdfree (td=0xc41a1210) at ../../../kern/kern_descrip.c:1655 #27 0xc04c7235 in exit1 (td=0xc41a1210, rv=0) at ../../../kern/kern_exit.c:271 #28 0xc04c85bd in sys_exit (td=Could not find the frame base for "sys_exit". ) at ../../../kern/kern_exit.c:98 #29 0xc0667407 in syscall (frame=0xf88dfd38) at ../../../i386/i386/trap.c:1034 #30 0xc06558b0 in Xint0x80_syscall () at ../../../i386/i386/exception.s:203 #31 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) -- Thanks, Tai-hwa Liang From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 10:41:19 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B427616A417 for ; Fri, 4 Jan 2008 10:41:19 +0000 (UTC) (envelope-from mozolevsky@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.172]) by mx1.freebsd.org (Postfix) with ESMTP id 40D5E13C447 for ; Fri, 4 Jan 2008 10:41:19 +0000 (UTC) (envelope-from mozolevsky@gmail.com) Received: by ug-out-1314.google.com with SMTP id y2so3597596uge.37 for ; Fri, 04 Jan 2008 02:41:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=8hXwQzdmPTtog+Iq9FUiTtfQMeVOEDL7TNywED90oUA=; b=BSZ5tHN4e2YSwJTV/dTM/hgM5+sT0Fkcd464dPP4l40s0BphqbevQXCsAR/XhI9DtlSHaffEGCv7WAGa97PhzPUi25NOpzKBlJ0qdjnIeyZqEUnpOp0pN4XaSK/xM6BTBzbGM8DFQY7/AfDswpEGxpDmCEhm4438FvOnXp6Mep4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=hWKwGeKh+kh+1er+avgAAvjSbgtg8N1MOdeG3VWtkw4fSM35mygQoPoQpgW79CKlMXbvSbLXhVfpZ9i0gfpgh2MTASgPBM7RJNOd3u+Lgxv6HqoTh8OEXH9JIf7vSqAw+GPBO/BMtL6xokiUhpuV2HUceRz/ng6LNxdckfeC+MU= Received: by 10.67.26.7 with SMTP id d7mr678986ugj.23.1199443277960; Fri, 04 Jan 2008 02:41:17 -0800 (PST) Received: by 10.66.248.11 with HTTP; Fri, 4 Jan 2008 02:41:17 -0800 (PST) Message-ID: Date: Fri, 4 Jan 2008 10:41:17 +0000 From: "Igor Mozolevsky" Sender: mozolevsky@gmail.com To: "Robert Watson" In-Reply-To: <20080104002002.L30578@fledge.watson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <477C82F0.5060809@freebsd.org> <863ateemw2.fsf@ds4.des.no> <20080104002002.L30578@fledge.watson.org> X-Google-Sender-Auth: a9654ee0cf5c6aa8 Cc: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= , freebsd-current@freebsd.org, Jason Evans Subject: Re: sbrk(2) broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 10:41:19 -0000 On 04/01/2008, Robert Watson wrote: > To be clear, in the new world order, instead of getting NULL > back from malloc(3), SIGKILL is delivered to large processes. Huh??? Again, huh??? From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 10:55:32 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1B5D116A417; Fri, 4 Jan 2008 10:55:32 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id C6CEC13C447; Fri, 4 Jan 2008 10:55:31 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 8831020C5; Fri, 4 Jan 2008 11:55:23 +0100 (CET) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: -0.2/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id F11D720C1; Fri, 4 Jan 2008 11:55:22 +0100 (CET) Received: by ds4.des.no (Postfix, from userid 1001) id C030F8449F; Fri, 4 Jan 2008 11:55:22 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: "Igor Mozolevsky" References: <477C82F0.5060809@freebsd.org> <863ateemw2.fsf@ds4.des.no> <20080104002002.L30578@fledge.watson.org> Date: Fri, 04 Jan 2008 11:55:22 +0100 In-Reply-To: (Igor Mozolevsky's message of "Fri\, 4 Jan 2008 10\:41\:17 +0000") Message-ID: <86bq81c12d.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, Robert Watson , Jason Evans Subject: Re: sbrk(2) broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 10:55:32 -0000 "Igor Mozolevsky" writes: > Robert Watson writes: > > To be clear, in the new world order, instead of getting NULL > > back from malloc(3), SIGKILL is delivered to large processes. > Huh??? Again, huh??? For the same reason as it has for the last 20 years or so: memory overcommit, which means that malloc() allocates address space, not memory. Actual memory is allocated on-demand when the address space is used (read from or written to). If there is no RAM left and none can be freed by swapping out, the process gets killed. The process that gets killed is not necessarily the memory hog, it is merely the process that is unlucky enough to touch a new page at the wrong moment, i.e. when all RAM and swap is exhausted *or* everything in RAM is wired down and unswappable. Of course, if you're afraid of memory overcommit and you know in advance how much memory you need, you can simply allocate a sufficient amount of address space at startup and touch it all. This way, you will either be killed right away, or be guaranteed to have sufficient memory for the rest of your (process) lifetime. Alternatively, do what Varnish does: create a large file, mmap it, and allocate everything you need from that area, so you have your own private swap space. Just make sure to actually allocate the disk space you need (by filling the file with zeroes, or at the minimum writing a zero to the file every sb.st_blksize bytes, preferably sequentially to avoid excessive fragmentation) or you may run into the same problem as with malloc() if the disk fills up while your backing file is still sparse. The ability to specify a backing file to use instead of anonymous mappings would be a cool addition to jemalloc. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 11:06:04 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 50AFB16A419; Fri, 4 Jan 2008 11:06:04 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 1665C13C459; Fri, 4 Jan 2008 11:06:04 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 5631B4F8F8; Fri, 4 Jan 2008 06:06:03 -0500 (EST) Date: Fri, 4 Jan 2008 11:06:03 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= In-Reply-To: <86wsqqaqbe.fsf@ds4.des.no> Message-ID: <20080104110511.S77222@fledge.watson.org> References: <477C82F0.5060809@freebsd.org> <863ateemw2.fsf@ds4.des.no> <20080104002002.L30578@fledge.watson.org> <86wsqqaqbe.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="621616949-938840691-1199444763=:77222" Cc: freebsd-current@freebsd.org, Jason Evans , Poul-Henning Kamp Subject: Re: sbrk(2) broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 11:06:04 -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. --621616949-938840691-1199444763=:77222 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Fri, 4 Jan 2008, Dag-Erling Sm=F8rgrav wrote: > Robert Watson writes: >> The right answer is presumably to introduce a new LIMIT_SWAP, which >> limits the allocation of anonymous memory by processes, and size it to >> something like 90% of swap space by default. > > Not a good solution on its own. You need a per-process limit as well,=20 > otherwise a malloc() bomb will still cause other processes to fail random= ly. That was what I had in mind, the above should read RLIMIT_SWAP. Robert N M Watson Computer Laboratory University of Cambridge --621616949-938840691-1199444763=:77222-- From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 11:18:07 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 245B416A469 for ; Fri, 4 Jan 2008 11:18:07 +0000 (UTC) (envelope-from mozolevsky@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.175]) by mx1.freebsd.org (Postfix) with ESMTP id 8F5D913C448 for ; Fri, 4 Jan 2008 11:18:06 +0000 (UTC) (envelope-from mozolevsky@gmail.com) Received: by ug-out-1314.google.com with SMTP id y2so3601808uge.37 for ; Fri, 04 Jan 2008 03:18:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=hZfaHCNwrnh7haN2GtWepr9fSx+5siwIR0QBCmYuHTE=; b=qijGKmlMMuy6qHCR0raPj80VtDcVLSvggq/5JCWQH66RGmKTBrusqNn7Zu63RHUzO9l8D85VZP4Zm+oJjHIBSe8f5Meh3pML1np2EFSNdu3Vq90L1Z6xvZGM0Fs40bjKIB0BTqStWNlO7mciiZo+ZT+wbRETJoWRoxBrwxsqLKM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=qGgqa8y3/6AySyXYAYV+9myTenJk84Vs8oX4RDr7muQwE4UqIIpLPuqSVb4biUgPM52jEqaQh0XmRtDnnVsFuaqM6SguuQ8NaW3iycUr8CHmizUhD+Mphyjgqg0TsPoZ841XM5k28HvigPkI2INJii9eFJXwTzjdkRyhGIpeagw= Received: by 10.66.219.11 with SMTP id r11mr16713450ugg.31.1199445485104; Fri, 04 Jan 2008 03:18:05 -0800 (PST) Received: by 10.66.248.11 with HTTP; Fri, 4 Jan 2008 03:18:05 -0800 (PST) Message-ID: Date: Fri, 4 Jan 2008 11:18:05 +0000 From: "Igor Mozolevsky" Sender: mozolevsky@gmail.com To: "=?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?=" In-Reply-To: <86bq81c12d.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <477C82F0.5060809@freebsd.org> <863ateemw2.fsf@ds4.des.no> <20080104002002.L30578@fledge.watson.org> <86bq81c12d.fsf@ds4.des.no> X-Google-Sender-Auth: 0adb89dd6b28915f Cc: freebsd-current@freebsd.org, Robert Watson , Jason Evans Subject: Re: sbrk(2) broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 11:18:07 -0000 On 04/01/2008, Dag-Erling Sm=F8rgrav wrote: > For the same reason as it has for the last 20 years or so: memory > overcommit, which means that malloc() allocates address space, not > memory. Actual memory is allocated on-demand when the address space is > used (read from or written to). If there is no RAM left and none can be > freed by swapping out, the process gets killed. The process that gets > killed is not necessarily the memory hog, it is merely the process that > is unlucky enough to touch a new page at the wrong moment, i.e. when all > RAM and swap is exhausted *or* everything in RAM is wired down and > unswappable. Broadcasting SIGDANGER would be a much better option; followed by SIGTERM to the memory hogger (to allow for graceful termination) and only then SIGKILL. I can imagine a few (legitimate) scenarios when a user process would want to hog as much RAM as possible... > Of course, if you're afraid of memory overcommit and you know in advance > how much memory you need, you can simply allocate a sufficient amount of > address space at startup and touch it all. This way, you will either be > killed right away, or be guaranteed to have sufficient memory for the > rest of your (process) lifetime. Alternatively, do what Varnish does: > create a large file, mmap it, and allocate everything you need from that > area, so you have your own private swap space. Just make sure to > actually allocate the disk space you need (by filling the file with > zeroes, or at the minimum writing a zero to the file every sb.st_blksize > bytes, preferably sequentially to avoid excessive fragmentation) Surely you can just fseek() on the file at the correct lenght? > The ability to specify a backing file to use instead of anonymous > mappings would be a cool addition to jemalloc. That would be really cool and even better if it allocated it in a contiguous chunk. Igor :-) From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 11:19:28 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 760CF16A417; Fri, 4 Jan 2008 11:19:28 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 4527813C46B; Fri, 4 Jan 2008 11:19:28 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id B6BF84D7EC; Fri, 4 Jan 2008 06:19:27 -0500 (EST) Date: Fri, 4 Jan 2008 11:19:27 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Igor Mozolevsky In-Reply-To: Message-ID: <20080104111336.X77222@fledge.watson.org> References: <477C82F0.5060809@freebsd.org> <863ateemw2.fsf@ds4.des.no> <20080104002002.L30578@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= , freebsd-current@freebsd.org, Jason Evans Subject: Re: sbrk(2) broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 11:19:28 -0000 On Fri, 4 Jan 2008, Igor Mozolevsky wrote: > On 04/01/2008, Robert Watson wrote: > >> To be clear, in the new world order, instead of getting NULL back from >> malloc(3), SIGKILL is delivered to large processes. > > Huh??? Again, huh??? FreeBSD allows memory overcommit, both overcommit of physical memory resulting in paging, and overcommit of swap space. For the last few years, resource limits on the data segment size, previously observed by malloc(), have prevented processes from mallocing enough memory individually to exhaust swap on 32-bit systems. This is arguably a bug, because you actually want a single process to be able to allocate enough memory to fill its address space, but because the data segment size is used to make address space layout decisions from the inception of the process, is rather inate to using sbrk(). Jason's new malloc uses mmap() of anonymous memory, which isn't affected by the data segment limit, and hence, as a feature, isn't limited by the resouce limit. This turns out to be awkward if you have a run-away process, as where previously it would simply get back an error when it tried to exceed its resource limit, now it simply consumes all your swap, which then results in overcommit. My hope was that we could re-introduce a resource limit on malloc'd memory without large changes, but that appears to have been more tricky than hoped. The goal is not to prevent overcommit, which is invaluable in UNIX systems due to the fork() model which pretty much pre-supposes it by design, rather, to prevent exhaustion of swap by a single process if not specifically allowed by the administrator (in the same way we limit all sorts of other things, like open files, mbufs, socket buffer memory, etc). The right way to do it is to provide a specifically configurable process limit on swap use, the same way we did for data segment size, only not data segment size, but that was considered likely too risky for 7.0. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 11:22:05 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 455FE16A417; Fri, 4 Jan 2008 11:22:05 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 18CEB13C468; Fri, 4 Jan 2008 11:22:05 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 646F74DB9D; Fri, 4 Jan 2008 06:22:04 -0500 (EST) Date: Fri, 4 Jan 2008 11:22:04 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Igor Mozolevsky In-Reply-To: Message-ID: <20080104111938.N77222@fledge.watson.org> References: <477C82F0.5060809@freebsd.org> <863ateemw2.fsf@ds4.des.no> <20080104002002.L30578@fledge.watson.org> <86bq81c12d.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= , freebsd-current@freebsd.org, Jason Evans Subject: Re: sbrk(2) broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 11:22:05 -0000 On Fri, 4 Jan 2008, Igor Mozolevsky wrote: > Of course, if you're afraid of memory overcommit and you know in advance >> how much memory you need, you can simply allocate a sufficient amount of >> address space at startup and touch it all. This way, you will either be >> killed right away, or be guaranteed to have sufficient memory for the rest >> of your (process) lifetime. Alternatively, do what Varnish does: create a >> large file, mmap it, and allocate everything you need from that area, so >> you have your own private swap space. Just make sure to actually allocate >> the disk space you need (by filling the file with zeroes, or at the minimum >> writing a zero to the file every sb.st_blksize bytes, preferably >> sequentially to avoid excessive fragmentation) > > Surely you can just fseek() on the file at the correct lenght? That will create a sparse file without file system blocks to back it, and is effectively also over-commit. When the file system runs out of room, you will get SIGSEGV when the vnode pager discovers it can't write a page to disk. If you zero-fill it, the blocks are pre-allocated. In a more ideal world, we might support an ioctl or system call to pre-allocate but not hook up the blocks until they were written to, in order to avoid writing lots of zeros to disk, but we don't live in that ideal world yet. Allowing malloc to support alternative sources of pages for memory mapping, such as specific files, would be very neat indeed. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 11:30:24 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C6FE16A421 for ; Fri, 4 Jan 2008 11:30:24 +0000 (UTC) (envelope-from mozolevsky@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.171]) by mx1.freebsd.org (Postfix) with ESMTP id E1C2213C474 for ; Fri, 4 Jan 2008 11:30:23 +0000 (UTC) (envelope-from mozolevsky@gmail.com) Received: by ug-out-1314.google.com with SMTP id y2so3603179uge.37 for ; Fri, 04 Jan 2008 03:30:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=gup2pBSTdu+kXZ1uwYSOCBDvBTE5v1msKMfIaje5iuA=; b=UotGhPUIpU2qJ9gmPmMPPzw5rJFaN+jquJ7N8f0x/9aIyayLx4p37ygH2PRv5PbL6blvrCwVrtAxtpyZPYG4k/QsDBGg67s7XfNT+Dj/OT6U6ahp+5SD4AjjSkoQzQUMER4O17hxYQTW0XvUX6tnldTgacG5vTRt12gAi1v4+24= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=ELhzcmkgCcLcObPvA4nURsxQPNv6AQZ5mvDzTRlYvc8sA7pIMRKILgIEFAfWHZrzgCJ1f5+kZ3AkmawkuP0A62oEFS2rGvP6n0Rbr8vBghi7cEKPe32cQawM2KXz9EiAOIrrsjE5+DTmLrmFnCysuMN+MxB0Y3fW9qJwfy2ThjA= Received: by 10.66.252.17 with SMTP id z17mr4222279ugh.50.1199446222499; Fri, 04 Jan 2008 03:30:22 -0800 (PST) Received: by 10.66.248.11 with HTTP; Fri, 4 Jan 2008 03:30:22 -0800 (PST) Message-ID: Date: Fri, 4 Jan 2008 11:30:22 +0000 From: "Igor Mozolevsky" Sender: mozolevsky@gmail.com To: "Robert Watson" In-Reply-To: <20080104111938.N77222@fledge.watson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <477C82F0.5060809@freebsd.org> <863ateemw2.fsf@ds4.des.no> <20080104002002.L30578@fledge.watson.org> <86bq81c12d.fsf@ds4.des.no> <20080104111938.N77222@fledge.watson.org> X-Google-Sender-Auth: 6f7b5e09b60b8fac Cc: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= , freebsd-current@freebsd.org, Jason Evans Subject: Re: sbrk(2) broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 11:30:24 -0000 On 04/01/2008, Robert Watson wrote: > On Fri, 4 Jan 2008, Igor Mozolevsky wrote: > > > Of course, if you're afraid of memory overcommit and you know in advance > >> how much memory you need, you can simply allocate a sufficient amount of > >> address space at startup and touch it all. This way, you will either be > >> killed right away, or be guaranteed to have sufficient memory for the rest > >> of your (process) lifetime. Alternatively, do what Varnish does: create a > >> large file, mmap it, and allocate everything you need from that area, so > >> you have your own private swap space. Just make sure to actually allocate > >> the disk space you need (by filling the file with zeroes, or at the minimum > >> writing a zero to the file every sb.st_blksize bytes, preferably > >> sequentially to avoid excessive fragmentation) > > > > Surely you can just fseek() on the file at the correct lenght? > > That will create a sparse file without file system blocks to back it, and is > effectively also over-commit. When the file system runs out of room, you will > get SIGSEGV when the vnode pager discovers it can't write a page to disk. If > you zero-fill it, the blocks are pre-allocated. Surely you should not be allowed to overcommit on fseek() followed by write(,,1); zeroing out gigs of hdd space seems rather silly... Igor From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 11:31:15 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D79DC16A41B; Fri, 4 Jan 2008 11:31:15 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 7A07213C461; Fri, 4 Jan 2008 11:31:09 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <477E18FB.3040205@FreeBSD.org> Date: Fri, 04 Jan 2008 12:31:07 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Igor Mozolevsky References: <477C82F0.5060809@freebsd.org> <863ateemw2.fsf@ds4.des.no> <20080104002002.L30578@fledge.watson.org> <86bq81c12d.fsf@ds4.des.no> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= , freebsd-current@freebsd.org, Robert Watson , Jason Evans Subject: Re: sbrk(2) broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 11:31:15 -0000 Igor Mozolevsky wrote: > On 04/01/2008, Dag-Erling Smørgrav wrote: > >> For the same reason as it has for the last 20 years or so: memory >> overcommit, which means that malloc() allocates address space, not >> memory. Actual memory is allocated on-demand when the address space is >> used (read from or written to). If there is no RAM left and none can be >> freed by swapping out, the process gets killed. The process that gets >> killed is not necessarily the memory hog, it is merely the process that >> is unlucky enough to touch a new page at the wrong moment, i.e. when all >> RAM and swap is exhausted *or* everything in RAM is wired down and >> unswappable. > > Broadcasting SIGDANGER would be a much better option; followed by > SIGTERM to the memory hogger (to allow for graceful termination) and > only then SIGKILL. I can imagine a few (legitimate) scenarios when a > user process would want to hog as much RAM as possible... Do everyone a favour and research the topic in the archives, please. Another thread on the subject will just waste everyone's time. Kris From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 11:38:24 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A1E7716A418; Fri, 4 Jan 2008 11:38:24 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 700F813C43E; Fri, 4 Jan 2008 11:38:24 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id ACFFB512D6; Fri, 4 Jan 2008 06:38:23 -0500 (EST) Date: Fri, 4 Jan 2008 11:38:23 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Igor Mozolevsky In-Reply-To: Message-ID: <20080104113426.T77222@fledge.watson.org> References: <477C82F0.5060809@freebsd.org> <863ateemw2.fsf@ds4.des.no> <20080104002002.L30578@fledge.watson.org> <86bq81c12d.fsf@ds4.des.no> <20080104111938.N77222@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= , freebsd-current@freebsd.org, Jason Evans Subject: Re: sbrk(2) broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 11:38:24 -0000 On Fri, 4 Jan 2008, Igor Mozolevsky wrote: > On 04/01/2008, Robert Watson wrote: >> On Fri, 4 Jan 2008, Igor Mozolevsky wrote: >> >>> Of course, if you're afraid of memory overcommit and you know in advance >>>> how much memory you need, you can simply allocate a sufficient amount of >>>> address space at startup and touch it all. This way, you will either be >>>> killed right away, or be guaranteed to have sufficient memory for the >>>> rest of your (process) lifetime. Alternatively, do what Varnish does: >>>> create a large file, mmap it, and allocate everything you need from that >>>> area, so you have your own private swap space. Just make sure to >>>> actually allocate the disk space you need (by filling the file with >>>> zeroes, or at the minimum writing a zero to the file every sb.st_blksize >>>> bytes, preferably sequentially to avoid excessive fragmentation) >>> >>> Surely you can just fseek() on the file at the correct lenght? >> >> That will create a sparse file without file system blocks to back it, and >> is effectively also over-commit. When the file system runs out of room, >> you will get SIGSEGV when the vnode pager discovers it can't write a page >> to disk. If you zero-fill it, the blocks are pre-allocated. > > Surely you should not be allowed to overcommit on fseek() followed by > write(,,1); zeroing out gigs of hdd space seems rather silly... Sparse files are a feature. It just becomes inconvenient at that point because you discover the lack of space asynchronously from a useful user process event. When memory pressure gets high, the vnode pager decides it's time to push a dirty page to disk, and then discovers that there are no free blocks on the file system to write to. As I mentioned in my e-mail, it would be nice if our file system supported a way to reserve blocks for files without hooking them up to the file's visiible address space (in order to avoid zeroing them, which is required if you do want to hook them up for an unprivileged process). However, that feature doesn't currently exist. Many systems with sensitivity to on-demand allocation costs and without security requirements allow files to be extended without zeroing. On systems with security requirements, this becomes a privileged operation (such as on Mac OS X) because exposing unzeroed pages from other files or processes not explicitly shared is Not Allowed. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 11:42:51 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7304D16A49E for ; Fri, 4 Jan 2008 11:42:51 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 2CA7A13C457 for ; Fri, 4 Jan 2008 11:42:50 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JAkwk-0003kM-3N for freebsd-current@freebsd.org; Fri, 04 Jan 2008 11:42:42 +0000 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 04 Jan 2008 11:42:42 +0000 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 04 Jan 2008 11:42:42 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Fri, 04 Jan 2008 12:42:28 +0100 Lines: 26 Message-ID: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig2359F93E64CE8E64AD3DF4B9" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 2.0.0.9 (X11/20070801) X-Enigmail-Version: 0.95.5 Sender: news Subject: When will ZFS become stable? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 11:42:51 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2359F93E64CE8E64AD3DF4B9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, As far as I know about the details of implementation and what would it take to fix the problems, is it safe to assume ZFS will never become stable during 7.x lifetime? --------------enig2359F93E64CE8E64AD3DF4B9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFHfhuqldnAQVacBcgRArdiAKDlGnUigVzolVxBSUQqMdGBr56AlwCg5xFs 41vO9M9O3zRxOlq7QrKKXzw= =t+Xr -----END PGP SIGNATURE----- --------------enig2359F93E64CE8E64AD3DF4B9-- From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 12:21:57 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B352916A418 for ; Fri, 4 Jan 2008 12:21:57 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id 3296713C46E for ; Fri, 4 Jan 2008 12:21:56 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.14.2/8.14.2) with ESMTP id m04CLs7k017200; Fri, 4 Jan 2008 15:21:54 +0300 (MSK) (envelope-from ache@nagual.pp.ru) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nagual.pp.ru; s=default; t=1199449314; bh=CPW+C7DpBO+rg76UTJXBzw3UnD78QweUs+3j6M2 9g7I=; l=507; h=Date:From:To:Cc:Subject:Message-ID:Mail-Followup-To: References:MIME-Version:Content-Type:Content-Disposition: In-Reply-To:User-Agent; b=svmdkCZaI3GbXhpUB7f/3PZdl7HsWmxMuL9ZV2Xg KE93y96dUydRtYA8Gq6Agd/mZW3t6yy/525t99SwosjpvOqpCrGR2t56CBr8h6KmFsV l2+Q41SgZF1PLfcjswqq1GL5aJcDY5raCiUrVwSMMiTXmezhiiLGccMn/HmL/a6g= Received: (from ache@localhost) by nagual.pp.ru (8.14.2/8.14.2/Submit) id m04CLqYk017199; Fri, 4 Jan 2008 15:21:53 +0300 (MSK) (envelope-from ache) Date: Fri, 4 Jan 2008 15:21:50 +0300 From: Andrey Chernov To: Jason Evans Message-ID: <20080104122149.GA17103@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , Jason Evans , freebsd-current@FreeBSD.ORG, Poul-Henning Kamp References: <477C82F0.5060809@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <477C82F0.5060809@freebsd.org> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-current@FreeBSD.ORG, Poul-Henning Kamp Subject: Re: sbrk(2) broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 12:21:57 -0000 On Wed, Jan 02, 2008 at 10:38:40PM -0800, Jason Evans wrote: > Poul-Henning noticed today that xchat fails to start if malloc uses sbrk > internally. Malloc() itself knows about memory amount _really_ in use by a program and could check it don't go beyond the limits, but for this it needs run-time check via getrlimit() call for each malloc() call (a program can use setrlimit() by itself). Traking direct mmap()s and sbrk()s outside of malloc() is also needed. -- http://ache.pp.ru/ From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 12:25:11 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A46AF16A46D for ; Fri, 4 Jan 2008 12:25:11 +0000 (UTC) (envelope-from unga888@yahoo.com) Received: from web57008.mail.re3.yahoo.com (web57008.mail.re3.yahoo.com [66.196.97.112]) by mx1.freebsd.org (Postfix) with SMTP id 42F9213C4DB for ; Fri, 4 Jan 2008 12:25:11 +0000 (UTC) (envelope-from unga888@yahoo.com) Received: (qmail 97094 invoked by uid 60001); 4 Jan 2008 11:58:29 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=ccmXl7AyZMhYbSWVD2NC3VltXxWqxWOgo49D+E9xQhjlN55bzH2e9QYAqRW54pbq/6P61aTKx0rQLFSs58ChOaganfq/bTloGRwokLAsyjVY6hpC9Ub0wHcTMKfl54K1COopykTi6A8W1dg2po1yKuVaBEfuSZ/aIdlg//IJ+WU=; X-YMail-OSG: pRharbsVM1m7cKW0QUwko4RysFFH6DHNaqqidceZTe03OncLm3oL8UkESFHXKIMFICeuekf.L8R4W.VDI3d2EZ1B6LgKq.t77TCjNJNOWgU_dx8bEQu9.voySeQl4UIpCDv.C7ub6ZsIs8.deOQFyqOf8A-- Received: from [165.21.155.69] by web57008.mail.re3.yahoo.com via HTTP; Fri, 04 Jan 2008 03:58:29 PST Date: Fri, 4 Jan 2008 03:58:29 -0800 (PST) From: Unga To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <829048.96565.qm@web57008.mail.re3.yahoo.com> Subject: 7.0-PRERELEASE installworld fails X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 12:25:11 -0000 Hi all I'm making a kernel upgrade on 7.0-BETA4 with the today's sources downloaded by cvsup. make installworld fails with following error: -------------------------------------------------------------- >>> Installing everything -------------------------------------------------------------- cd /usr/src; make -f Makefile.inc1 install ===> share/info (install) ===> lib (install) ===> lib/csu/i386-elf (install) cc -O2 -fno-strict-aliasing -pipe -I/usr/src/lib/csu/i386-elf/../common -I/usr /src/lib/csu/i386-elf/../../libc/include -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit h -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunu sed-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno -pointer-sign -c /usr/src/lib/csu/i386-elf/crt1.c /usr/src/lib/csu/i386-elf/crt1.c:33:20: error: stdlib.h: No such file or directo ry In file included from /usr/src/lib/csu/i386-elf/crt1.c:35: /usr/src/lib/csu/i386-elf/../../libc/include/libc_private.h:178:24: error: sys/_ types.h: No such file or directory Please note, make buildworld, make kernel-toolchain, make buildkernel and make installkernel works without an error. Btw, I'm new to FreeBSD, but I'm not new to Unix. I have attempted the kernel upgrade as per the Handbook and UPDATING. I can provide more detail on my steps if necessary. Is this some mistake from my side or an error in the FreeBSD side? Appreciate an reply on this issue. Best Regards Unga ____________________________________________________________________________________ Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 12:34:42 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A676C16A417; Fri, 4 Jan 2008 12:34:42 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 5D20813C45D; Fri, 4 Jan 2008 12:34:42 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 9C2AD209C; Fri, 4 Jan 2008 13:34:33 +0100 (CET) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: -0.2/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 8A96E2049; Fri, 4 Jan 2008 13:34:33 +0100 (CET) Received: by ds4.des.no (Postfix, from userid 1001) id 6B3D0844CD; Fri, 4 Jan 2008 13:34:33 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Robert Watson References: <477C82F0.5060809@freebsd.org> <863ateemw2.fsf@ds4.des.no> <20080104002002.L30578@fledge.watson.org> <86wsqqaqbe.fsf@ds4.des.no> <20080104110511.S77222@fledge.watson.org> Date: Fri, 04 Jan 2008 13:34:33 +0100 In-Reply-To: <20080104110511.S77222@fledge.watson.org> (Robert Watson's message of "Fri\, 4 Jan 2008 11\:06\:03 +0000 \(GMT\)") Message-ID: <86r6gxahwm.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, Jason Evans , Poul-Henning Kamp Subject: Re: sbrk(2) broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 12:34:42 -0000 Robert Watson writes: > Dag-Erling Sm=C3=B8rgrav writes: > > Robert Watson writes: > > > The right answer is presumably to introduce a new LIMIT_SWAP, which > > > limits the allocation of anonymous memory by processes, and size it to > > > something like 90% of swap space by default. > > Not a good solution on its own. You need a per-process limit as > > well, otherwise a malloc() bomb will still cause other processes to > > fail randomly. > That was what I had in mind, the above should read RLIMIT_SWAP. You don't want the default to be so high. You want a low default, with the possibility for the admin to increase the limit for a particular user in login.conf or similar without rebooting (which is currently not possible since the default datasize =3D=3D maxdsiz, which can only be changed in the kernel config or loader.conf) You may also want to have a collective limit for unprivileged users, so root will still be able to log in if something goes wrong. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 12:45:38 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B4DA716A419; Fri, 4 Jan 2008 12:45:38 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 6B22213C458; Fri, 4 Jan 2008 12:45:38 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 4FFB420BE; Fri, 4 Jan 2008 13:45:30 +0100 (CET) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: -0.2/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 2AC0020BD; Fri, 4 Jan 2008 13:45:30 +0100 (CET) Received: by ds4.des.no (Postfix, from userid 1001) id 04399844CD; Fri, 4 Jan 2008 13:45:30 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: "Igor Mozolevsky" References: <477C82F0.5060809@freebsd.org> <863ateemw2.fsf@ds4.des.no> <20080104002002.L30578@fledge.watson.org> <86bq81c12d.fsf@ds4.des.no> Date: Fri, 04 Jan 2008 13:45:29 +0100 In-Reply-To: (Igor Mozolevsky's message of "Fri\, 4 Jan 2008 11\:18\:05 +0000") Message-ID: <86myrlahee.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, Robert Watson , Jason Evans Subject: Re: sbrk(2) broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 12:45:38 -0000 "Igor Mozolevsky" writes: > Broadcasting SIGDANGER would be a much better option; followed by > SIGTERM to the memory hogger (to allow for graceful termination) and > only then SIGKILL. I can imagine a few (legitimate) scenarios when a > user process would want to hog as much RAM as possible... We don't currently have SIGDANGER, but the signal code was rewritten years ago to allow more than 32 signals precisely for the purpose of implementing an AIX-like SIGDANGER. This wasn't done, however, and eventually SIGTHR was the first new signal to take advantage of the rewritten code. > [about pre-zeroing a backing file] > Surely you can just fseek() on the file at the correct lenght? No. First of all, you're thinking of lseek(), not fseek() Second, an lseek() beyond the end of a file will not actually extend the file. Third, ftruncate() (which *will* extend a file if it is shorter than the requested length) or lseek() followed by write() will not allocate physical disk space except for the data actually written; it will create a sparse file, which when later written to will become fragmented, resulting in horrible performance. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 12:47:29 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C56216A41A for ; Fri, 4 Jan 2008 12:47:29 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay02.kiev.sovam.com (relay02.kiev.sovam.com [62.64.120.197]) by mx1.freebsd.org (Postfix) with ESMTP id 48DF913C4E8 for ; Fri, 4 Jan 2008 12:47:29 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.226] (helo=deviant.kiev.zoral.com.ua) by relay02.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1JAlxH-0009Jb-RL for freebsd-current@freebsd.org; Fri, 04 Jan 2008 14:47:28 +0200 Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m04ClJQ9007746; Fri, 4 Jan 2008 14:47:19 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id m04ClIPI007745; Fri, 4 Jan 2008 14:47:18 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 4 Jan 2008 14:47:18 +0200 From: Kostik Belousov To: Peter Jeremy Message-ID: <20080104124718.GZ57756@deviant.kiev.zoral.com.ua> References: <20080104002002.L30578@fledge.watson.org> <20080104095132.GC947@server.vk2pj.dyndns.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7uy9XegIstZRHI/L" Content-Disposition: inline In-Reply-To: <20080104095132.GC947@server.vk2pj.dyndns.org> User-Agent: Mutt/1.4.2.3i X-Scanner-Signature: bf674e48040b805769da4ba4af5b826b X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 1976 [Dec 29 2007] X-SpamTest-Info: helo_type=3 X-SpamTest-Info: {received from trusted relay: not dialup} X-SpamTest-Method: none X-SpamTest-Method: Local Lists X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0255], KAS30/Release Cc: Ian FREISLICH , freebsd-current@freebsd.org Subject: Re: sbrk(2) broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 12:47:29 -0000 --7uy9XegIstZRHI/L Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 04, 2008 at 08:51:32PM +1100, Peter Jeremy wrote: > On Fri, Jan 04, 2008 at 08:27:41AM +0200, Ian FREISLICH wrote: > >I have long lived processes that continuously handle very valuable > >data and potentially get very large (several GB). I'd like that > >process to be able to make a rational decision about what happens to its > >memory contents when an allocation fails rather than having the > >proverbial rug pulled out from under it. Rug pulling at any point=20 > >can cost an annual salary or two. >=20 > If you google for freebsd+sigdanger, you will find that this topic > was first discussed nearly 10 years ago. Unfortunately, no progress > appears to have been made, though it crops up every few years. I need to make a slight correction there: some time ago the patch at the http://people.freebsd.org/~kib/overcommit/index.html works, at least I believe so. I implemented overcommit turn-off knob and did the exact anonymous memory accounting. Quite possible, the code rotten since then. --7uy9XegIstZRHI/L Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHfirVC3+MBN1Mb4gRAlFXAKCijH04tmW5ImcTafJ7Cav/+dqTxACg4nrD JGjNqGYTO9EJmCx2zZK5WWE= =Le2r -----END PGP SIGNATURE----- --7uy9XegIstZRHI/L-- From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 12:48:44 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D998116A419; Fri, 4 Jan 2008 12:48:44 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 8EAA213C468; Fri, 4 Jan 2008 12:48:44 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 52D3220BB; Fri, 4 Jan 2008 13:48:36 +0100 (CET) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: -0.2/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 3E62620B9; Fri, 4 Jan 2008 13:48:36 +0100 (CET) Received: by ds4.des.no (Postfix, from userid 1001) id 1B7CD844CD; Fri, 4 Jan 2008 13:48:36 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Robert Watson References: <477C82F0.5060809@freebsd.org> <863ateemw2.fsf@ds4.des.no> <20080104002002.L30578@fledge.watson.org> <86bq81c12d.fsf@ds4.des.no> <20080104111938.N77222@fledge.watson.org> <20080104113426.T77222@fledge.watson.org> Date: Fri, 04 Jan 2008 13:48:36 +0100 In-Reply-To: <20080104113426.T77222@fledge.watson.org> (Robert Watson's message of "Fri\, 4 Jan 2008 11\:38\:23 +0000 \(GMT\)") Message-ID: <86ir29ah97.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, Jason Evans , Igor Mozolevsky Subject: Re: sbrk(2) broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 12:48:44 -0000 Robert Watson writes: > As I mentioned in my e-mail, it would be nice if our file system > supported a way to reserve blocks for files without hooking them up to > the file's visiible address space (in order to avoid zeroing them, > which is required if you do want to hook them up for an unprivileged > process). However, that feature doesn't currently exist. Even for files which are intended to be filled up immediately, telling the file system ahead of time how much data will be written would allow it to make much better layout decisions. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 12:54:00 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5BB4F16A419; Fri, 4 Jan 2008 12:54:00 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 1700913C4DB; Fri, 4 Jan 2008 12:53:59 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 9F4EA17105; Fri, 4 Jan 2008 12:53:58 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.2/8.14.2) with ESMTP id m04Crvx6005648; Fri, 4 Jan 2008 12:53:57 GMT (envelope-from phk@critter.freebsd.dk) To: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= From: "Poul-Henning Kamp" In-Reply-To: Your message of "Fri, 04 Jan 2008 13:45:29 +0100." <86myrlahee.fsf@ds4.des.no> Date: Fri, 04 Jan 2008 12:53:57 +0000 Message-ID: <5647.1199451237@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: freebsd-current@freebsd.org, Robert Watson , Jason Evans , Igor Mozolevsky Subject: Re: sbrk(2) broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 12:54:00 -0000 In message <86myrlahee.fsf@ds4.des.no>, =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= wr ites: >"Igor Mozolevsky" writes: >> Broadcasting SIGDANGER would be a much better option; followed by >> SIGTERM to the memory hogger (to allow for graceful termination) and >> only then SIGKILL. I can imagine a few (legitimate) scenarios when a >> user process would want to hog as much RAM as possible... > >We don't currently have SIGDANGER, but the signal code was rewritten >years ago to allow more than 32 signals precisely for the purpose of >implementing an AIX-like SIGDANGER. This wasn't done, however, and >eventually SIGTHR was the first new signal to take advantage of the >rewritten code. SIGDANGER is not what we need. What we need is an intelligent mechanism to tell applications what the overall situation is, so that jemalloc and aware applications can tune their usage pattern to the availability of physical and virtual memory. Instead of the binary "SIGDANGER" indication we need a more gradual state, at the very least three stats: "plenty", "getting a bit tight" and "crunchtime". Having a signal to indicate changes of the state may make sense, but in a crunch, you don't want to wake all processes and page them in, just to tell them that you're short on memory, it would have to be a signal that doesn't schedule the recipient process until something else does. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 12:57:13 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6F16116A41A; Fri, 4 Jan 2008 12:57:13 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 2EBFB13C4EF; Fri, 4 Jan 2008 12:57:12 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 0368517106; Fri, 4 Jan 2008 12:57:11 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.2/8.14.2) with ESMTP id m04CvBOY005706; Fri, 4 Jan 2008 12:57:11 GMT (envelope-from phk@critter.freebsd.dk) To: Andrey Chernov From: "Poul-Henning Kamp" In-Reply-To: Your message of "Fri, 04 Jan 2008 15:21:50 +0300." <20080104122149.GA17103@nagual.pp.ru> Date: Fri, 04 Jan 2008 12:57:11 +0000 Message-ID: <5705.1199451431@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: freebsd-current@FreeBSD.ORG, Jason Evans Subject: Re: sbrk(2) broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 12:57:13 -0000 In message <20080104122149.GA17103@nagual.pp.ru>, Andrey Chernov writes: >On Wed, Jan 02, 2008 at 10:38:40PM -0800, Jason Evans wrote: >> Poul-Henning noticed today that xchat fails to start if malloc uses sbrk >> internally. > >Malloc() itself knows about memory amount _really_ in use by a program [...] No, the VM system has a much better idea about this. You need to think about this the right way: There is address space allocated to the process (via sbrk/mmap) A subset of this, is address space allocated by the program (via malloc) ...and then there is memory actually in use, which is an entirely different thing, of which we currently only have some kind of clue in the VM system. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 13:03:03 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F081C16A481 for ; Fri, 4 Jan 2008 13:03:03 +0000 (UTC) (envelope-from mozolevsky@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.169]) by mx1.freebsd.org (Postfix) with ESMTP id 7EA9D13C458 for ; Fri, 4 Jan 2008 13:03:03 +0000 (UTC) (envelope-from mozolevsky@gmail.com) Received: by ug-out-1314.google.com with SMTP id y2so3612906uge.37 for ; Fri, 04 Jan 2008 05:03:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=dNVrgIL2qP5uc0PBDlUHwoSGTPLhB8bhmKAY/xitfzs=; b=lgd+iEpxezEFJ1D7/OArix0djxgIkjtKLiV7jNPTwGYjpwYEgc71FHDqufhBdEalKVW3jPsG6zwTT/EST9bZd6G38oDKMq1tNXxm2wfL1hyD9CiOjSwE5qvC65GSzP4Tc4iYHdVepc6iGfe5d3M+EMbbHWMWKiML1DZ2ab3Ey9s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=xNA8zB6UZrGatqkLkZV6WGW37tVat2l5RhQYg4R8mbyAnkv8gXN/PzATvYUtw8wd4hoDeAJ8DpR7JMv001jwHCQ2kq+NSgFnndvyj7744/DoViNUln5aOM082p8cCksLYSOYV/fY0PK6jypBrbWItAvNiy5znmURj+R5cQBL7uc= Received: by 10.67.116.15 with SMTP id t15mr1347142ugm.21.1199451781996; Fri, 04 Jan 2008 05:03:01 -0800 (PST) Received: by 10.66.248.11 with HTTP; Fri, 4 Jan 2008 05:03:01 -0800 (PST) Message-ID: Date: Fri, 4 Jan 2008 13:03:01 +0000 From: "Igor Mozolevsky" Sender: mozolevsky@gmail.com To: "Poul-Henning Kamp" In-Reply-To: <5647.1199451237@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <86myrlahee.fsf@ds4.des.no> <5647.1199451237@critter.freebsd.dk> X-Google-Sender-Auth: cf87e6e2b8316bf5 Cc: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= , freebsd-current@freebsd.org, Robert Watson , Jason Evans Subject: Re: sbrk(2) broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 13:03:04 -0000 On 04/01/2008, Poul-Henning Kamp wrote: > SIGDANGER is not what we need. > > What we need is an intelligent mechanism to tell applications what > the overall situation is, so that jemalloc and aware applications can > tune their usage pattern to the availability of physical and virtual > memory. > > Instead of the binary "SIGDANGER" indication we need a more gradual > state, at the very least three stats: "plenty", "getting a bit > tight" and "crunchtime". This makes memory management in the userland hideously and unnecessarily complicated. It's simpler to have SIGDANGER (meaning, free all you can) -> SIGTERM (terminate gracefully) -> SIGKILL (too late, I'm killing you anyway); and maybe a MIB in sysctl like ...vm.overcommit_action ='soft' being SIGDANGER->SIGTERM->SIGKILL and = 'hard' being SIGKILL, so the sysadmin at least has a choice Igor From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 13:12:50 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AB6DA16A598; Fri, 4 Jan 2008 13:12:50 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id 652A813C46E; Fri, 4 Jan 2008 13:12:49 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.14.2/8.14.2) with ESMTP id m04DClnW017948; Fri, 4 Jan 2008 16:12:48 +0300 (MSK) (envelope-from ache@nagual.pp.ru) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nagual.pp.ru; s=default; t=1199452368; bh=n/IDD2IV4h+atDBjmVAnXxAU2QmzOHbjxLnGTXj 2K9Y=; l=570; h=Date:From:To:Cc:Subject:Message-ID:Mail-Followup-To: References:MIME-Version:Content-Type:Content-Disposition: In-Reply-To:User-Agent; b=LCkwsTyQlpWNs5VZKy2XoeTxzsACRB9bEijnQw7Z 5SXq2gKu4nfzywa3jn9l+Ha33aQiElgWE8scwhR4m/bkTJurYV4lsPkDD56exE/KSzF /fjETYgbMY/iNm/WEqHmNvokXU/VFSUqwqSPeOfopsFQrSrkmH1MVP3CfnSU5t7Q= Received: (from ache@localhost) by nagual.pp.ru (8.14.2/8.14.2/Submit) id m04DClOC017947; Fri, 4 Jan 2008 16:12:47 +0300 (MSK) (envelope-from ache) Date: Fri, 4 Jan 2008 16:12:47 +0300 From: Andrey Chernov To: Poul-Henning Kamp Message-ID: <20080104131247.GA17816@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , Poul-Henning Kamp , freebsd-current@FreeBSD.ORG, Jason Evans References: <20080104122149.GA17103@nagual.pp.ru> <5705.1199451431@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5705.1199451431@critter.freebsd.dk> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-current@FreeBSD.ORG, Jason Evans Subject: Re: sbrk(2) broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 13:12:50 -0000 On Fri, Jan 04, 2008 at 12:57:11PM +0000, Poul-Henning Kamp wrote: > There is address space allocated to the process (via sbrk/mmap) > > A subset of this, is address space allocated by the program (via malloc) > > ...and then there is memory actually in use, which is an entirely different > thing, of which we currently only have some kind of clue in the VM > system. Then, we need sysctl to fetch that "memory actually in use" from the kernel and compare that with getrlimit() which allows malloc() to return 0 when needed. -- http://ache.pp.ru/ From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 13:12:59 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 14F0116A594; Fri, 4 Jan 2008 13:12:59 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id C313213C4DD; Fri, 4 Jan 2008 13:12:58 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 4FB1720A0; Fri, 4 Jan 2008 14:12:50 +0100 (CET) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: -0.2/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 4150B207E; Fri, 4 Jan 2008 14:12:50 +0100 (CET) Received: by ds4.des.no (Postfix, from userid 1001) id 28097844CD; Fri, 4 Jan 2008 14:12:50 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: "Igor Mozolevsky" References: <86myrlahee.fsf@ds4.des.no> <5647.1199451237@critter.freebsd.dk> Date: Fri, 04 Jan 2008 14:12:50 +0100 In-Reply-To: (Igor Mozolevsky's message of "Fri\, 4 Jan 2008 13\:03\:01 +0000") Message-ID: <86abnlag4t.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Poul-Henning Kamp , freebsd-current@freebsd.org, Robert Watson , Jason Evans Subject: Re: sbrk(2) broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 13:12:59 -0000 "Igor Mozolevsky" writes: > This makes memory management in the userland hideously and > unnecessarily complicated. It's simpler to have SIGDANGER [...] You don't seem to understand what Poul-Henning was trying to point out, which is that broadcasting SIGDANGER can make a bad situation much, much worse by waking up and paging in every single process in the system, including processes that are blocked and wouldn't otherwise run for several minutes, hours or even days (getty, inetd, sshd, mountd, even nfsd / nfsiod in some cases can sleep for days at a time waiting for I/O) DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 13:24:29 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8D0B416A420; Fri, 4 Jan 2008 13:24:29 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 629E213C442; Fri, 4 Jan 2008 13:24:29 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 8E5A14A9FA; Fri, 4 Jan 2008 08:24:28 -0500 (EST) Date: Fri, 4 Jan 2008 13:24:28 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= In-Reply-To: <86abnlag4t.fsf@ds4.des.no> Message-ID: <20080104132310.X77222@fledge.watson.org> References: <86myrlahee.fsf@ds4.des.no> <5647.1199451237@critter.freebsd.dk> <86abnlag4t.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="621616949-924143580-1199453068=:77222" Cc: Poul-Henning Kamp , freebsd-current@freebsd.org, Jason Evans , Igor Mozolevsky Subject: Re: sbrk(2) broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 13:24:29 -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. --621616949-924143580-1199453068=:77222 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Fri, 4 Jan 2008, Dag-Erling Sm=F8rgrav wrote: > "Igor Mozolevsky" writes: >> This makes memory management in the userland hideously and unnecessarily= =20 >> complicated. It's simpler to have SIGDANGER [...] > > You don't seem to understand what Poul-Henning was trying to point out,= =20 > which is that broadcasting SIGDANGER can make a bad situation much, much= =20 > worse by waking up and paging in every single process in the system,=20 > including processes that are blocked and wouldn't otherwise run for sever= al=20 > minutes, hours or even days (getty, inetd, sshd, mountd, even nfsd / nfsi= od=20 > in some cases can sleep for days at a time waiting for I/O) Another aspect of the problem is that applications have come to depend in= =20 malloc(3) returning NULL when memory is getting tight, and while we have ne= ver=20 done exactly that, we have historically had malloc(3) return NULL when we g= et=20 close to the process data segment size. Robert N M Watson Computer Laboratory University of Cambridge --621616949-924143580-1199453068=:77222-- From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 13:26:38 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B533416A417; Fri, 4 Jan 2008 13:26:38 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 85BAE13C45B; Fri, 4 Jan 2008 13:26:38 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id E8BBD4ADE5; Fri, 4 Jan 2008 08:26:37 -0500 (EST) Date: Fri, 4 Jan 2008 13:26:37 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= In-Reply-To: <86r6gxahwm.fsf@ds4.des.no> Message-ID: <20080104132437.U77222@fledge.watson.org> References: <477C82F0.5060809@freebsd.org> <863ateemw2.fsf@ds4.des.no> <20080104002002.L30578@fledge.watson.org> <86wsqqaqbe.fsf@ds4.des.no> <20080104110511.S77222@fledge.watson.org> <86r6gxahwm.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="621616949-307192972-1199453197=:77222" Cc: freebsd-current@freebsd.org, Jason Evans , Poul-Henning Kamp Subject: Re: sbrk(2) broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 13:26:38 -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. --621616949-307192972-1199453197=:77222 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Fri, 4 Jan 2008, Dag-Erling Sm=F8rgrav wrote: > Robert Watson writes: >> Dag-Erling Sm=F8rgrav writes: >>> Robert Watson writes: >>>> The right answer is presumably to introduce a new LIMIT_SWAP, which=20 >>>> limits the allocation of anonymous memory by processes, and size it to= =20 >>>> something like 90% of swap space by default. >>> Not a good solution on its own. You need a per-process limit as well,= =20 >>> otherwise a malloc() bomb will still cause other processes to fail=20 >>> randomly. >> That was what I had in mind, the above should read RLIMIT_SWAP. > > You don't want the default to be so high. You want a low default, with t= he=20 > possibility for the admin to increase the limit for a particular user in= =20 > login.conf or similar without rebooting (which is currently not possible= =20 > since the default datasize =3D=3D maxdsiz, which can only be changed in t= he=20 > kernel config or loader.conf) I'm fine with also having global limits. > You may also want to have a collective limit for unprivileged users, so r= oot=20 > will still be able to log in if something goes wrong. This will presumably only work for console logins, as sshd (etc) will depen= d=20 on unprivileged users, but perhaps that is fine. I'm less concerned with t= he=20 details of the implementation or policy than that we simply be able to supp= ort=20 even a basic policy and have it configured by default to prevent=20 foot-shooting. Robert N M Watson Computer Laboratory University of Cambridge --621616949-307192972-1199453197=:77222-- From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 13:28:41 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B04D216A47B; Fri, 4 Jan 2008 13:28:41 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 4388013C4EB; Fri, 4 Jan 2008 13:28:41 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 936DF17105; Fri, 4 Jan 2008 13:28:39 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.2/8.14.2) with ESMTP id m04DSd9S005975; Fri, 4 Jan 2008 13:28:39 GMT (envelope-from phk@critter.freebsd.dk) To: Andrey Chernov From: "Poul-Henning Kamp" In-Reply-To: Your message of "Fri, 04 Jan 2008 16:12:47 +0300." <20080104131247.GA17816@nagual.pp.ru> Date: Fri, 04 Jan 2008 13:28:39 +0000 Message-ID: <5974.1199453319@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: freebsd-current@FreeBSD.ORG, Jason Evans Subject: Re: sbrk(2) broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 13:28:41 -0000 In message <20080104131247.GA17816@nagual.pp.ru>, Andrey Chernov writes: >On Fri, Jan 04, 2008 at 12:57:11PM +0000, Poul-Henning Kamp wrote: >> There is address space allocated to the process (via sbrk/mmap) >> >> A subset of this, is address space allocated by the program (via malloc) >> >> ...and then there is memory actually in use, which is an entirely different >> thing, of which we currently only have some kind of clue in the VM >> system. > >Then, we need sysctl to fetch that "memory actually in use" from the >kernel and compare that with getrlimit() which allows malloc() to return >0 when needed. No we don't. Find a book that explains how Virtual Memory works. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 13:43:52 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 368D716A418 for ; Fri, 4 Jan 2008 13:43:52 +0000 (UTC) (envelope-from davidt@yadt.co.uk) Received: from outcold.yadt.co.uk (outcold.yadt.co.uk [81.187.204.178]) by mx1.freebsd.org (Postfix) with ESMTP id D72CA13C442 for ; Fri, 4 Jan 2008 13:43:51 +0000 (UTC) (envelope-from davidt@yadt.co.uk) Received: from localhost (localhost [127.0.0.1]) by outcold.yadt.co.uk (Postfix) with ESMTP id 5AAD5186A; Fri, 4 Jan 2008 13:25:48 +0000 (GMT) X-Virus-Scanned: amavisd-new at yadt.co.uk Received: from outcold.yadt.co.uk ([127.0.0.1]) by localhost (outcold.yadt.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XRtB-1i2KosG; Fri, 4 Jan 2008 13:25:45 +0000 (GMT) Received: by outcold.yadt.co.uk (Postfix, from userid 1001) id E1D5D1863; Fri, 4 Jan 2008 13:25:45 +0000 (GMT) Date: Fri, 4 Jan 2008 13:25:45 +0000 From: David Taylor To: Andrey Chernov Message-ID: <20080104132545.GA51075@outcold.yadt.co.uk> Mail-Followup-To: Andrey Chernov , freebsd-current@FreeBSD.ORG References: <20080104122149.GA17103@nagual.pp.ru> <5705.1199451431@critter.freebsd.dk> <20080104131247.GA17816@nagual.pp.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <20080104131247.GA17816@nagual.pp.ru> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-current@FreeBSD.ORG Subject: Re: sbrk(2) broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 13:43:52 -0000 On Fri, 04 Jan 2008, Andrey Chernov wrote: > On Fri, Jan 04, 2008 at 12:57:11PM +0000, Poul-Henning Kamp wrote: > > There is address space allocated to the process (via sbrk/mmap) > > > > A subset of this, is address space allocated by the program (via malloc) > > > > ...and then there is memory actually in use, which is an entirely different > > thing, of which we currently only have some kind of clue in the VM > > system. > > Then, we need sysctl to fetch that "memory actually in use" from the > kernel and compare that with getrlimit() which allows malloc() to return > 0 when needed. That won't help much -- malloc could have allocated some address space that hasn't (yet) been touched by the process. Just returning 0 when the amount of memory "in use" hits a limit wouldn't stop the process from then touching all the memory it has previously been allocated and exceeding the limit. -- David Taylor From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 13:48:40 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4BD1B16A417; Fri, 4 Jan 2008 13:48:40 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay02.kiev.sovam.com (relay02.kiev.sovam.com [62.64.120.197]) by mx1.freebsd.org (Postfix) with ESMTP id E473213C50D; Fri, 4 Jan 2008 13:48:39 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.226] (helo=deviant.kiev.zoral.com.ua) by relay02.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1JAmuU-000PGi-2Y; Fri, 04 Jan 2008 15:48:38 +0200 Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m04DmTeu067071; Fri, 4 Jan 2008 15:48:29 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id m04DmTTd067070; Fri, 4 Jan 2008 15:48:29 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 4 Jan 2008 15:48:29 +0200 From: Kostik Belousov To: Dag-Erling Sm??rgrav Message-ID: <20080104134829.GA57756@deviant.kiev.zoral.com.ua> References: <86myrlahee.fsf@ds4.des.no> <5647.1199451237@critter.freebsd.dk> <86abnlag4t.fsf@ds4.des.no> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="28KEV0d44fEAywNn" Content-Disposition: inline In-Reply-To: <86abnlag4t.fsf@ds4.des.no> User-Agent: Mutt/1.4.2.3i X-Scanner-Signature: a8c813420754d5015e2a5a3aeed75c84 X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 1976 [Dec 29 2007] X-SpamTest-Info: helo_type=3 X-SpamTest-Info: {received from trusted relay: not dialup} X-SpamTest-Method: none X-SpamTest-Method: Local Lists X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0255], KAS30/Release Cc: Poul-Henning Kamp , freebsd-current@freebsd.org, Robert Watson , Jason Evans , Igor Mozolevsky Subject: Re: sbrk(2) broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 13:48:40 -0000 --28KEV0d44fEAywNn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 04, 2008 at 02:12:50PM +0100, Dag-Erling Sm??rgrav wrote: > "Igor Mozolevsky" writes: > > This makes memory management in the userland hideously and > > unnecessarily complicated. It's simpler to have SIGDANGER [...] >=20 > You don't seem to understand what Poul-Henning was trying to point out, > which is that broadcasting SIGDANGER can make a bad situation much, much > worse by waking up and paging in every single process in the system, > including processes that are blocked and wouldn't otherwise run for > several minutes, hours or even days (getty, inetd, sshd, mountd, even > nfsd / nfsiod in some cases can sleep for days at a time waiting for > I/O) By making the default action for SIGDANGER to be SIG_IGN, this problem would be mostly solved. Only processes that actually care about SIGDANGER and installing the handler for it would require some non-trivial and resource-hungry operation. --28KEV0d44fEAywNn Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHfjksC3+MBN1Mb4gRAmJjAKDta4Mk4AjCW2d0m5X/14Nkpo944QCgs4WC vcLoV3Fz6xWAXkmkPWhOFbc= =R3Hf -----END PGP SIGNATURE----- --28KEV0d44fEAywNn-- From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 13:53:37 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 19E0916A41B for ; Fri, 4 Jan 2008 13:53:37 +0000 (UTC) (envelope-from skip@menantico.com) Received: from vms173003pub.verizon.net (vms173003pub.verizon.net [206.46.173.3]) by mx1.freebsd.org (Postfix) with ESMTP id E535213C459 for ; Fri, 4 Jan 2008 13:53:36 +0000 (UTC) (envelope-from skip@menantico.com) Received: from mx.menantico.com ([71.168.197.190]) by vms173003.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0JU400GPCH66DDR3@vms173003.mailsrvcs.net>; Fri, 04 Jan 2008 07:51:42 -0600 (CST) Date: Fri, 04 Jan 2008 08:54:38 -0500 From: Skip Ford In-reply-to: <20080104110511.S77222@fledge.watson.org> To: Robert Watson Mail-followup-to: Robert Watson , Dag-Erling =?unknown-8bit?B?U23DuHJncmF2?= , freebsd-current@freebsd.org, Jason Evans , Poul-Henning Kamp Message-id: <20080104135438.GA788@menantico.com> MIME-version: 1.0 Content-type: text/plain; charset=unknown-8bit Content-transfer-encoding: 8BIT Content-disposition: inline References: <477C82F0.5060809@freebsd.org> <863ateemw2.fsf@ds4.des.no> <20080104002002.L30578@fledge.watson.org> <86wsqqaqbe.fsf@ds4.des.no> <20080104110511.S77222@fledge.watson.org> User-Agent: Mutt/1.4.2.3i Cc: Dag-Erling =?unknown-8bit?B?U23DuHJncmF2?= , freebsd-current@freebsd.org, Jason Evans , Poul-Henning Kamp Subject: Re: sbrk(2) broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 13:53:37 -0000 Robert Watson wrote: > On Fri, 4 Jan 2008, Dag-Erling Smørgrav wrote: > >Robert Watson writes: > >>The right answer is presumably to introduce a new LIMIT_SWAP, which > >>limits the allocation of anonymous memory by processes, and size it to > >>something like 90% of swap space by default. > > > >Not a good solution on its own. You need a per-process limit as well, > >otherwise a malloc() bomb will still cause other processes to fail > >randomly. > > That was what I had in mind, the above should read RLIMIT_SWAP. Are you referring to the implementation of RLIMIT_SWAP in the overcommit-disable patch at: http://people.freebsd.org/~kib/overcommit/index.html ...or some other as yet unwritten implementation? That patch doesn't currently do 90% of swap but easily can. That's been available for almost 3 years now. I tested it at one point but not lately and it never went into production. Do you, and others, have a problem with that implementation? -- Skip From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 13:59:23 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1BBD816A41A; Fri, 4 Jan 2008 13:59:23 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay02.kiev.sovam.com (relay02.kiev.sovam.com [62.64.120.197]) by mx1.freebsd.org (Postfix) with ESMTP id B2BCE13C4DB; Fri, 4 Jan 2008 13:59:22 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.226] (helo=deviant.kiev.zoral.com.ua) by relay02.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1JAn4r-0001sJ-EW; Fri, 04 Jan 2008 15:59:21 +0200 Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m04DxC5s015102; Fri, 4 Jan 2008 15:59:12 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id m04DxCvY015100; Fri, 4 Jan 2008 15:59:12 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 4 Jan 2008 15:59:12 +0200 From: Kostik Belousov To: Skip Ford Message-ID: <20080104135912.GB57756@deviant.kiev.zoral.com.ua> References: <477C82F0.5060809@freebsd.org> <863ateemw2.fsf@ds4.des.no> <20080104002002.L30578@fledge.watson.org> <86wsqqaqbe.fsf@ds4.des.no> <20080104110511.S77222@fledge.watson.org> <20080104135438.GA788@menantico.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="A/AdVN8FDkvpDdxN" Content-Disposition: inline In-Reply-To: <20080104135438.GA788@menantico.com> User-Agent: Mutt/1.4.2.3i X-Scanner-Signature: 1118cf21f7425d415ed61e91afc5cb63 X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 1976 [Dec 29 2007] X-SpamTest-Info: helo_type=3 X-SpamTest-Info: {received from trusted relay: not dialup} X-SpamTest-Method: none X-SpamTest-Method: Local Lists X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0255], KAS30/Release Cc: Dag-Erling =?koi8-r?B?U23DuHJncmF2?= , freebsd-current@FreeBSD.org, Robert Watson , Jason Evans , Poul-Henning Kamp Subject: Re: sbrk(2) broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 13:59:23 -0000 --A/AdVN8FDkvpDdxN Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 04, 2008 at 08:54:38AM -0500, Skip Ford wrote: > Robert Watson wrote: > > On Fri, 4 Jan 2008, Dag-Erling Sm=F8rgrav wrote: > > >Robert Watson writes: > > >>The right answer is presumably to introduce a new LIMIT_SWAP, which > > >>limits the allocation of anonymous memory by processes, and size it to > > >>something like 90% of swap space by default. > > > > > >Not a good solution on its own. You need a per-process limit as well,= =20 > > >otherwise a malloc() bomb will still cause other processes to fail=20 > > >randomly. > >=20 > > That was what I had in mind, the above should read RLIMIT_SWAP. >=20 > Are you referring to the implementation of RLIMIT_SWAP in the > overcommit-disable patch at: >=20 > http://people.freebsd.org/~kib/overcommit/index.html >=20 > ...or some other as yet unwritten implementation? That patch doesn't > currently do 90% of swap but easily can. That's been available for almos= t 3 > years now. I tested it at one point but not lately and it never went into > production. Do you, and others, have a problem with that implementation? Oh, I thought that I was the sole user of the patch. What problems did you encountered while testing it ? What you mean by "do 90% of swap" ? --A/AdVN8FDkvpDdxN Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHfjuwC3+MBN1Mb4gRAgu6AJ0WRUc3vHQ9y+Xpk70YFOQZLoX+wwCggMq7 MRGydd9Q74RMjOes7k72EdE= =YVBD -----END PGP SIGNATURE----- --A/AdVN8FDkvpDdxN-- From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 14:10:43 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 89CCD16A41A; Fri, 4 Jan 2008 14:10:43 +0000 (UTC) (envelope-from skip@menantico.com) Received: from vms173003pub.verizon.net (vms173003pub.verizon.net [206.46.173.3]) by mx1.freebsd.org (Postfix) with ESMTP id 5F3AC13C43E; Fri, 4 Jan 2008 14:10:43 +0000 (UTC) (envelope-from skip@menantico.com) Received: from mx.menantico.com ([71.168.197.190]) by vms173003.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0JU400H85HYDQQL9@vms173003.mailsrvcs.net>; Fri, 04 Jan 2008 08:08:38 -0600 (CST) Date: Fri, 04 Jan 2008 09:11:33 -0500 From: Skip Ford In-reply-to: <20080104135912.GB57756@deviant.kiev.zoral.com.ua> To: Kostik Belousov Mail-followup-to: Kostik Belousov , Robert Watson , Dag-Erling =?unknown-8bit?B?U23DuHJncmF2?= , freebsd-current@FreeBSD.org, Jason Evans , Poul-Henning Kamp Message-id: <20080104141133.GB788@menantico.com> MIME-version: 1.0 Content-type: text/plain; charset=unknown-8bit Content-transfer-encoding: 8BIT Content-disposition: inline References: <477C82F0.5060809@freebsd.org> <863ateemw2.fsf@ds4.des.no> <20080104002002.L30578@fledge.watson.org> <86wsqqaqbe.fsf@ds4.des.no> <20080104110511.S77222@fledge.watson.org> <20080104135438.GA788@menantico.com> <20080104135912.GB57756@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.4.2.3i Cc: Dag-Erling =?unknown-8bit?B?U23DuHJncmF2?= , freebsd-current@FreeBSD.org, Robert Watson , Jason Evans , Poul-Henning Kamp Subject: Re: sbrk(2) broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 14:10:43 -0000 Kostik Belousov wrote: > On Fri, Jan 04, 2008 at 08:54:38AM -0500, Skip Ford wrote: > > Robert Watson wrote: > > > On Fri, 4 Jan 2008, Dag-Erling Smørgrav wrote: > > > >Robert Watson writes: > > > >>The right answer is presumably to introduce a new LIMIT_SWAP, which > > > >>limits the allocation of anonymous memory by processes, and size it to > > > >>something like 90% of swap space by default. > > > > > > > >Not a good solution on its own. You need a per-process limit as well, > > > >otherwise a malloc() bomb will still cause other processes to fail > > > >randomly. > > > > > > That was what I had in mind, the above should read RLIMIT_SWAP. > > > > Are you referring to the implementation of RLIMIT_SWAP in the > > overcommit-disable patch at: > > > > http://people.freebsd.org/~kib/overcommit/index.html > > > > ...or some other as yet unwritten implementation? That patch doesn't > > currently do 90% of swap but easily can. That's been available for almost 3 > > years now. I tested it at one point but not lately and it never went into > > production. Do you, and others, have a problem with that implementation? > Oh, I thought that I was the sole user of the patch. What problems did you > encountered while testing it ? Nope, there are two of us. :-) I don't remember encountering problems. I never put it into production because maintaining it in a local branch was beyond my ability. I just didn't know enough to know what it did and didn't do, or how it would have to be modified to work with future changes. I just didn't understand it enough to go with it and maintain it. > What you mean by "do 90% of swap" ? I was referring only to what Robert said above, that he thinks RLIMIT_SWAP should limit anon memory size to ~90% of swap by default. Your patch, last I looked, limits it to 100% of swap by design but could be easily changed I think. -- Skip From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 14:12:01 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 42BE116A421 for ; Fri, 4 Jan 2008 14:12:01 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: from hs-out-2122.google.com (hs-out-0708.google.com [64.233.178.251]) by mx1.freebsd.org (Postfix) with ESMTP id DBFE813C4D3 for ; Fri, 4 Jan 2008 14:12:00 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: by hs-out-2122.google.com with SMTP id j58so5219866hsj.11 for ; Fri, 04 Jan 2008 06:12:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=Auo6u/ahvPWQveev1o9Jl5ADa20pxZnwSALscTcreMs=; b=jOo1z1OurCs/LeK7jjBz0UNmO7hMESoALMNFbDNgGVMbC/3A9RxkRMWR2NSL5dPdqBE3XLbi6o9i68XreH1JqjGOdd6yU6p5fni82gjaPRks7Eh8O3fxJWgC+BSFb1QxE7bXFcBc6SsXzaq2Kn15JwIZT0uPUgTZLbNwAaiCtCY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=TVlQR1uT5u9/CpHCeigI4LpfkoS/VOnFiz6cE8nclFh7DgLrLbty9886X4zO4cLExw51aHPp0Ts2yHDPHv2fioGQSmH/t7la+R0GSpY62b6RsNc2zt7ASadUT9sTaIYmYy5Qo7hma1vQi2EPiwM5HXHYJJqM3poyiibQJJ2X0/M= Received: by 10.142.212.19 with SMTP id k19mr5106641wfg.200.1199455911649; Fri, 04 Jan 2008 06:11:51 -0800 (PST) Received: by 10.142.162.20 with HTTP; Fri, 4 Jan 2008 06:11:51 -0800 (PST) Message-ID: Date: Fri, 4 Jan 2008 22:11:51 +0800 From: "Sepherosa Ziehau" To: "=?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?=" In-Reply-To: <86lk76c6t5.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <86ir2hznnd.fsf@ds4.des.no> <86abnpu0wv.fsf@ds4.des.no> <86abnovy4k.fsf@ds4.des.no> <86odc3dlgi.fsf@ds4.des.no> <86lk76c6t5.fsf@ds4.des.no> Cc: kevlo@freebsd.org, sam@freebsd.org, current@freebsd.org, net@freebsd.org Subject: Re: if_ral regression X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 14:12:01 -0000 On Jan 4, 2008 4:51 PM, Dag-Erling Sm=F8rgrav wrote: > "Sepherosa Ziehau" writes: > > Are you also using freebsd as STA too? If yes, would you have time to > > gather following information on the STA side before after and during > > the rsyncing: > > 1) wlandebug -i sta_iface +input > > 2) tcpdump -ni sta_iface -y ieee802_11 -w dump.bin > > I'll have to pull out an old laptop to do that, my current one runs > Ubuntu. Hopefully, I'll have the results for you later today. I > imagine you want to see the output from wlandebug both when the AP is > working and when it is stuck? Yes. I just did some air dump of ral's beacon and data frame A sample ral(4) broadcast beacon frame: 21:26:26.662250 Beacon (sephe-hostap) [1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0 18.0 Mbit] ESS CH: 6 0x0000: 8000 0000 ffff ffff ffff 0015 f2d7 420c 0x0010: 0015 f2d7 420c 0000 e053 4a10 0000 0000 0x0020: 6400 2104 000c 7365 7068 652d 686f 7374 0x0030: 6170 0108 8284 8b96 0c12 1824 0301 0605 0x0040: 0400 0101 002a 0100 3204 3048 606c The seq is 0!! Two sample ral(4) data frames (ICMP echo resps) 21:26:27.810209 IP 192.168.5.2 > 192.168.5.1: ICMP echo request, id 61969, seq 1, length 64 0x0000: 0801 2c00 0015 f2d7 420c 0014 787a 5990 0x0010: 0015 f2d7 420c f0b1 aaaa 0300 0000 0800 0x0020: 4500 0054 0e75 0000 4001 e0e0 c0a8 0502 0x0030: c0a8 0501 0800 42b2 f211 0001 477e 3403 0x0040: 000c 5caa 0809 0a0b 0c0d 0e0f 1011 1213 0x0050: 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 21:26:28.820190 IP 192.168.5.2 > 192.168.5.1: ICMP echo request, id 61969, seq 2, length 64 0x0000: 0801 2c00 0015 f2d7 420c 0014 787a 5990 0x0010: 0015 f2d7 420c 00b2 aaaa 0300 0000 0800 0x0020: 4500 0054 f517 0000 4001 fa3d c0a8 0502 0x0030: c0a8 0501 0800 1bb1 f211 0002 477e 3404 0x0040: 000c 83a9 0809 0a0b 0c0d 0e0f 1011 1213 0x0050: 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 802.11 stack does the right thing here, seq is incremented between two fram= es. This actually brings up two things: 1) I think should ignore seq in multicast frames; this is permitted in 802.11 standard. In dfly I did that, since one of our users encountered a broken commercial AP which is not 802.11e but use different beacon se --=20 Live Free or Die From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 14:12:22 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 70FE616A49C for ; Fri, 4 Jan 2008 14:12:22 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: from hs-out-2122.google.com (hs-out-0708.google.com [64.233.178.251]) by mx1.freebsd.org (Postfix) with ESMTP id 2393B13C46E for ; Fri, 4 Jan 2008 14:12:22 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: by hs-out-2122.google.com with SMTP id j58so5219866hsj.11 for ; Fri, 04 Jan 2008 06:12:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=Auo6u/ahvPWQveev1o9Jl5ADa20pxZnwSALscTcreMs=; b=jOo1z1OurCs/LeK7jjBz0UNmO7hMESoALMNFbDNgGVMbC/3A9RxkRMWR2NSL5dPdqBE3XLbi6o9i68XreH1JqjGOdd6yU6p5fni82gjaPRks7Eh8O3fxJWgC+BSFb1QxE7bXFcBc6SsXzaq2Kn15JwIZT0uPUgTZLbNwAaiCtCY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=TVlQR1uT5u9/CpHCeigI4LpfkoS/VOnFiz6cE8nclFh7DgLrLbty9886X4zO4cLExw51aHPp0Ts2yHDPHv2fioGQSmH/t7la+R0GSpY62b6RsNc2zt7ASadUT9sTaIYmYy5Qo7hma1vQi2EPiwM5HXHYJJqM3poyiibQJJ2X0/M= Received: by 10.142.212.19 with SMTP id k19mr5106641wfg.200.1199455911649; Fri, 04 Jan 2008 06:11:51 -0800 (PST) Received: by 10.142.162.20 with HTTP; Fri, 4 Jan 2008 06:11:51 -0800 (PST) Message-ID: Date: Fri, 4 Jan 2008 22:11:51 +0800 From: "Sepherosa Ziehau" To: "=?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?=" In-Reply-To: <86lk76c6t5.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <86ir2hznnd.fsf@ds4.des.no> <86abnpu0wv.fsf@ds4.des.no> <86abnovy4k.fsf@ds4.des.no> <86odc3dlgi.fsf@ds4.des.no> <86lk76c6t5.fsf@ds4.des.no> Cc: kevlo@freebsd.org, sam@freebsd.org, current@freebsd.org, net@freebsd.org Subject: Re: if_ral regression X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 14:12:22 -0000 On Jan 4, 2008 4:51 PM, Dag-Erling Sm=F8rgrav wrote: > "Sepherosa Ziehau" writes: > > Are you also using freebsd as STA too? If yes, would you have time to > > gather following information on the STA side before after and during > > the rsyncing: > > 1) wlandebug -i sta_iface +input > > 2) tcpdump -ni sta_iface -y ieee802_11 -w dump.bin > > I'll have to pull out an old laptop to do that, my current one runs > Ubuntu. Hopefully, I'll have the results for you later today. I > imagine you want to see the output from wlandebug both when the AP is > working and when it is stuck? Yes. I just did some air dump of ral's beacon and data frame A sample ral(4) broadcast beacon frame: 21:26:26.662250 Beacon (sephe-hostap) [1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0 18.0 Mbit] ESS CH: 6 0x0000: 8000 0000 ffff ffff ffff 0015 f2d7 420c 0x0010: 0015 f2d7 420c 0000 e053 4a10 0000 0000 0x0020: 6400 2104 000c 7365 7068 652d 686f 7374 0x0030: 6170 0108 8284 8b96 0c12 1824 0301 0605 0x0040: 0400 0101 002a 0100 3204 3048 606c The seq is 0!! Two sample ral(4) data frames (ICMP echo resps) 21:26:27.810209 IP 192.168.5.2 > 192.168.5.1: ICMP echo request, id 61969, seq 1, length 64 0x0000: 0801 2c00 0015 f2d7 420c 0014 787a 5990 0x0010: 0015 f2d7 420c f0b1 aaaa 0300 0000 0800 0x0020: 4500 0054 0e75 0000 4001 e0e0 c0a8 0502 0x0030: c0a8 0501 0800 42b2 f211 0001 477e 3403 0x0040: 000c 5caa 0809 0a0b 0c0d 0e0f 1011 1213 0x0050: 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 21:26:28.820190 IP 192.168.5.2 > 192.168.5.1: ICMP echo request, id 61969, seq 2, length 64 0x0000: 0801 2c00 0015 f2d7 420c 0014 787a 5990 0x0010: 0015 f2d7 420c 00b2 aaaa 0300 0000 0800 0x0020: 4500 0054 f517 0000 4001 fa3d c0a8 0502 0x0030: c0a8 0501 0800 1bb1 f211 0002 477e 3404 0x0040: 000c 83a9 0809 0a0b 0c0d 0e0f 1011 1213 0x0050: 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 802.11 stack does the right thing here, seq is incremented between two fram= es. This actually brings up two things: 1) I think should ignore seq in multicast frames; this is permitted in 802.11 standard. In dfly I did that, since one of our users encountered a broken commercial AP which is not 802.11e but use different beacon se --=20 Live Free or Die From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 14:19:08 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5942F16A41B; Fri, 4 Jan 2008 14:19:08 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay02.kiev.sovam.com (relay02.kiev.sovam.com [62.64.120.197]) by mx1.freebsd.org (Postfix) with ESMTP id DED7513C44B; Fri, 4 Jan 2008 14:19:07 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.226] (helo=deviant.kiev.zoral.com.ua) by relay02.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1JAnNy-0007MZ-IZ; Fri, 04 Jan 2008 16:19:07 +0200 Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m04EIwp7040266; Fri, 4 Jan 2008 16:18:58 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id m04EIwWm040265; Fri, 4 Jan 2008 16:18:58 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 4 Jan 2008 16:18:57 +0200 From: Kostik Belousov To: Skip Ford Message-ID: <20080104141857.GC57756@deviant.kiev.zoral.com.ua> References: <477C82F0.5060809@freebsd.org> <863ateemw2.fsf@ds4.des.no> <20080104002002.L30578@fledge.watson.org> <86wsqqaqbe.fsf@ds4.des.no> <20080104110511.S77222@fledge.watson.org> <20080104135438.GA788@menantico.com> <20080104135912.GB57756@deviant.kiev.zoral.com.ua> <20080104141133.GB788@menantico.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="h8+hH1OQkST14sOt" Content-Disposition: inline In-Reply-To: <20080104141133.GB788@menantico.com> User-Agent: Mutt/1.4.2.3i X-Scanner-Signature: 717fb1dce93df3d9117221529acf11a8 X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 1976 [Dec 29 2007] X-SpamTest-Info: helo_type=3 X-SpamTest-Info: {received from trusted relay: not dialup} X-SpamTest-Method: none X-SpamTest-Method: Local Lists X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0255], KAS30/Release Cc: Dag-Erling =?koi8-r?B?U23DuHJncmF2?= , freebsd-current@FreeBSD.org, Robert Watson , Jason Evans , Poul-Henning Kamp Subject: Re: sbrk(2) broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 14:19:08 -0000 --h8+hH1OQkST14sOt Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 04, 2008 at 09:11:33AM -0500, Skip Ford wrote: > Kostik Belousov wrote: > > On Fri, Jan 04, 2008 at 08:54:38AM -0500, Skip Ford wrote: > > > Robert Watson wrote: > > > > On Fri, 4 Jan 2008, Dag-Erling Sm=F8rgrav wrote: > > > > >Robert Watson writes: > > > > >>The right answer is presumably to introduce a new LIMIT_SWAP, whi= ch > > > > >>limits the allocation of anonymous memory by processes, and size = it to > > > > >>something like 90% of swap space by default. > > > > > > > > > >Not a good solution on its own. You need a per-process limit as w= ell,=20 > > > > >otherwise a malloc() bomb will still cause other processes to fail= =20 > > > > >randomly. > > > >=20 > > > > That was what I had in mind, the above should read RLIMIT_SWAP. > > >=20 > > > Are you referring to the implementation of RLIMIT_SWAP in the > > > overcommit-disable patch at: > > >=20 > > > http://people.freebsd.org/~kib/overcommit/index.html > > >=20 > > > ...or some other as yet unwritten implementation? That patch doesn't > > > currently do 90% of swap but easily can. That's been available for a= lmost 3 > > > years now. I tested it at one point but not lately and it never went= into > > > production. Do you, and others, have a problem with that implementat= ion? > > Oh, I thought that I was the sole user of the patch. What problems did = you > > encountered while testing it ? >=20 > Nope, there are two of us. :-) >=20 > I don't remember encountering problems. I never put it into production > because maintaining it in a local branch was beyond my ability. I just d= idn't > know enough to know what it did and didn't do, or how it would have to be > modified to work with future changes. I just didn't understand it enough > to go with it and maintain it. >=20 > > What you mean by "do 90% of swap" ? >=20 > I was referring only to what Robert said above, that he thinks RLIMIT_SWAP > should limit anon memory size to ~90% of swap by default. Your patch, > last I looked, limits it to 100% of swap by design but could be easily > changed I think. Ok. The patch really imposes two kind of limits: - the total amount of anon memory that could be allocated in the whole system (this is what I called "disabling overcommit") - per-user RLIMIT_SWAP limit, that account the allocation by the uid. This has some obvious problems with setuid(2) syscall. AFAIR, I ended up not moving the accounted numbers to the new uid. Both limits can be turned on/off independently. May be, time to revive it. --h8+hH1OQkST14sOt Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHfkBRC3+MBN1Mb4gRAuIKAKCqu7wKHFsS4zsrOKezEd6DeYQ0mgCfRwAV UjCx3JJfxU6zL01EJ5Iq4/s= =tHbx -----END PGP SIGNATURE----- --h8+hH1OQkST14sOt-- From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 14:20:50 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 51C5416A419 for ; Fri, 4 Jan 2008 14:20:50 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.238]) by mx1.freebsd.org (Postfix) with ESMTP id 017BD13C4D9 for ; Fri, 4 Jan 2008 14:20:49 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: by nz-out-0506.google.com with SMTP id l8so1268944nzf.13 for ; Fri, 04 Jan 2008 06:20:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=XUfzhWiPvibjl+4pAvSRIATeeuY/MnHnU5BJGFvoC3M=; b=a295olCP04njz6P9VIj2XP+1jbzu+rxJ23TWLoUDdiQHP1nRC5jherzz3QFq/Lg71wkEdkeI9shu8Q9exUuYUr4AvCBjWOpSiwJbgbPTR4CS2xIr73UmQAc3fTvEFIGE16aXGJPb0aLd6CjJV+jwzf3S9swFUXFAQuroVvCxq2Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=lXQE/E+TI1OtONwhvPsjyV9h5ioYteQj4h6qOEP1i0bB4qAVssIdRL3kzcMpauWRrqjSIyZEpwnCRbO2PZrJPFb9rH7hbNIpqc+n8pOBQ3Oubi601KOlnDX3+sWWePh5Iu1j8Eu5Qr7tGmSGeQfbhQ0gFeYWwExkc7jjQWezjvE= Received: by 10.143.173.2 with SMTP id a2mr1241885wfp.168.1199456448741; Fri, 04 Jan 2008 06:20:48 -0800 (PST) Received: by 10.142.162.20 with HTTP; Fri, 4 Jan 2008 06:20:48 -0800 (PST) Message-ID: Date: Fri, 4 Jan 2008 22:20:48 +0800 From: "Sepherosa Ziehau" To: "=?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?=" In-Reply-To: <86lk76c6t5.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <86ir2hznnd.fsf@ds4.des.no> <86abnpu0wv.fsf@ds4.des.no> <86abnovy4k.fsf@ds4.des.no> <86odc3dlgi.fsf@ds4.des.no> <86lk76c6t5.fsf@ds4.des.no> Cc: kevlo@freebsd.org, sam@freebsd.org, current@freebsd.org, net@freebsd.org Subject: Re: if_ral regression X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 14:20:50 -0000 On Jan 4, 2008 4:51 PM, Dag-Erling Sm=F8rgrav wrote: > "Sepherosa Ziehau" writes: > > Are you also using freebsd as STA too? If yes, would you have time to > > gather following information on the STA side before after and during > > the rsyncing: > > 1) wlandebug -i sta_iface +input > > 2) tcpdump -ni sta_iface -y ieee802_11 -w dump.bin > > I'll have to pull out an old laptop to do that, my current one runs > Ubuntu. Hopefully, I'll have the results for you later today. I > imagine you want to see the output from wlandebug both when the AP is > working and when it is stuck? > > DES > -- > > Dag-Erling Sm=F8rgrav - des@des.no > Grr, keyboard mis-fire :P Yes. I just did some air dump of ral's beacon and data frame A sample ral(4) broadcast beacon frame: 21:26:26.662250 Beacon (sephe-hostap) [1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0 18.0 Mbit] ESS CH: 6 0x0000: 8000 0000 ffff ffff ffff 0015 f2d7 420c 0x0010: 0015 f2d7 420c 0000 e053 4a10 0000 0000 0x0020: 6400 2104 000c 7365 7068 652d 686f 7374 0x0030: 6170 0108 8284 8b96 0c12 1824 0301 0605 0x0040: 0400 0101 002a 0100 3204 3048 606c The seq is 0!! Two sample ral(4) data frames (ICMP echo resps) 21:26:27.810209 IP 192.168.5.2 > 192.168.5.1: ICMP echo request, id 61969, seq 1, length 64 0x0000: 0801 2c00 0015 f2d7 420c 0014 787a 5990 0x0010: 0015 f2d7 420c f0b1 aaaa 0300 0000 0800 0x0020: 4500 0054 0e75 0000 4001 e0e0 c0a8 0502 0x0030: c0a8 0501 0800 42b2 f211 0001 477e 3403 0x0040: 000c 5caa 0809 0a0b 0c0d 0e0f 1011 1213 0x0050: 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 21:26:28.820190 IP 192.168.5.2 > 192.168.5.1: ICMP echo request, id 61969, seq 2, length 64 0x0000: 0801 2c00 0015 f2d7 420c 0014 787a 5990 0x0010: 0015 f2d7 420c 00b2 aaaa 0300 0000 0800 0x0020: 4500 0054 f517 0000 4001 fa3d c0a8 0502 0x0030: c0a8 0501 0800 1bb1 f211 0002 477e 3404 0x0040: 000c 83a9 0809 0a0b 0c0d 0e0f 1011 1213 0x0050: 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 802.11 stack does the right thing here, seq is incremented between two fram= es. This actually brings up two things: 1) I think we should ignore seq in multicast frames; this is permitted in 802.11 standard. In dfly I did that, since one of our users encountered a broken commercial AP which is not 802.11e but uses different seq for data and beacon. 2) TX sequence. I think standards only mention QSTA/nQSTA, but not AP. Currently our AP uses per node TX seq, which means beacon's seq is difficult to choose, at least for 2560 based ral(4), whose beacons' seq need to be set by software. I saw Linksys AP uses one seq for all of the frames it sends. Sam, what's you opinion on this? I think if STA counts ral(4)'s beacon seq, as what we do currently, beacon missing will quickly happen since beacons will be discarded after first several data frames. Best Regards, sephe --=20 Live Free or Die From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 14:22:28 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C949B16A41B for ; Fri, 4 Jan 2008 14:22:28 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id 41E8A13C457 for ; Fri, 4 Jan 2008 14:22:27 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.14.2/8.14.2) with ESMTP id m04EMQBv018841 for ; Fri, 4 Jan 2008 17:22:27 +0300 (MSK) (envelope-from ache@nagual.pp.ru) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nagual.pp.ru; s=default; t=1199456547; bh=E+L7PVgXtpLBHXl6Qfuh+Edkk06i/ApaXUuaCg1 xlrs=; l=1291; h=Date:From:To:Subject:Message-ID:Mail-Followup-To: References:MIME-Version:Content-Type:Content-Disposition: In-Reply-To:User-Agent; b=TePzR9U5leHB48e4l8BkbXpPt/a9y0IEhACqCtRS nRkU/iMZ9J9prroUVK+MQqfaEOl857wepmgDiDmKRgDkf6t0Q5yNiEudmdxl+Y+GS4m PZdiLTQ1aHTn5n9qPVzm7PjKyhR2uC5MWlTl9F8UtNyUVQEF3A4VbUVfrOpfU0D8= Received: (from ache@localhost) by nagual.pp.ru (8.14.2/8.14.2/Submit) id m04EMQbO018840 for freebsd-current@FreeBSD.ORG; Fri, 4 Jan 2008 17:22:26 +0300 (MSK) (envelope-from ache) Date: Fri, 4 Jan 2008 17:22:26 +0300 From: Andrey Chernov To: freebsd-current@FreeBSD.ORG Message-ID: <20080104142226.GA18773@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , freebsd-current@FreeBSD.ORG References: <20080104122149.GA17103@nagual.pp.ru> <5705.1199451431@critter.freebsd.dk> <20080104131247.GA17816@nagual.pp.ru> <20080104132545.GA51075@outcold.yadt.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080104132545.GA51075@outcold.yadt.co.uk> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: Subject: Re: sbrk(2) broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 14:22:28 -0000 On Fri, Jan 04, 2008 at 01:25:45PM +0000, David Taylor wrote: > On Fri, 04 Jan 2008, Andrey Chernov wrote: > > > On Fri, Jan 04, 2008 at 12:57:11PM +0000, Poul-Henning Kamp wrote: > > > There is address space allocated to the process (via sbrk/mmap) > > > > > > A subset of this, is address space allocated by the program (via malloc) > > > > > > ...and then there is memory actually in use, which is an entirely different > > > thing, of which we currently only have some kind of clue in the VM > > > system. > > > > Then, we need sysctl to fetch that "memory actually in use" from the > > kernel and compare that with getrlimit() which allows malloc() to return > > 0 when needed. > > That won't help much -- malloc could have allocated some address space that > hasn't (yet) been touched by the process. Just returning 0 when the > amount of memory "in use" hits a limit wouldn't stop the process from > then touching all the memory it has previously been allocated and > exceeding the limit. In that case the process is subject to be killed by system, if exceeds its limits. But... this is not malloc() problem at all, malloc() designed to detect overflow situation, not prevent it. The malloc() problem is not returning 0. -- http://ache.pp.ru/ From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 14:57:22 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 491DF16A418; Fri, 4 Jan 2008 14:57:22 +0000 (UTC) (envelope-from skip@menantico.com) Received: from vms040pub.verizon.net (vms040pub.verizon.net [206.46.252.40]) by mx1.freebsd.org (Postfix) with ESMTP id 2221F13C461; Fri, 4 Jan 2008 14:57:22 +0000 (UTC) (envelope-from skip@menantico.com) Received: from mx.menantico.com ([71.168.197.190]) by vms040.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0JU400IOZK8YJB05@vms040.mailsrvcs.net>; Fri, 04 Jan 2008 08:58:10 -0600 (CST) Date: Fri, 04 Jan 2008 09:58:07 -0500 From: Skip Ford In-reply-to: <20080104141857.GC57756@deviant.kiev.zoral.com.ua> To: Kostik Belousov Mail-followup-to: Kostik Belousov , Robert Watson , Dag-Erling =?unknown-8bit?B?U23DuHJncmF2?= , freebsd-current@FreeBSD.org, Jason Evans , Poul-Henning Kamp Message-id: <20080104145807.GC788@menantico.com> MIME-version: 1.0 Content-type: text/plain; charset=unknown-8bit Content-transfer-encoding: 8BIT Content-disposition: inline References: <477C82F0.5060809@freebsd.org> <863ateemw2.fsf@ds4.des.no> <20080104002002.L30578@fledge.watson.org> <86wsqqaqbe.fsf@ds4.des.no> <20080104110511.S77222@fledge.watson.org> <20080104135438.GA788@menantico.com> <20080104135912.GB57756@deviant.kiev.zoral.com.ua> <20080104141133.GB788@menantico.com> <20080104141857.GC57756@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.4.2.3i Cc: Dag-Erling =?unknown-8bit?B?U23DuHJncmF2?= , freebsd-current@FreeBSD.org, Robert Watson , Jason Evans , Poul-Henning Kamp Subject: Re: sbrk(2) broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 14:57:22 -0000 Kostik Belousov wrote: > On Fri, Jan 04, 2008 at 09:11:33AM -0500, Skip Ford wrote: > > Kostik Belousov wrote: > > > On Fri, Jan 04, 2008 at 08:54:38AM -0500, Skip Ford wrote: > > > > Robert Watson wrote: > > > > > On Fri, 4 Jan 2008, Dag-Erling Smørgrav wrote: > > > > > >Robert Watson writes: > > > > > >>The right answer is presumably to introduce a new LIMIT_SWAP, which > > > > > >>limits the allocation of anonymous memory by processes, and size it to > > > > > >>something like 90% of swap space by default. > > > > > > > > > > > >Not a good solution on its own. You need a per-process limit as well, > > > > > >otherwise a malloc() bomb will still cause other processes to fail > > > > > >randomly. > > > > > > > > > > That was what I had in mind, the above should read RLIMIT_SWAP. > > > > > > > > Are you referring to the implementation of RLIMIT_SWAP in the > > > > overcommit-disable patch at: > > > > > > > > http://people.freebsd.org/~kib/overcommit/index.html > > > > > > > > ...or some other as yet unwritten implementation? That patch doesn't > > > > currently do 90% of swap but easily can. That's been available for almost 3 > > > > years now. I tested it at one point but not lately and it never went into > > > > production. Do you, and others, have a problem with that implementation? > > > > > What you mean by "do 90% of swap" ? > > > > I was referring only to what Robert said above, that he thinks RLIMIT_SWAP > > should limit anon memory size to ~90% of swap by default. Your patch, > > last I looked, limits it to 100% of swap by design but could be easily > > changed I think. > > Ok. The patch really imposes two kind of limits: > - the total amount of anon memory that could be allocated in the whole > system (this is what I called "disabling overcommit") > - per-user RLIMIT_SWAP limit, that account the allocation by the uid. This > has some obvious problems with setuid(2) syscall. AFAIR, I ended up > not moving the accounted numbers to the new uid. > > Both limits can be turned on/off independently. Independently, but using the same sysctl knob which seems a bit awkward. > May be, time to revive it. The concensus in this thread seems to be that a per-process limit needs to be implemented rather than, or in addition to, the per-uid limit you already have. -- Skip From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 15:08:20 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F125E16A419 for ; Fri, 4 Jan 2008 15:08:20 +0000 (UTC) (envelope-from vadimnuclight@tpu.ru) Received: from relay1.tpu.ru (relay1.tpu.ru [213.183.112.102]) by mx1.freebsd.org (Postfix) with ESMTP id 40C5A13C478 for ; Fri, 4 Jan 2008 15:08:20 +0000 (UTC) (envelope-from vadimnuclight@tpu.ru) Received: from localhost (localhost.localdomain [127.0.0.1]) by relay1.tpu.ru (Postfix) with ESMTP id 9FE11104677 for ; Fri, 4 Jan 2008 21:08:18 +0600 (NOVT) X-Virus-Scanned: amavisd-new at tpu.ru Received: from relay1.tpu.ru ([127.0.0.1]) by localhost (relay1.tpu.ru [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lb93gKFq3U3n for ; Fri, 4 Jan 2008 21:08:15 +0600 (NOVT) Received: from mail.main.tpu.ru (mail.main.tpu.ru [10.0.0.3]) by relay1.tpu.ru (Postfix) with ESMTP id B5C5A104669 for ; Fri, 4 Jan 2008 21:08:15 +0600 (NOVT) Received: from mail.tpu.ru ([213.183.112.105]) by mail.main.tpu.ru with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Jan 2008 21:08:15 +0600 Received: from nuclight.avtf.net ([78.140.2.250]) by mail.tpu.ru over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Jan 2008 21:08:14 +0600 Date: Fri, 04 Jan 2008 21:08:12 +0600 To: "freebsd-current@freebsd.org" From: "Vadim Goncharov" Organization: AVTF TPU Hostel Content-Type: text/plain; format=flowed; delsp=yes; charset=koi8-r MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: User-Agent: Opera M2/7.54 (Win32, build 3865) X-OriginalArrivalTime: 04 Jan 2008 15:08:15.0715 (UTC) FILETIME=[A1AE3330:01C84EE3] X-Mailman-Approved-At: Fri, 04 Jan 2008 15:16:43 +0000 Subject: sbrk(2), OOM-killer and malloc() overcommit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 15:08:21 -0000 Hi, There were talks in 'sbrk(2) broken' thread about memory hogs which can easily eat all available VM despite of resources. That'smust be fixed or it will make a bad reputation for FreeBSD as a server platform. But there are related "bug", in that of malloc overcommit, which can be demonstrated by this short program (if no resource limits are present, you'll see): #include /* http://alter.tomsk.ru/bugs/head/ */ /* (C) Vladimir */ /* alter at alter tom ru */ int main(int argc, char **argv){ #define MB 1048576 const size_t step = MB; size_t size = (size_t) 4095 * MB; char *p; printf("%s $Rev: 54 $\n", argv[0]); printf("start size = %u MiB, step = %uMiB\n", size / MB, step / MB); for(;size;){ p = (char *)malloc(size); if(p){ printf("allocated %u MiB\n", size / MB); puts("calling bzero()..."); puts("NEXT MESSAGE SHOULD BE \"*** OK ***\", ELSE - THERE IS BUG IN A KERNEL"); bzero(p, size); puts("*** OK *** Seems this OS doesn't contain the bug!"); return(0); } else { size -= step; } } return(0); } There are people with long-running data-mining big processes that blame FreeBSD for being "not serious for serious server tasks" due to this bug, because other systems allow for some kind of memory reserving from additional files or other overcommit tuning (Linux has overcommit probability reducing tunable, which is enough for most such tasks). I know there exists a patch (which was again mentioned in thread), http://people.freebsd.org/~kib/overcommit/index.html - but it has never gone into src tree. So why we still have this problem, why not have at least this patch?.. -- WBR, Vadim Goncharov From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 16:33:54 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 78EBC16A419; Fri, 4 Jan 2008 16:33:54 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (cl-162.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:a1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 11F9E13C44B; Fri, 4 Jan 2008 16:33:53 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.1/8.13.8) with ESMTP id m04GXrOh043331; Fri, 4 Jan 2008 10:33:53 -0600 (CST) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.1/8.13.8/Submit) id m04GXriW043330; Fri, 4 Jan 2008 10:33:53 -0600 (CST) (envelope-from brooks) Date: Fri, 4 Jan 2008 10:33:52 -0600 From: Brooks Davis To: Ivan Voras Message-ID: <20080104163352.GA42835@lor.one-eyed-alien.net> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7AUc2qLy4jB3hD7Z" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.16 (2007-06-09) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (lor.one-eyed-alien.net [127.0.0.1]); Fri, 04 Jan 2008 10:33:53 -0600 (CST) Cc: freebsd-current@freebsd.org Subject: Re: When will ZFS become stable? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 16:33:54 -0000 --7AUc2qLy4jB3hD7Z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 04, 2008 at 12:42:28PM +0100, Ivan Voras wrote: > Hi, >=20 > As far as I know about the details of implementation and what would it > take to fix the problems, is it safe to assume ZFS will never become > stable during 7.x lifetime? I suppose that depends what you mean by stable. It seems stable enough for a number of applications today. It's clearly not widely tested since we haven't shipped a release based on it. It's possible some of the issues of memory requirements won't be fixable in 7.x, but I don't think that's a given. -- Brooks --7AUc2qLy4jB3hD7Z Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFHfl/wXY6L6fI4GtQRApPDAKCGkc8LaMwoXoLwJNyY1raKCzGspgCff8J2 rlec38tZCAW9t3DN+iUbups= =qcei -----END PGP SIGNATURE----- --7AUc2qLy4jB3hD7Z-- From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 17:46:06 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DB61A16A420 for ; Fri, 4 Jan 2008 17:46:06 +0000 (UTC) (envelope-from merlyn500@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.184]) by mx1.freebsd.org (Postfix) with ESMTP id 22D5B13C447 for ; Fri, 4 Jan 2008 17:46:05 +0000 (UTC) (envelope-from merlyn500@gmail.com) Received: by nf-out-0910.google.com with SMTP id b2so571552nfb.33 for ; Fri, 04 Jan 2008 09:46:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date:user-agent:mime-version:content-type:content-transfer-encoding:content-disposition:message-id; bh=eGjFxgMe+sQsgVF/cCjizHxHD629HbKrToHNsy/1kEI=; b=iXw/dctAOEUopPUYCWJzAPDJTve/7+vQ6FunELVkNAIz7KZCGwhrtASM3tgxlRCZGtP5WBtQbhjvgzuiRtacy+k+UKzZI+3/HSGt+tm9ZwwriImvxuaetXyBPA1kSSWNz6mCmK+GV4/tb0ECIexepzsMxFyethIibK3RDcZFt8w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:mime-version:content-type:content-transfer-encoding:content-disposition:message-id; b=k4cVfZqg23+PE5X6b+XXiDy5f9Q8K1+pdywl6TeLKdQMqWTQ+YoHiLf8sqBCP6yE/57RdARVZmMfPxF8EN83wIn9cwQ7FinaPKSjKecaWJLt6nM+r07+7GjBeUwEbfebs3oezjc4qsyWOnFwNsytHX5B4V4Zrq27Tr7QOfO+p+8= Received: by 10.78.204.7 with SMTP id b7mr19959081hug.74.1199467047417; Fri, 04 Jan 2008 09:17:27 -0800 (PST) Received: from ?192.168.1.3? ( [85.207.232.114]) by mx.google.com with ESMTPS id k9sm1290709nfh.39.2008.01.04.09.17.25 (version=SSLv3 cipher=OTHER); Fri, 04 Jan 2008 09:17:26 -0800 (PST) From: Milan Bartos To: freebsd-current@freebsd.org Date: Fri, 4 Jan 2008 18:16:08 +0100 User-Agent: KMail/1.9.7 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200801041816.09716.merlyn500@gmail.com> Subject: Ati driver xorg 1.4, works badly X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 17:46:06 -0000 Hi, i have problem with ati mobility radeon 9600 graphic card. With vesa driver works OK, but with ati or radeon driver, 3d acceletarion does not work (with Xorg 6.9 worked). I am now using Xorg xorg-server-1.4_3,1. xvinfo: X-Video Extension version 2.2 screen #0 Adaptor #0: "ATI Radeon Video Overlay" number of ports: 1 port base: 73 operations supported: PutImage supported visuals: depth 24, visualID 0x23 depth 24, visualID 0x24 depth 24, visualID 0x25 depth 24, visualID 0x26 depth 24, visualID 0x27 depth 24, visualID 0x28 depth 24, visualID 0x29 depth 24, visualID 0x2a depth 24, visualID 0x2b depth 24, visualID 0x2c depth 24, visualID 0x2d depth 24, visualID 0x2e depth 24, visualID 0x2f depth 24, visualID 0x30 depth 24, visualID 0x31 depth 24, visualID 0x32 number of attributes: 22 "XV_DEVICE_ID" (range 0 to -1) client gettable attribute (current value is 109) "XV_LOCATION_ID" (range 0 to -1) client gettable attribute (current value is 110) "XV_INSTANCE_ID" (range 0 to -1) client gettable attribute (current value is 111) "XV_DUMP_STATUS" (range 0 to 1) client settable attribute "XV_SET_DEFAULTS" (range 0 to 1) client settable attribute "XV_AUTOPAINT_COLORKEY" (range 0 to 1) client settable attribute client gettable attribute (current value is 1) "XV_COLORKEY" (range 0 to -1) client settable attribute client gettable attribute (current value is 30) "XV_DOUBLE_BUFFER" (range 0 to 1) client settable attribute client gettable attribute (current value is 1) "XV_OVERLAY_ALPHA" (range 0 to 255) client settable attribute client gettable attribute (current value is 255) "XV_GRAPHICS_ALPHA" (range 0 to 255) client settable attribute client gettable attribute (current value is 255) "XV_ALPHA_MODE" (range 0 to 1) client settable attribute client gettable attribute (current value is 0) "XV_BRIGHTNESS" (range -1000 to 1000) client settable attribute client gettable attribute (current value is 0) "XV_CONTRAST" (range -1000 to 1000) client settable attribute client gettable attribute (current value is 0) "XV_SATURATION" (range -1000 to 1000) client settable attribute client gettable attribute (current value is 0) "XV_COLOR" (range -1000 to 1000) client settable attribute client gettable attribute (current value is 0) "XV_HUE" (range -1000 to 1000) client settable attribute client gettable attribute (current value is 0) "XV_RED_INTENSITY" (range -1000 to 1000) client settable attribute client gettable attribute (current value is 0) "XV_GREEN_INTENSITY" (range -1000 to 1000) client settable attribute client gettable attribute (current value is 0) "XV_BLUE_INTENSITY" (range -1000 to 1000) client settable attribute client gettable attribute (current value is 0) "XV_CRTC" (range -1 to 1) client settable attribute client gettable attribute (current value is -1) "XV_GAMMA" (range 100 to 10000) client settable attribute client gettable attribute (current value is 1000) "XV_COLORSPACE" (range 0 to 1) client settable attribute client gettable attribute (current value is 0) maximum XvImage size: 2048 x 2048 Number of image formats: 8 id: 0x41424752 (RGBA) guid: 52474241-0000-0010-8000-00aa00389b71 bits per pixel: 32 number of planes: 1 type: RGB (packed) depth: 32 red, green, blue masks: 0xff0000, 0xff00, 0xff id: 0x0 guid: 52474200-0000-0010-8000-00aa00389b71 bits per pixel: 24 number of planes: 1 type: RGB (packed) depth: 24 red, green, blue masks: 0xff0000, 0xff00, 0xff id: 0x54424752 (RGBT) guid: 52474254-0000-0010-8000-00aa00389b71 bits per pixel: 16 number of planes: 1 type: RGB (packed) depth: 16 red, green, blue masks: 0x7c00, 0x3e0, 0x1f id: 0x32424752 (RGB2) guid: 52474200-0000-0010-8000-00aa00389b71 bits per pixel: 16 number of planes: 1 type: RGB (packed) depth: 16 red, green, blue masks: 0xf800, 0x7e0, 0x1f id: 0x32595559 (YUY2) guid: 59555932-0000-0010-8000-00aa00389b71 bits per pixel: 16 number of planes: 1 type: YUV (packed) id: 0x59565955 (UYVY) guid: 55595659-0000-0010-8000-00aa00389b71 bits per pixel: 16 number of planes: 1 type: YUV (packed) id: 0x32315659 (YV12) guid: 59563132-0000-0010-8000-00aa00389b71 bits per pixel: 12 number of planes: 3 type: YUV (planar) id: 0x30323449 (I420) guid: 49343230-0000-0010-8000-00aa00389b71 bits per pixel: 12 number of planes: 3 type: YUV (planar) dmesg: Copyright (c) 1992-2008 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 is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-CURRENT #8: Tue Jan 1 19:19:22 CET 2008 merlyn@Vallhala:/usr/obj/usr/src/sys/GENERIC WARNING: WITNESS option enabled, expect reduced performance. module_register: module pci/ichss_pci already exists! Module pci/ichss_pci failed to register: 17 module_register: module cpu/ichss already exists! Module cpu/ichss failed to register: 17 module_register: module cpu/est already exists! Module cpu/est failed to register: 17 module_register: module cpu/p4tcc already exists! Module cpu/p4tcc failed to register: 17 module_register: module cpu/powernow already exists! Module cpu/powernow failed to register: 17 module_register: module cpu/smist already exists! Module cpu/smist failed to register: 17 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) M processor 1.70GHz (598.06-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6d6 Stepping = 6 Features=0xafe9f9bf Features2=0x180 real memory = 536281088 (511 MB) avail memory = 511008768 (487 MB) kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) hptrr: HPT RocketRAID controller driver v1.1 (Jan 1 2008 19:19:00) acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 cpu0: on acpi0 est0: on cpu0 p4tcc0: on cpu0 acpi_acad0: on acpi0 battery0: on acpi0 acpi_lid0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci_link3: BIOS IRQ 11 for 0.29.INTB is invalid pci0: on pcib0 agp0: on hostb0 pcib1: at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0x3000-0x30ff mem 0xd8000000-0xdfffffff,0xd0100000-0xd010ffff irq 11 at device 0.0 on pci1 uhci0: port 0x1800-0x181f irq 11 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0x1820-0x183f irq 10 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0x1840-0x185f irq 11 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered ehci0: mem 0xd0000000-0xd00003ff irq 10 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb3: EHCI version 1.0 usb3: companion controllers, 2 ports each: usb0 usb1 usb2 usb3: on ehci0 usb3: USB revision 2.0 uhub3: on usb3 uhub3: 6 ports with 6 removable, self powered pcib2: at device 30.0 on pci0 pci_link3: BIOS IRQ 11 for 2.5.INTA is invalid pci2: on pcib2 bfe0: mem 0xd0200000-0xd0201fff irq 10 at device 5.0 on pci2 miibus0: on bfe0 bmtphy0: PHY 1 on miibus0 bmtphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto bfe0: using obsoleted if_watchdog interface bfe0: Ethernet address: 00:0a:e4:b6:20:82 bfe0: [ITHREAD] pci2: at device 6.0 (no driver attached) cbb0: at device 9.0 on pci2 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 cbb0: [ITHREAD] cbb1: irq 10 at device 9.1 on pci2 cardbus1: on cbb1 pccard1: <16-bit PCCard bus> on cbb1 cbb1: [ITHREAD] fwohci0: mem 0xd0203000-0xd02037ff irq 11 at device 9.2 on pci2 fwohci0: [FILTER] fwohci0: OHCI version 1.0 (ROM=0) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 06:e4:0a:00:69:4f:10:03 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: 06:e4:0a:4f:10:03 fwe0: Ethernet address: 06:e4:0a:4f:10:03 fwip0: on firewire0 fwip0: Firewire address: 06:e4:0a:00:69:4f:10:03 @ 0xfffe00000000, S400, maxrec 2048 sbp0: on firewire0 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0x12b0000 fwohci0: Initiate bus reset fwohci0: BUS reset fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1860-0x186f at device 31.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] pci0: at device 31.3 (no driver attached) pcm0: port 0x1c00-0x1cff,0x18c0-0x18ff mem 0xd0000c00-0xd0000dff,0xd0000800-0xd00008ff irq 10 at device 31.5 on pci0 pcm0: [ITHREAD] pcm0: pci0: at device 31.6 (no driver attached) acpi_tz0: on acpi0 acpi_tz1: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model Generic PS/2 mouse, device ID 0 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcffff,0xd0000-0xd0fff,0xd8000-0xdbfff,0xdc000-0xdffff pnpid ORM0000 on isa0 ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppbus0: on ppc0 plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 ppc0: [GIANT-LOCKED] ppc0: [ITHREAD] sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 8250 or not responding sio0: [FILTER] sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounter "TSC" frequency 598063975 Hz quality 800 Timecounters tick every 1.000 msec firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) IP Filter: v4.1.28 initialized. Default = block all, Logging = enabled hptrr: no controller detected. ad0: 57231MB at ata0-master UDMA100 acd0: DVDR at ata1-master UDMA33 WARNING: WITNESS option enabled, expect reduced performance. Trying to mount root from ufs:/dev/ad0s1a free inode /home/424299 had 4 blocks free inode /home/424321 had 4 blocks free inode /home/424332 had 4 blocks free inode /home/424347 had 4 blocks free inode /home/424364 had 4 blocks free inode /home/424386 had 4 blocks GEOM_LABEL: Label for provider acd0t01 is iso9660/NOVE. drm0: on vgapci0 info: [drm] AGP at 0xe0000000 256MB info: [drm] Initialized radeon 1.25.0 20060524 pid 1284 (artsd), uid 1001: exited on signal 11 (core dumped) info: [drm] Setting GART location based on new memory map info: [drm] Loading R300 Microcode info: [drm] writeback test succeeded in 1 usecs drm0: [ITHREAD] info: [drm] Setting GART location based on new memory map info: [drm] Loading R300 Microcode info: [drm] writeback test succeeded in 1 usecs drm0: [ITHREAD] /etc/X11/xorg.conf: Section "ServerLayout" Identifier "X.org Configured" Screen 0 "Screen0" 0 0 InputDevice "Mouse0" "CorePointer" InputDevice "Keyboard0" "CoreKeyboard" EndSection Section "Files" RgbPath "/usr/local/share/X11/rgb" ModulePath "/usr/local/lib/xorg/modules" FontPath "/usr/local/lib/X11/fonts/misc/" FontPath "/usr/local/lib/X11/fonts/TTF/" FontPath "/usr/local/lib/X11/fonts/OTF" FontPath "/usr/local/lib/X11/fonts/Type1/" FontPath "/usr/local/lib/X11/fonts/100dpi/" FontPath "/usr/local/lib/X11/fonts/75dpi/" EndSection Section "Module" Load "extmod" Load "record" Load "dbe" Load "glx" Load "GLcore" Load "xtrap" Load "dri" Load "freetype" Load "type1" EndSection Section "InputDevice" Identifier "Keyboard0" Driver "kbd" Option "XkbLayout" "cz" EndSection Section "InputDevice" Identifier "Mouse0" Driver "mouse" Option "Protocol" "auto" Option "Device" "/dev/sysmouse" Option "ZAxisMapping" "4 5 6 7" EndSection Section "Monitor" Identifier "Monitor0" VendorName "Monitor Vendor" ModelName "Monitor Model" EndSection Section "Device" ### Available Driver options are:- ### Values: : integer, : float, : "True"/"False", ### : "String", : " Hz/kHz/MHz" ### [arg]: arg optional #Option "NoAccel" # [] #Option "SWcursor" # [] #Option "Dac6Bit" # [] #Option "Dac8Bit" # [] #Option "BusType" # [] #Option "CPPIOMode" # [] #Option "CPusecTimeout" # #Option "AGPMode" # #Option "AGPFastWrite" # [] #Option "AGPSize" # #Option "GARTSize" # #Option "RingSize" # #Option "BufferSize" # #Option "EnableDepthMoves" # [] #Option "EnablePageFlip" # [] #Option "NoBackBuffer" # [] #Option "DMAForXv" # [] #Option "FBTexPercent" # #Option "DepthBits" # #Option "PCIAPERSize" # #Option "AccelDFS" # [] #Option "DDCMode" # [] #Option "IgnoreEDID" # [] #Option "DisplayPriority" # [] #Option "PanelSize" # [] #Option "ForceMinDotClock" # #Option "ColorTiling" # [] #Option "VideoKey" # #Option "RageTheatreCrystal" # #Option "RageTheatreTunerPort" # #Option "RageTheatreCompositePort" # #Option "RageTheatreSVideoPort" # #Option "TunerType" # #Option "RageTheatreMicrocPath" # #Option "RageTheatreMicrocType" # #Option "ScalerWidth" # Option "RenderAccel" "true" # [] #Option "SubPixelOrder" # [] #Option "ShowCache" # [] #Option "DynamicClocks" # [] #Option "VGAAccess" # [] #Option "ReverseDDC" # [] #Option "LVDSProbePLL" # [] #Option "AccelMethod" # Option "DRI" "true" # [] #Option "ConnectorTable" # #Option "DefaultConnectorTable" # [] #Option "DefaultTMDSPLL" # [] Identifier "Card0" Driver "ati" VendorName "ATI Technologies Inc" BoardName "RV350 [Mobility Radeon 9600 M10]" BusID "PCI:1:0:0" EndSection Section "Screen" Identifier "Screen0" Device "Card0" Monitor "Monitor0" SubSection "Display" Viewport 0 0 Depth 1 EndSubSection SubSection "Display" Viewport 0 0 Depth 4 EndSubSection SubSection "Display" Viewport 0 0 Depth 8 EndSubSection SubSection "Display" Viewport 0 0 Depth 15 EndSubSection SubSection "Display" Viewport 0 0 Depth 16 EndSubSection SubSection "Display" Viewport 0 0 Depth 24 EndSubSection EndSection Any ideas what with it? Thank, Milan Bartos From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 17:55:22 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D4FA816A46C for ; Fri, 4 Jan 2008 17:55:22 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from kientzle.com (h-66-166-149-50.snvacaid.covad.net [66.166.149.50]) by mx1.freebsd.org (Postfix) with ESMTP id B02A213C447 for ; Fri, 4 Jan 2008 17:55:22 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: (from root@localhost) by kientzle.com (8.12.9/8.12.9) id m04Ht8HK004126; Fri, 4 Jan 2008 09:55:08 -0800 (PST) (envelope-from kientzle@freebsd.org) Received: from [10.0.0.209] (p54.kientzle.com [66.166.149.54]) by kientzle.com with SMTP; Fri, 04 Jan 2008 09:55:08 -0800 (PST) (envelope-from kientzle@freebsd.org) Message-ID: <477E72FC.5070304@freebsd.org> Date: Fri, 04 Jan 2008 09:55:08 -0800 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20060422 X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?UTF-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= References: <477C82F0.5060809@freebsd.org> <863ateemw2.fsf@ds4.des.no> <200801032200.25650.peter.schuller@infidyne.com> <8663yac62d.fsf@ds4.des.no> In-Reply-To: <8663yac62d.fsf@ds4.des.no> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Peter Schuller , freebsd-current@freebsd.org, Jason Evans Subject: Re: sbrk(2) broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 17:55:22 -0000 > "Sidegrading" is supposed to work now in HEAD; with a little hacking, > you can build an amd64 world and kernel on the i386 world, install the > kernel, reboot, and install world. AFAIK, the required hacking involves > copying /libexec/ld-elf.so.1 to /libexec/ld-elf32.so.1 ... I wonder when we'll have to standardize /libexec// to support multiple architectures for things like ld-elf.so.1. It used to only be a concern for those rare people running diskless over multiple architectures, but the case of i386 binaries on amd64 is a little more common. On the other hand, if ld-elf.so.1 is fairly unique in this concern, it might be simpler to rename it to: ld-elf-{i386,amd64,ppc,...}.so.1 Tim Kientzle From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 17:58:33 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 97CC716A419 for ; Fri, 4 Jan 2008 17:58:33 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.188]) by mx1.freebsd.org (Postfix) with ESMTP id 6C90713C45D for ; Fri, 4 Jan 2008 17:58:32 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: by rv-out-0910.google.com with SMTP id l15so6655760rvb.43 for ; Fri, 04 Jan 2008 09:58:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=vha38FwEltURLgb/2Nu0U6CLys5IwuxRF90gfJ0B5G0=; b=Rq4phK8fh0F9y0P/ZNXEcBD0cpDVz7niasWtVBCDEOhdp33HQb+6nZe4DAShQnd5erOvr5hh33figSzV0tne/SIMSnzcw7YX4/IHcbp6JUG9VsC548NcNmbhlQAKI8XySZFPfIvbcIQBgat6Txr5bIthBpGw3hPvf3gP9fFZe9g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=E/8w/8TJTf0+FYwENHhJLkJONMhdfOU3+alZNYlaEtF6bKf4H5+BGA3F9UT7JGAtZnbCmiHIK0U45p7Et04GzlMln/2oP2RTLVHeeOIYuRkm53WdAzTSrGMt25tmk3ujZnpLkx5u9xCYfruJVR66FAYKTx244aWMwajRTBWgDQk= Received: by 10.141.167.5 with SMTP id u5mr9025369rvo.189.1199469512614; Fri, 04 Jan 2008 09:58:32 -0800 (PST) Received: by 10.141.212.1 with HTTP; Fri, 4 Jan 2008 09:58:32 -0800 (PST) Message-ID: <9bbcef730801040958t36e48c9fjd0fbfabd49b08b97@mail.gmail.com> Date: Fri, 4 Jan 2008 18:58:32 +0100 From: "Ivan Voras" Sender: ivoras@gmail.com To: "Brooks Davis" In-Reply-To: <20080104163352.GA42835@lor.one-eyed-alien.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080104163352.GA42835@lor.one-eyed-alien.net> X-Google-Sender-Auth: 127963225529638b Cc: freebsd-current@freebsd.org Subject: Re: When will ZFS become stable? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 17:58:33 -0000 On 04/01/2008, Brooks Davis wrote: > On Fri, Jan 04, 2008 at 12:42:28PM +0100, Ivan Voras wrote: > > Hi, > > > > As far as I know about the details of implementation and what would it > > take to fix the problems, is it safe to assume ZFS will never become > > stable during 7.x lifetime? > > I suppose that depends what you mean by stable. My yardstick is currently "when a month goes by without anyone complaining it crashed on him" :) >It seems stable enough > for a number of applications today. This number is not so large. It seems to be easily crashed by rsync, for example (speaking from my own experience, and also some of my colleagues). > It's possible some of > the issues of memory requirements won't be fixable in 7.x, but I don't > think that's a given. I listened to some of Pawel's talks and devsummit brainstormings and I get the feeling *none* of the problems can be fixed in 7.x, especially on i386. I'm just asking for more official confirmation. This is not a trivial question, since it involves deploying systems to be maintained some years into the future - if ZFS will become stable relatively shortly, it might be worth putting up with crashes, but if not, there will be no near-future deployments of it. From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 17:58:37 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B542116A4E5; Fri, 4 Jan 2008 17:58:37 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail.speedfactory.net [66.23.216.219]) by mx1.freebsd.org (Postfix) with ESMTP id 363EC13C465; Fri, 4 Jan 2008 17:58:37 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.8q) with ESMTP id 227293551-1834499 for multiple; Fri, 04 Jan 2008 12:54:50 -0500 Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id m04HuaQV040837; Fri, 4 Jan 2008 12:56:38 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: Tai-hwa Liang Date: Fri, 4 Jan 2008 12:56:42 -0500 User-Agent: KMail/1.9.6 References: <474D81DB.7020004@FreeBSD.org> <200801031652.20807.jhb@freebsd.org> <0801041816427.55589@www.mmlab.cse.yzu.edu.tw> In-Reply-To: <0801041816427.55589@www.mmlab.cse.yzu.edu.tw> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200801041256.43153.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Fri, 04 Jan 2008 12:56:38 -0500 (EST) X-Virus-Scanned: ClamAV 0.91.2/5363/Fri Jan 4 08:37:27 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Remko Lodder , freebsd-current@freebsd.org, kib@freebsd.org Subject: Re: [Fwd: Re: kern/118258 sysctl causing panics on 7.0-xxx] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 17:58:37 -0000 On Friday 04 January 2008 05:19:28 am Tai-hwa Liang wrote: > On Thu, 3 Jan 2008, John Baldwin wrote: > > On Thursday 29 November 2007 10:53:32 pm Tai-hwa Liang wrote: > >> On Wed, 28 Nov 2007, Remko Lodder wrote: > >>> Hello, > >>> > >>> So as per Jeff's information, can someone from the -current > >>> list either contact jeff or try to resolve the problems > >>> mentioned? :) > >> > >> This is a longstanding bug which also exists in RELENG_6. It turns out > >> that 'sysctl kern.ttys' after a terminal device is removed could trigger > >> this panic reliably. For example, do 'sysctl kern.ttys' multiple times > >> after detaching an USB serial-to-rs232 cable or a PCMCIA modem card. > >> > >> Alternatively, following script would demo the panic if you don't have > >> a physically removable terminal device: > >> > >> #!/bin/sh > >> # > >> # Warning! Running this script as root will panic your CURRENT box... > >> # > >> while true; do > >> kldload dcons > >> kldunload dcons > >> ls /dev > >> sysctl kern.ttys > >> sleep 1 > >> done > >> > >> This seems to be a race between devfs and destroy_dev(), Cc'ing kib@ > >> since he probably has more clues in this area. > > > > Try this patch. Also available at > > http://www.FreeBSD.org/~jhb/patches/ttys_sysctl.patch > > With this patch, -CURRENT no longer boots and panics as follows: Fixed, was missing an unlock at the bottom of the loop. Patch is updated at the same URL. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 18:10:23 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DD8A916A419 for ; Fri, 4 Jan 2008 18:10:23 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from kientzle.com (h-66-166-149-50.snvacaid.covad.net [66.166.149.50]) by mx1.freebsd.org (Postfix) with ESMTP id B652813C448 for ; Fri, 4 Jan 2008 18:10:23 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: (from root@localhost) by kientzle.com (8.12.9/8.12.9) id m04HatJu003934; Fri, 4 Jan 2008 09:36:55 -0800 (PST) (envelope-from kientzle@freebsd.org) Received: from [10.0.0.209] (p54.kientzle.com [66.166.149.54]) by kientzle.com with SMTP; Fri, 04 Jan 2008 09:36:55 -0800 (PST) (envelope-from kientzle@freebsd.org) Message-ID: <477E6EB7.1010004@freebsd.org> Date: Fri, 04 Jan 2008 09:36:55 -0800 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20060422 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vadim Goncharov References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-current@freebsd.org" Subject: Re: sbrk(2), OOM-killer and malloc() overcommit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 18:10:24 -0000 Vadim Goncharov wrote: > ... related "bug", in that of malloc overcommit,... malloc overcommit is not a bug; it's an important feature for many applications, for the same reasons that sparse files are an important feature. (Many applications can optimize performance by using an addressable region much larger than the actual data they need to store.) If you really need a 4G block of memory, mmap() it to a file on disk. Tim Kientzle From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 18:12:10 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 720AF16A418; Fri, 4 Jan 2008 18:12:10 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (cl-162.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:a1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 01A0C13C467; Fri, 4 Jan 2008 18:12:09 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.1/8.13.8) with ESMTP id m04IC9Qv044778; Fri, 4 Jan 2008 12:12:09 -0600 (CST) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.1/8.13.8/Submit) id m04IC9kd044777; Fri, 4 Jan 2008 12:12:09 -0600 (CST) (envelope-from brooks) Date: Fri, 4 Jan 2008 12:12:09 -0600 From: Brooks Davis To: Ivan Voras Message-ID: <20080104181208.GE42835@lor.one-eyed-alien.net> References: <20080104163352.GA42835@lor.one-eyed-alien.net> <9bbcef730801040958t36e48c9fjd0fbfabd49b08b97@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XuV1QlJbYrcVoo+x" Content-Disposition: inline In-Reply-To: <9bbcef730801040958t36e48c9fjd0fbfabd49b08b97@mail.gmail.com> User-Agent: Mutt/1.5.16 (2007-06-09) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (lor.one-eyed-alien.net [127.0.0.1]); Fri, 04 Jan 2008 12:12:09 -0600 (CST) Cc: freebsd-current@freebsd.org Subject: Re: When will ZFS become stable? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 18:12:10 -0000 --XuV1QlJbYrcVoo+x Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 04, 2008 at 06:58:32PM +0100, Ivan Voras wrote: > On 04/01/2008, Brooks Davis wrote: > > On Fri, Jan 04, 2008 at 12:42:28PM +0100, Ivan Voras wrote: > > > Hi, > > > > > > As far as I know about the details of implementation and what would it > > > take to fix the problems, is it safe to assume ZFS will never become > > > stable during 7.x lifetime? > > > > I suppose that depends what you mean by stable. >=20 > My yardstick is currently "when a month goes by without anyone > complaining it crashed on him" :) I'm not sure any file system we support meets that criteria... > >It seems stable enough > > for a number of applications today. >=20 > This number is not so large. It seems to be easily crashed by rsync, > for example (speaking from my own experience, and also some of my > colleagues). I saw those crashes early one, but that's 90% of what the mirror server I'm running does and I'm not seeing them any more. I won't argue everything is fixed, but ZFS seems much more stable than it was. > > It's possible some of > > the issues of memory requirements won't be fixable in 7.x, but I don't > > think that's a given. >=20 > I listened to some of Pawel's talks and devsummit brainstormings and I > get the feeling *none* of the problems can be fixed in 7.x, especially > on i386. I'm just asking for more official confirmation. My understanding is that ZFS will never be a great choice on any 32-bit architecture without major changes Sun probably isn't interested in making. I think many of the problems people are reporting stem from that. > This is not a trivial question, since it involves deploying systems to > be maintained some years into the future - if ZFS will become stable > relatively shortly, it might be worth putting up with crashes, but if > not, there will be no near-future deployments of it. I don't think anyone is naive enough to say everything will be perfect by any given date. Reality doesn't work that way. People looking to deploy ZFS now will need to tolerate a certain amount of risk since it's never been part of a FreeBSD release (and it's still quite new even in Solaris). Issues being unfixable in 7.x are one of those risks, but that's always the case. -- Brooks --XuV1QlJbYrcVoo+x Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFHfnb4XY6L6fI4GtQRAtx1AKDiNM7zC3HA80cWMEU52oSZN4JJJQCgkRw6 8HAXT16t60UZ9Lc+hV051JE= =jo9L -----END PGP SIGNATURE----- --XuV1QlJbYrcVoo+x-- From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 18:32:41 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BE93016A418 for ; Fri, 4 Jan 2008 18:32:41 +0000 (UTC) (envelope-from vadimnuclight@tpu.ru) Received: from relay1.tpu.ru (relay1.tpu.ru [213.183.112.102]) by mx1.freebsd.org (Postfix) with ESMTP id 5ACCB13C457 for ; Fri, 4 Jan 2008 18:32:41 +0000 (UTC) (envelope-from vadimnuclight@tpu.ru) Received: from localhost (localhost.localdomain [127.0.0.1]) by relay1.tpu.ru (Postfix) with ESMTP id 565851046C1; Sat, 5 Jan 2008 00:32:38 +0600 (NOVT) X-Virus-Scanned: amavisd-new at tpu.ru Received: from relay1.tpu.ru ([127.0.0.1]) by localhost (relay1.tpu.ru [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bHZ8UAgfyT8i; Sat, 5 Jan 2008 00:32:35 +0600 (NOVT) Received: from mail.main.tpu.ru (mail.main.tpu.ru [10.0.0.3]) by relay1.tpu.ru (Postfix) with ESMTP id 4E8E5104689; Sat, 5 Jan 2008 00:32:35 +0600 (NOVT) Received: from mail.tpu.ru ([213.183.112.105]) by mail.main.tpu.ru with Microsoft SMTPSVC(6.0.3790.3959); Sat, 5 Jan 2008 00:32:34 +0600 Received: from nuclight.avtf.net ([78.140.2.250]) by mail.tpu.ru over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Sat, 5 Jan 2008 00:32:21 +0600 Date: Sat, 05 Jan 2008 00:32:04 +0600 To: "Tim Kientzle" References: <477E6EB7.1010004@freebsd.org> From: "Vadim Goncharov" Organization: AVTF TPU Hostel Content-Type: text/plain; format=flowed; delsp=yes; charset=koi8-r MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <477E6EB7.1010004@freebsd.org> User-Agent: Opera M2/7.54 (Win32, build 3865) X-OriginalArrivalTime: 04 Jan 2008 18:32:21.0574 (UTC) FILETIME=[24C7FE60:01C84F00] X-Mailman-Approved-At: Fri, 04 Jan 2008 18:43:11 +0000 Cc: "freebsd-current@freebsd.org" Subject: Re: sbrk(2), OOM-killer and malloc() overcommit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 18:32:41 -0000 04.01.08 @ 23:36 Tim Kientzle wrote: > Vadim Goncharov wrote: >> ... related "bug", in that of malloc overcommit,... > > malloc overcommit is not a bug; it's an important > feature for many applications, for the same > reasons that sparse files are an important feature. > (Many applications can optimize performance by > using an addressable region much larger than the > actual data they need to store.) What applications? How do they use this "feature"? > If you really need a 4G block of memory, mmap() > it to a file on disk. That's not a solution for end-user. Why just not have space reserving, as other operating systems can guarantee to their applications that stable availability of memory? -- WBR, Vadim Goncharov From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 19:28:25 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0528216A41B for ; Fri, 4 Jan 2008 19:28:25 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail15.syd.optusnet.com.au (mail15.syd.optusnet.com.au [211.29.132.196]) by mx1.freebsd.org (Postfix) with ESMTP id 9335C13C458 for ; Fri, 4 Jan 2008 19:28:24 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from server.vk2pj.dyndns.org (c220-239-20-82.belrs4.nsw.optusnet.com.au [220.239.20.82]) by mail15.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m04JSLaK004232 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 5 Jan 2008 06:28:22 +1100 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.2/8.14.1) with ESMTP id m04JSLCr019519; Sat, 5 Jan 2008 06:28:21 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.2/8.14.2/Submit) id m04JSK76019518; Sat, 5 Jan 2008 06:28:20 +1100 (EST) (envelope-from peter) Date: Sat, 5 Jan 2008 06:28:20 +1100 From: Peter Jeremy To: Vadim Goncharov Message-ID: <20080104192820.GM947@server.vk2pj.dyndns.org> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="m972NQjnE83KvVa/" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.17 (2007-11-01) Cc: "freebsd-current@freebsd.org" Subject: Re: sbrk(2), OOM-killer and malloc() overcommit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 19:28:25 -0000 --m972NQjnE83KvVa/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 04, 2008 at 09:08:12PM +0600, Vadim Goncharov wrote: >will make a bad reputation for FreeBSD as a server platform. But there ar= e=20 >related "bug", in that of malloc overcommit, which can be demonstrated by= =20 >this short program (if no resource limits are present, you'll see): This is a feature, not a bug. >http://people.freebsd.org/~kib/overcommit/index.html - but it has never=20 >gone into src tree. So why we still have this problem, why not have at=20 >least this patch?.. Overcommit has been bikeshedded extensively in the past. I suggest you study the archives first. --=20 Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. --m972NQjnE83KvVa/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHfojU/opHv/APuIcRAsskAJ4y6oWbS4Cq/du+Q3FRugdQvrZ7MgCgw+WE 3iiK4zR7mytCsQXXQeeyE4s= =qFUb -----END PGP SIGNATURE----- --m972NQjnE83KvVa/-- From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 19:33:37 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 189C816A46B for ; Fri, 4 Jan 2008 19:33:37 +0000 (UTC) (envelope-from gtodd@bellanet.org) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.242]) by mx1.freebsd.org (Postfix) with ESMTP id D390213C457 for ; Fri, 4 Jan 2008 19:33:36 +0000 (UTC) (envelope-from gtodd@bellanet.org) Received: by an-out-0708.google.com with SMTP id c14so1375596anc.13 for ; Fri, 04 Jan 2008 11:33:36 -0800 (PST) Received: by 10.100.254.18 with SMTP id b18mr36194320ani.57.1199473625625; Fri, 04 Jan 2008 11:07:05 -0800 (PST) Received: from ?192.168.2.159? ( [70.51.167.223]) by mx.google.com with ESMTPS id c38sm22329716anc.31.2008.01.04.11.07.04 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 04 Jan 2008 11:07:04 -0800 (PST) Message-ID: <477E82E3.6000303@bellanet.org> Date: Fri, 04 Jan 2008 14:02:59 -0500 From: Graham Todd User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: Matthew Dillon References: <200801012116.m01LGQhN012860@bonkers.video-collage.com> <200801032334.m03NY7Zd019292@apollo.backplane.com> In-Reply-To: <200801032334.m03NY7Zd019292@apollo.backplane.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Mikhail Teterin , efinleywork@efinley.com, current@freebsd.org Subject: Re: a new way to hang 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 19:33:37 -0000 Matthew Dillon wrote: > DragonFly has a new filesystem called HAMMER in the works which should > become production ready in a few months. All primary operations work now > so it is very real, but major pieces still need to be written and others > need to be rewritten and stabilized. It's in pre-alpha state now and > will be early-alpha by the DFly 2.0 release later this month. It should > be in a state that can be ported without having to play constant catchup > in maybe 2-3 months. This filesystem has full historical capabilities... > you don't even have to make snapshots per say, just sync, and you can get > at any data as-of any point in the past with a simple @@ > file/directory name extension. Wow, pretty neat. If HAMMER becomes the default filesystem and snapshots are low cost and easy are they any plans to leverage these features? :-) If I understand some of the opensolaris work correctly they are starting to make use of zfs snapshots for upgrades/updates and packaging systems. From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 20:21:52 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A169B16A469 for ; Fri, 4 Jan 2008 20:21:52 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id EEB2113C458 for ; Fri, 4 Jan 2008 20:21:51 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.samsco.home (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.8/8.13.8) with ESMTP id m04JsuDN073472; Fri, 4 Jan 2008 12:54:57 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <477E8F10.401@samsco.org> Date: Fri, 04 Jan 2008 12:54:56 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.11) Gecko/20071128 SeaMonkey/1.1.7 MIME-Version: 1.0 To: Graham Todd References: <200801012116.m01LGQhN012860@bonkers.video-collage.com> <200801032334.m03NY7Zd019292@apollo.backplane.com> <477E82E3.6000303@bellanet.org> In-Reply-To: <477E82E3.6000303@bellanet.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (pooker.samsco.org [168.103.85.57]); Fri, 04 Jan 2008 12:54:57 -0700 (MST) X-Spam-Status: No, score=-1.4 required=5.4 tests=ALL_TRUSTED autolearn=failed version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: Mikhail Teterin , efinleywork@efinley.com, current@freebsd.org Subject: Re: a new way to hang 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 20:21:52 -0000 Graham Todd wrote: > Matthew Dillon wrote: >> DragonFly has a new filesystem called HAMMER in the works which should >> become production ready in a few months. All primary operations work now >> so it is very real, but major pieces still need to be written and others >> need to be rewritten and stabilized. It's in pre-alpha state now and >> will be early-alpha by the DFly 2.0 release later this month. It should >> be in a state that can be ported without having to play constant catchup >> in maybe 2-3 months. This filesystem has full historical capabilities... >> you don't even have to make snapshots per say, just sync, and you can get >> at any data as-of any point in the past with a simple @@ >> file/directory name extension. > > Wow, pretty neat. If HAMMER becomes the default filesystem and snapshots > are low cost and easy are they any plans to leverage these features? :-) > If I understand some of the opensolaris work correctly they are > starting to make use of zfs snapshots for upgrades/updates and packaging > systems. There are better lists on which to discuss DragonflyBSD vaporware. Scott From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 20:27:06 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C3FCF16A419 for ; Fri, 4 Jan 2008 20:27:06 +0000 (UTC) (envelope-from vadimnuclight@tpu.ru) Received: from relay1.tpu.ru (relay1.tpu.ru [213.183.112.102]) by mx1.freebsd.org (Postfix) with ESMTP id 6915513C4D3 for ; Fri, 4 Jan 2008 20:27:06 +0000 (UTC) (envelope-from vadimnuclight@tpu.ru) Received: from localhost (localhost.localdomain [127.0.0.1]) by relay1.tpu.ru (Postfix) with ESMTP id 55E2D1046C5; Sat, 5 Jan 2008 02:27:05 +0600 (NOVT) X-Virus-Scanned: amavisd-new at tpu.ru Received: from relay1.tpu.ru ([127.0.0.1]) by localhost (relay1.tpu.ru [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X9gIP5qfsNFZ; Sat, 5 Jan 2008 02:27:02 +0600 (NOVT) Received: from mail.main.tpu.ru (mail.main.tpu.ru [10.0.0.3]) by relay1.tpu.ru (Postfix) with ESMTP id 2EEEC1046C1; Sat, 5 Jan 2008 02:27:02 +0600 (NOVT) Received: from mail.tpu.ru ([213.183.112.105]) by mail.main.tpu.ru with Microsoft SMTPSVC(6.0.3790.3959); Sat, 5 Jan 2008 02:27:01 +0600 Received: from nuclight.avtf.net ([78.140.2.250]) by mail.tpu.ru over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Sat, 5 Jan 2008 02:27:00 +0600 Date: Sat, 05 Jan 2008 02:26:53 +0600 To: "Peter Jeremy" References: <20080104192820.GM947@server.vk2pj.dyndns.org> From: "Vadim Goncharov" Organization: AVTF TPU Hostel Content-Type: text/plain; format=flowed; delsp=yes; charset=koi8-r MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <20080104192820.GM947@server.vk2pj.dyndns.org> User-Agent: Opera M2/7.54 (Win32, build 3865) X-OriginalArrivalTime: 04 Jan 2008 20:27:00.0371 (UTC) FILETIME=[28DD1E30:01C84F10] X-Mailman-Approved-At: Fri, 04 Jan 2008 20:55:04 +0000 Cc: "freebsd-current@freebsd.org" Subject: Re: sbrk(2), OOM-killer and malloc() overcommit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 20:27:06 -0000 05.01.08 @ 01:28 Peter Jeremy wrote: >> will make a bad reputation for FreeBSD as a server platform. But there >> are >> related "bug", in that of malloc overcommit, which can be demonstrated >> by >> this short program (if no resource limits are present, you'll see): > > This is a feature, not a bug. > >> http://people.freebsd.org/~kib/overcommit/index.html - but it has never >> gone into src tree. So why we still have this problem, why not have at >> least this patch?.. > > Overcommit has been bikeshedded extensively in the past. I suggest you > study the archives first. So why we are losing users due to this "feature", as other OSes provide tunables? Can I find somewhere summary of that discussions in archives? -- WBR, Vadim Goncharov From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 21:26:52 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8DC9316A417 for ; Fri, 4 Jan 2008 21:26:52 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from sippysoft.com (gk.360sip.com [72.236.70.226]) by mx1.freebsd.org (Postfix) with ESMTP id 4B21913C455 for ; Fri, 4 Jan 2008 21:26:51 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from [192.168.0.3] ([204.244.149.125]) (authenticated bits=0) by sippysoft.com (8.13.8/8.13.8) with ESMTP id m04LQg8a004176 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Jan 2008 13:26:43 -0800 (PST) (envelope-from sobomax@FreeBSD.org) Message-ID: <477EA466.6060204@FreeBSD.org> Date: Fri, 04 Jan 2008 13:25:58 -0800 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Tim Kientzle References: <477C82F0.5060809@freebsd.org> <863ateemw2.fsf@ds4.des.no> <200801032200.25650.peter.schuller@infidyne.com> <8663yac62d.fsf@ds4.des.no> <477E72FC.5070304@freebsd.org> In-Reply-To: <477E72FC.5070304@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= , freebsd-current@FreeBSD.org, Peter Schuller , Jason Evans Subject: ELF dynamic loader name [was: sbrk(2) broken] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 21:26:52 -0000 Tim Kientzle wrote: >> "Sidegrading" is supposed to work now in HEAD; with a little hacking, >> you can build an amd64 world and kernel on the i386 world, install the >> kernel, reboot, and install world. AFAIK, the required hacking involves >> copying /libexec/ld-elf.so.1 to /libexec/ld-elf32.so.1 ... > > I wonder when we'll have to standardize /libexec// to support > multiple architectures for things like ld-elf.so.1. It used to only > be a concern for those rare people running diskless over multiple > architectures, but the case of i386 binaries on amd64 is a little > more common. > > On the other hand, if ld-elf.so.1 is fairly unique in this > concern, it might be simpler to rename it to: > ld-elf-{i386,amd64,ppc,...}.so.1 Good point, it's silly that i386 binary running on amd64 kernel requires ld-elf32.so.1, while ld-elf.so.1 when running on i386 kernel. It adds unneeded complexity for running i386 jail or chroot on amd64 for example. I wonder if we can do what Tim said - rename dynamic loader to actually include architecture name. I am pretty sure it would allow to remove quite few special cases from the kernel elf/emulation code and possibly from the cross build logic. -Maxim From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 22:08:36 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EEA0B16A418 for ; Fri, 4 Jan 2008 22:08:36 +0000 (UTC) (envelope-from peter@wemm.org) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.185]) by mx1.freebsd.org (Postfix) with ESMTP id 6C94C13C455 for ; Fri, 4 Jan 2008 22:08:36 +0000 (UTC) (envelope-from peter@wemm.org) Received: by fk-out-0910.google.com with SMTP id b27so9934533fka.11 for ; Fri, 04 Jan 2008 14:08:36 -0800 (PST) Received: by 10.82.146.14 with SMTP id t14mr30571656bud.9.1199482943133; Fri, 04 Jan 2008 13:42:23 -0800 (PST) Received: by 10.82.182.2 with HTTP; Fri, 4 Jan 2008 13:42:23 -0800 (PST) Message-ID: Date: Fri, 4 Jan 2008 13:42:23 -0800 From: "Peter Wemm" To: "Maxim Sobolev" In-Reply-To: <477EA466.6060204@FreeBSD.org> MIME-Version: 1.0 References: <477C82F0.5060809@freebsd.org> <863ateemw2.fsf@ds4.des.no> <200801032200.25650.peter.schuller@infidyne.com> <8663yac62d.fsf@ds4.des.no> <477E72FC.5070304@freebsd.org> <477EA466.6060204@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= , Tim Kientzle , Peter Schuller , Jason Evans , freebsd-current@freebsd.org Subject: Re: ELF dynamic loader name [was: sbrk(2) broken] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 22:08:37 -0000 On 1/4/08, Maxim Sobolev wrote: > > Tim Kientzle wrote: > >> "Sidegrading" is supposed to work now in HEAD; with a little hacking, > >> you can build an amd64 world and kernel on the i386 world, install the > >> kernel, reboot, and install world. AFAIK, the required hacking > involves > >> copying /libexec/ld-elf.so.1 to /libexec/ld-elf32.so.1 ... > > > > I wonder when we'll have to standardize /libexec// to support > > multiple architectures for things like ld-elf.so.1. It used to only > > be a concern for those rare people running diskless over multiple > > architectures, but the case of i386 binaries on amd64 is a little > > more common. > > > > On the other hand, if ld-elf.so.1 is fairly unique in this > > concern, it might be simpler to rename it to: > > ld-elf-{i386,amd64,ppc,...}.so.1 > > Good point, it's silly that i386 binary running on amd64 kernel requires > ld-elf32.so.1, while ld-elf.so.1 when running on i386 kernel. It adds > unneeded complexity for running i386 jail or chroot on amd64 for example. > > I wonder if we can do what Tim said - rename dynamic loader to actually > include architecture name. I am pretty sure it would allow to remove > quite few special cases from the kernel elf/emulation code and possibly > from the cross build logic. > > -Maxim While this doesn't count as an explicit vote against the rename, we can solve the chroot problem easily. I did this once already, but for some reason never got around to committing it. However, renaming ld-elf.so.1 is a bad idea in general. Yes, it would have been better to have had the arch name in there from the start, but it doesn't. It is unfortunate, but I feel that changing it will cause far more pain across the board than it would solve for the specific case of chrooting i386 binaries. I don't think it is worth it. There are a whole bunch of references to the ld-elf.so.1 name. Not just in our tree, but in external 3rd party code. Even things like gdb "know" how to handle ld-elf.so.1. Getting those upstream folks to add additional strcmp()'s for ld-elf-i386.so.1, ld-elf-amd64.so.1 etc will be hard enough, and it will add another hurdle that minor platform maintainers have to overcome. ld-elf-mips-be-4Kc.so.1 anybody? (ok, that last one is a stretch) Anyway, I'm not absolutely against it, but I think it will be a net loss overall. We'll have more pain than I think it is worth, especially since the alternatives are much easier. -Peter From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 22:44:47 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4996416A418 for ; Fri, 4 Jan 2008 22:44:47 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.freebsd.org (Postfix) with ESMTP id 2392213C44B for ; Fri, 4 Jan 2008 22:44:47 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.14.1/8.13.7) with ESMTP id m04MiIUe001927; Fri, 4 Jan 2008 14:44:18 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.14.1/8.13.4/Submit) id m04MiI6T001926; Fri, 4 Jan 2008 14:44:18 -0800 (PST) Date: Fri, 4 Jan 2008 14:44:18 -0800 (PST) From: Matthew Dillon Message-Id: <200801042244.m04MiI6T001926@apollo.backplane.com> To: Scott Long References: <200801012116.m01LGQhN012860@bonkers.video-collage.com> <200801032334.m03NY7Zd019292@apollo.backplane.com> <477E82E3.6000303@bellanet.org> <477E8F10.401@samsco.org> Cc: Mikhail Teterin , efinleywork@efinley.com, current@freebsd.org, Graham Todd Subject: Re: a new way to hang 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 22:44:47 -0000 :There are better lists on which to discuss DragonflyBSD vaporware. : :Scott Not having a good new year, Scott? Not production ready, but certainly not vaporware. vkernel# cd /mnt vkernel# echo "abcd" > charlie vkernel# sync vkernel# hammer now 0x477eae02 vkernel# rm charlie vkernel# sync vkernel# cat charlie@@0x477eae02 abcd vkernel# ls vkernel# cd @@0x477eae02 vkernel# ls charlie vkernel# cd /mnt vkernel# echo "defgh" > charlie vkernel# sync vkernel# hammer now 0x477eae89 vkernel# echo "ijkl" > charlie vkernel# sync vkernel# hammer now 0x477eae8f vkernel# cat charlie ijkl vkernel# cat charlie@@0x477eae89 defgh vkernel# cat charlie@@0x477eae02 abcd vkernel# cd /mnt vkernel# cd @@0x477eae02 vkernel# cat charlie abcd vkernel# Not only does it work, but it works on the entire filesystem state thank you very much. In anycase, I will follow w/ Graham in personal email. -Matt Matthew Dillon From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 23:39:03 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2507716A418; Fri, 4 Jan 2008 23:39:03 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from sippysoft.com (gk.360sip.com [72.236.70.226]) by mx1.freebsd.org (Postfix) with ESMTP id D025613C442; Fri, 4 Jan 2008 23:39:02 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from [192.168.0.3] ([204.244.149.125]) (authenticated bits=0) by sippysoft.com (8.13.8/8.13.8) with ESMTP id m04NctfZ010632 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Jan 2008 15:38:57 -0800 (PST) (envelope-from sobomax@FreeBSD.org) Message-ID: <477EC363.90902@FreeBSD.org> Date: Fri, 04 Jan 2008 15:38:11 -0800 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Peter Wemm References: <477C82F0.5060809@freebsd.org> <863ateemw2.fsf@ds4.des.no> <200801032200.25650.peter.schuller@infidyne.com> <8663yac62d.fsf@ds4.des.no> <477E72FC.5070304@freebsd.org> <477EA466.6060204@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Jason Evans , freebsd-current@FreeBSD.org, =?ISO-8859-1?Q?Dag-Erling_Sm=F8?=, Tim Kientzle , =?ISO-8859-1?Q?rgrav?= , Peter Schuller Subject: Re: ELF dynamic loader name [was: sbrk(2) broken] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 23:39:03 -0000 Peter Wemm wrote: > While this doesn't count as an explicit vote against the rename, we can > solve the chroot problem easily. I did this once already, but for some > reason never got around to committing it. > > However, renaming ld-elf.so.1 is a bad idea in general. Yes, it would > have been better to have had the arch name in there from the start, but > it doesn't. It is unfortunate, but I feel that changing it will cause > far more pain across the board than it would solve for the specific case > of chrooting i386 binaries. I don't think it is worth it. > > There are a whole bunch of references to the ld-elf.so.1 name. Not just > in our tree, but in external 3rd party code. Even things like gdb > "know" how to handle ld-elf.so.1. Getting those upstream folks to add > additional strcmp()'s for ld-elf-i386.so.1, ld-elf-amd64.so.1 etc will > be hard enough, and it will add another hurdle that minor platform > maintainers have to overcome. ld-elf-mips-be-4Kc.so.1 anybody? (ok, > that last one is a stretch) > > Anyway, I'm not absolutely against it, but I think it will be a net loss > overall. We'll have more pain than I think it is worth, especially > since the alternatives are much easier. I see, what about moving it into /libexec//? Is it better approach? -Maxim From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 23:43:47 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A333E16A417; Fri, 4 Jan 2008 23:43:47 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from sippysoft.com (gk.360sip.com [72.236.70.226]) by mx1.freebsd.org (Postfix) with ESMTP id 5A5C213C448; Fri, 4 Jan 2008 23:43:47 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from [192.168.0.3] ([204.244.149.125]) (authenticated bits=0) by sippysoft.com (8.13.8/8.13.8) with ESMTP id m04NhguR010859 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Jan 2008 15:43:43 -0800 (PST) (envelope-from sobomax@FreeBSD.org) Message-ID: <477EC481.9060303@FreeBSD.org> Date: Fri, 04 Jan 2008 15:42:57 -0800 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Peter Wemm References: <477C82F0.5060809@freebsd.org> <863ateemw2.fsf@ds4.des.no> <200801032200.25650.peter.schuller@infidyne.com> <8663yac62d.fsf@ds4.des.no> <477E72FC.5070304@freebsd.org> <477EA466.6060204@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Jason Evans , freebsd-current@FreeBSD.org, =?ISO-8859-1?Q?Dag-Erling_Sm=F8?=, Tim Kientzle , =?ISO-8859-1?Q?rgrav?= , Peter Schuller Subject: Re: ELF dynamic loader name [was: sbrk(2) broken] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 23:43:47 -0000 Peter Wemm wrote: > There are a whole bunch of references to the ld-elf.so.1 name. Not just > in our tree, but in external 3rd party code. Even things like gdb > "know" how to handle ld-elf.so.1. Getting those upstream folks to add > additional strcmp()'s for ld-elf-i386.so.1, ld-elf-amd64.so.1 etc will > be hard enough, and it will add another hurdle that minor platform > maintainers have to overcome. ld-elf-mips-be-4Kc.so.1 anybody? (ok, > that last one is a stretch) P.S. I wonder why gdb(1) and friends need that strcmp()'s and don't use appropriate field from the elf header. I am pretty sure that dynamic linker name is embedded on link time in there. At least that's the very first string that is returned by invoking string(1) on any dynamic binary. -Maxim From owner-freebsd-current@FreeBSD.ORG Sat Jan 5 01:10:31 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2BA9016A417 for ; Sat, 5 Jan 2008 01:10:31 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail08.syd.optusnet.com.au (mail08.syd.optusnet.com.au [211.29.132.189]) by mx1.freebsd.org (Postfix) with ESMTP id ADFF113C447 for ; Sat, 5 Jan 2008 01:10:30 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from server.vk2pj.dyndns.org (c220-239-20-82.belrs4.nsw.optusnet.com.au [220.239.20.82]) by mail08.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m051ASTG025897 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 5 Jan 2008 12:10:28 +1100 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.2/8.14.1) with ESMTP id m051ARi2021525; Sat, 5 Jan 2008 12:10:27 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.2/8.14.2/Submit) id m051ARN1021524; Sat, 5 Jan 2008 12:10:27 +1100 (EST) (envelope-from peter) Date: Sat, 5 Jan 2008 12:10:27 +1100 From: Peter Jeremy To: Vadim Goncharov Message-ID: <20080105011027.GA21334@server.vk2pj.dyndns.org> References: <20080104192820.GM947@server.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+HP7ph2BbKc20aGI" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.17 (2007-11-01) Cc: "freebsd-current@freebsd.org" Subject: Re: sbrk(2), OOM-killer and malloc() overcommit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jan 2008 01:10:31 -0000 --+HP7ph2BbKc20aGI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jan 05, 2008 at 02:26:53AM +0600, Vadim Goncharov wrote: >So why we are losing users due to this "feature", Other than your previous post, I don't recall seeing this claim before. Can you provide references to people stating that they are abandoning FreeBSD because it doesn't support swap reservation? I've had a quick look at can't find anything. Definitely, no-one considers it enough of a problem to have raised a PR. > Can I find somewhere summary of that discussions in archives? Since you're making the claim, how about _you_ produce the evidence. In general, swap over-commit is a good idea because it enables you to get by with far less resources than would otherwise be necessary - I've disabled swap reservation on some systems at work to allieviate problems that it was causing and I haven't seen any subsequent issues due to overcommit being in use. --=20 Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. --+HP7ph2BbKc20aGI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHftkD/opHv/APuIcRAsP6AJ9yA0TI8LZndMLGrUIQFKFH+0T54wCglBMH u6ltdbRtjnfO4SXiZWvMJfU= =N/f4 -----END PGP SIGNATURE----- --+HP7ph2BbKc20aGI-- From owner-freebsd-current@FreeBSD.ORG Sat Jan 5 03:51:15 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DA17D16A417; Sat, 5 Jan 2008 03:51:15 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from kientzle.com (h-66-166-149-50.snvacaid.covad.net [66.166.149.50]) by mx1.freebsd.org (Postfix) with ESMTP id 8326113C4D3; Sat, 5 Jan 2008 03:51:15 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: (from root@localhost) by kientzle.com (8.12.9/8.12.9) id m053p7CU000553; Fri, 4 Jan 2008 19:51:07 -0800 (PST) (envelope-from kientzle@freebsd.org) Received: from [10.0.0.209] (p54.kientzle.com [66.166.149.54]) by kientzle.com with SMTP; Fri, 04 Jan 2008 19:51:07 -0800 (PST) (envelope-from kientzle@freebsd.org) Message-ID: <477EFEAB.8090807@freebsd.org> Date: Fri, 04 Jan 2008 19:51:07 -0800 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20060422 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Wemm References: <477C82F0.5060809@freebsd.org> <863ateemw2.fsf@ds4.des.no> <200801032200.25650.peter.schuller@infidyne.com> <8663yac62d.fsf@ds4.des.no> <477E72FC.5070304@freebsd.org> <477EA466.6060204@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Jason Evans , freebsd-current@freebsd.org, =?ISO-8859-1?Q?Dag-Erling_Sm=F8?=, =?ISO-8859-1?Q?rgrav?= , Peter Schuller Subject: Re: ELF dynamic loader name [was: sbrk(2) broken] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jan 2008 03:51:15 -0000 Peter Wemm wrote: > > On the other hand, if ld-elf.so.1 is fairly unique in this > > concern, it might be simpler to rename it to: > > ld-elf-{i386,amd64,ppc,...}.so.1 > > While this doesn't count as an explicit vote against the rename, we can > solve the chroot problem easily. Details? Does your approach also solve the problem of sharing /usr across different architectures (either in a diskless NFS environment or a dual-boot scenario with a shared /usr partition)? > However, renaming ld-elf.so.1 is a bad idea in general. ... things like gdb > "know" how to handle ld-elf.so.1. Getting those upstream folks to add > additional strcmp()'s for ld-elf-i386.so.1, ld-elf-amd64.so.1 etc will > be hard enough, and it will add another hurdle ... I'm not sure that I see the problem. What am I missing? 1) gdb is built to debug binaries for a particular architecture. (gdb/ARM can't debug gdb/i386 binaries) 2) gdb therefore only needs to check for "ld-elf-"`uname -m`".so.1", which is easy to handle when gdb itself is built. I can see some subtleties for cross-builds, but nothing outrageous. It also seems that your argument applies just as well to ld-elf.so.1 and ld-elf32.so.1. Either way, there's more than one ld-elf.so.1, and therefore more than one name to keep track of. I'm not championing the rename by any means, just trying to better understand the issues. The fact that amd64 can run i386 binaries but not vice-versa has a lot of subtle implications. Also, this is the first time that FreeBSD has really had large user bases on two fundamentally different architectures, so it's the first time we've really had to confront some of these support issues (such as the shared /usr scenario). Tim Kientzle From owner-freebsd-current@FreeBSD.ORG Sat Jan 5 03:44:02 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 35C4916A473; Sat, 5 Jan 2008 03:44:02 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from mx-out-05.forthnet.gr (mx-out.forthnet.gr [193.92.150.104]) by mx1.freebsd.org (Postfix) with ESMTP id 4AF2313C461; Sat, 5 Jan 2008 03:43:59 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from mx-av-04.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-05.forthnet.gr (8.13.8/8.13.8) with ESMTP id m053Qs5m001018; Sat, 5 Jan 2008 05:26:54 +0200 Received: from MX-IN-05.forthnet.gr (mx-in-05.forthnet.gr [193.92.150.32]) by mx-av-04.forthnet.gr (8.14.1/8.14.1) with ESMTP id m053QsBm009040; Sat, 5 Jan 2008 05:26:54 +0200 Received: from kobe.laptop (ppp5-162.adsl.forthnet.gr [62.1.228.162]) by MX-IN-05.forthnet.gr (8.14.2/8.14.2) with ESMTP id m053QqoY000781; Sat, 5 Jan 2008 05:26:53 +0200 Authentication-Results: MX-IN-05.forthnet.gr smtp.mail=keramida@ceid.upatras.gr; spf=neutral Authentication-Results: MX-IN-05.forthnet.gr header.from=keramida@ceid.upatras.gr; sender-id=neutral Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.2/8.14.2) with ESMTP id m053QoG6046933; Sat, 5 Jan 2008 05:26:51 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) Received: (from keramida@localhost) by kobe.laptop (8.14.2/8.14.2/Submit) id m053Qm2b046932; Sat, 5 Jan 2008 05:26:48 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) Date: Sat, 5 Jan 2008 05:26:47 +0200 From: Giorgos Keramidas To: Igor Mozolevsky Message-ID: <20080105032647.GA46843@kobe.laptop> References: <477C82F0.5060809@freebsd.org> <863ateemw2.fsf@ds4.des.no> <20080104002002.L30578@fledge.watson.org> <86bq81c12d.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Mailman-Approved-At: Sat, 05 Jan 2008 04:26:26 +0000 Cc: Dag-Erling Sm?rgrav , freebsd-current@freebsd.org, Robert Watson , Jason Evans Subject: Re: sbrk(2) broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jan 2008 03:44:02 -0000 On 2008-01-04 11:18, Igor Mozolevsky wrote: > On 04/01/2008, Dag-Erling Sm?rgrav wrote: > > Of course, if you're afraid of memory overcommit and you know in advance > > how much memory you need, you can simply allocate a sufficient amount of > > address space at startup and touch it all. This way, you will either be > > killed right away, or be guaranteed to have sufficient memory for the > > rest of your (process) lifetime. Alternatively, do what Varnish does: > > create a large file, mmap it, and allocate everything you need from that > > area, so you have your own private swap space. Just make sure to > > actually allocate the disk space you need (by filling the file with > > zeroes, or at the minimum writing a zero to the file every sb.st_blksize > > bytes, preferably sequentially to avoid excessive fragmentation) > > Surely you can just fseek() on the file at the correct lenght? That would create a nicely sized 'hole' in the starting blocks. What Dag-Erling describes is the correct(TM) way of making sure that all blocks have been allocated from the backing store of the file. From owner-freebsd-current@FreeBSD.ORG Sat Jan 5 08:03:41 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 419A316A468; Sat, 5 Jan 2008 08:03:41 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.freebsd.org (Postfix) with ESMTP id F17BC13C4CE; Sat, 5 Jan 2008 08:03:40 +0000 (UTC) (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 1JB3W9-000N7w-Ia; Sat, 05 Jan 2008 09:32:29 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Tim Kientzle In-reply-to: <477EFEAB.8090807@freebsd.org> References: <477C82F0.5060809@freebsd.org> <863ateemw2.fsf@ds4.des.no> <200801032200.25650.peter.schuller@infidyne.com> <8663yac62d.fsf@ds4.des.no> <477E72FC.5070304@freebsd.org> <477EA466.6060204@FreeBSD.org> <477EFEAB.8090807@freebsd.org> Comments: In-reply-to Tim Kientzle message dated "Fri, 04 Jan 2008 19:51:07 -0800." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 05 Jan 2008 09:32:28 +0200 From: Danny Braniss Message-ID: Cc: =?ISO-8859-1?Q?Dag-Erling_Sm=F8?=@FreeBSD.ORG, Peter Wemm , Jason Evans , freebsd-current@freebsd.org, =?ISO-8859-1?Q?rgrav?= , Peter Schuller Subject: Re: ELF dynamic loader name [was: sbrk(2) broken] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jan 2008 08:03:41 -0000 > Peter Wemm wrote: > > > On the other hand, if ld-elf.so.1 is fairly unique in this > > > concern, it might be simpler to rename it to: > > > ld-elf-{i386,amd64,ppc,...}.so.1 > > > > While this doesn't count as an explicit vote against the rename, we can > > solve the chroot problem easily. > > Details? Does your approach also solve the problem of > sharing /usr across different architectures (either in > a diskless NFS environment or a dual-boot scenario with > a shared /usr partition)? > > > However, renaming ld-elf.so.1 is a bad idea in general. ... things like gdb > > "know" how to handle ld-elf.so.1. Getting those upstream folks to add > > additional strcmp()'s for ld-elf-i386.so.1, ld-elf-amd64.so.1 etc will > > be hard enough, and it will add another hurdle ... > > I'm not sure that I see the problem. What am I missing? > 1) gdb is built to debug binaries for a particular architecture. > (gdb/ARM can't debug gdb/i386 binaries) > 2) gdb therefore only needs to check for "ld-elf-"`uname -m`".so.1", > which is easy to handle when gdb itself is built. > > I can see some subtleties for cross-builds, but nothing > outrageous. > > It also seems that your argument applies just as well to > ld-elf.so.1 and ld-elf32.so.1. Either way, there's more > than one ld-elf.so.1, and therefore more than one name > to keep track of. > > I'm not championing the rename by any means, just trying > to better understand the issues. The fact that amd64 can > run i386 binaries but not vice-versa has a lot of subtle > implications. Also, this is the first time that FreeBSD > has really had large user bases on two fundamentally > different architectures, so it's the first time we've > really had to confront some of these support issues > (such as the shared /usr scenario). > > Tim Kientzle The main issue is NOT sharing / or /usr or /usr/local, that is peenuts. root and usr is less that 500 MGB, /usr/local though big, is handled neatly by amd (the automounter). cross building is one issue, but the real problem is sharing user's binaries. in Apple one can compile a binary for both i386 & ppc, and the binary is twice as big. side note, I compiled such a program, but by mistake chose two different binaries to be joined, and imagine my surprice when it acted differently from expected. We have come a long way since the days that a wrong architecture a.out would just coredump. In the old days, we had ~/bin/$arch in our path to keep different binaries, it was the days of VAX/Sun, but since i386 arrived, this has been forgotten. Now we are concidering to deploy amd64, and it would be nice if it can be a 2way street - amd64 can run i386, but i386 should run the i386 version ... just blaberring before coffee. danny From owner-freebsd-current@FreeBSD.ORG Sat Jan 5 09:24:20 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 34CB216A4BF for ; Sat, 5 Jan 2008 09:24:20 +0000 (UTC) (envelope-from pj@smo.de) Received: from ilk.de (mx-out13.ilk.de [194.121.104.13]) by mx1.freebsd.org (Postfix) with ESMTP id 9B7E713C459 for ; Sat, 5 Jan 2008 09:24:19 +0000 (UTC) (envelope-from pj@smo.de) Received: from bologna.intern.smo.de (pool54.ka.ilk.net [212.86.194.54]) by ilk.de (8.13.4/8.13.4/ilk-relay) with ESMTP id m04LFEhs031694; Fri, 4 Jan 2008 22:15:15 +0100 Received: from [192.168.153.208] (herdubreid.intern.smo.de [192.168.153.208]) by bologna.intern.smo.de (8.13.8+Sun/8.13.8) with ESMTP id m04LASeS010537; Fri, 4 Jan 2008 22:10:29 +0100 (CET) Message-ID: <477EA22E.3070709@smo.de> Date: Fri, 04 Jan 2008 22:16:30 +0100 From: Philipp Ost User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.13) Gecko/20071021 X-Accept-Language: de, en-us, en MIME-Version: 1.0 To: Milan Bartos References: <200801041816.09716.merlyn500@gmail.com> In-Reply-To: <200801041816.09716.merlyn500@gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Ati driver xorg 1.4, works badly X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jan 2008 09:24:20 -0000 Milan Bartos wrote: > Hi, i have problem with ati mobility radeon 9600 graphic card. With vesa > driver works OK, but with ati or radeon driver, 3d acceletarion does not work > (with Xorg 6.9 worked). I am now using Xorg xorg-server-1.4_3,1. I don't have any problems with an ATi Radeon 9250 using xf86-video-ati-6.7.196 and xorg-server-1.4_3,1. This setup worked fine until X.org 7.3 was imported, it was broken until several weeks ago. I don't remember what fixed it though... This is on 7.0-PRERELEASE (i386). HTH, Philipp From owner-freebsd-current@FreeBSD.ORG Sat Jan 5 13:50:46 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7F0F516A4C0; Sat, 5 Jan 2008 13:50:46 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 51D0513C458; Sat, 5 Jan 2008 13:50:46 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 620072099; Sat, 5 Jan 2008 14:50:37 +0100 (CET) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: -0.2/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 41682207E; Sat, 5 Jan 2008 14:50:37 +0100 (CET) Received: by ds4.des.no (Postfix, from userid 1001) id 1D235844C3; Sat, 5 Jan 2008 14:50:37 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Robert Watson References: <86myrlahee.fsf@ds4.des.no> <5647.1199451237@critter.freebsd.dk> <86abnlag4t.fsf@ds4.des.no> <20080104132310.X77222@fledge.watson.org> Date: Sat, 05 Jan 2008 14:50:37 +0100 In-Reply-To: <20080104132310.X77222@fledge.watson.org> (Robert Watson's message of "Fri\, 4 Jan 2008 13\:24\:28 +0000 \(GMT\)") Message-ID: <86odc08jpu.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Poul-Henning Kamp , freebsd-current@freebsd.org, Jason Evans , Igor Mozolevsky Subject: Re: sbrk(2) broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jan 2008 13:50:46 -0000 Robert Watson writes: > Another aspect of the problem is that applications have come to depend > in malloc(3) returning NULL when memory is getting tight [...] I don't do that any more. Unless the program I'm writing is intended to run for a long time and can gracefully handle an out-of-memory situation (such as denying client requests until the situation improves), I write malloc() wrappers which zero the allocated region before returning to the caller, to force a SIGSEGV and spare the caller from having to check the return value. I sometimes also allocate a little bit extra and stick a magic signature and an allocation length in there so my free() wrapper can check for bugs and zero the allocated memory before freeing it. I wouldn't need any of this if my code only ran on FreeBSD, but most of my $DAYTIME_JOB code these days runs on Linux first and FreeBSD second. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Sat Jan 5 14:01:23 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F195216A479; Sat, 5 Jan 2008 14:01:23 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id BFEF513C455; Sat, 5 Jan 2008 14:01:23 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id A16002089; Sat, 5 Jan 2008 15:01:14 +0100 (CET) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: -0.2/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 1391A207E; Sat, 5 Jan 2008 15:01:14 +0100 (CET) Received: by ds4.des.no (Postfix, from userid 1001) id DD391844C3; Sat, 5 Jan 2008 15:01:13 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Skip Ford References: <477C82F0.5060809@freebsd.org> <863ateemw2.fsf@ds4.des.no> <20080104002002.L30578@fledge.watson.org> <86wsqqaqbe.fsf@ds4.des.no> <20080104110511.S77222@fledge.watson.org> <20080104135438.GA788@menantico.com> <20080104135912.GB57756@deviant.kiev.zoral.com.ua> <20080104141133.GB788@menantico.com> <20080104141857.GC57756@deviant.kiev.zoral.com.ua> <20080104145807.GC788@menantico.com> Date: Sat, 05 Jan 2008 15:01:13 +0100 In-Reply-To: <20080104145807.GC788@menantico.com> (Skip Ford's message of "Fri\, 04 Jan 2008 09\:58\:07 -0500") Message-ID: <86k5mo8j86.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Kostik Belousov , freebsd-current@FreeBSD.org, Robert Watson , Jason Evans , Poul-Henning Kamp Subject: Re: sbrk(2) broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jan 2008 14:01:24 -0000 Skip Ford writes: > Kostik Belousov writes: > > - per-user RLIMIT_SWAP limit, that account the allocation by the uid. T= his > > has some obvious problems with setuid(2) syscall. AFAIR, I ended up > > not moving the accounted numbers to the new uid. > The concensus in this thread seems to be that a per-process limit needs to > be implemented rather than, or in addition to, the per-uid limit you > already have. Implementing a per-process limit would help fix the setuid() problem, since the usage of the process calling setuid() would be known and could be transferred to the new user. There could however be a problem when a process creates a MAP_SHARED | MAP_ANON mapping, then fork()s, and the child calls setuid() (think privilege separation). Hopefully, this case is rare enough (malloc() always uses MAP_PRIVATE) that it can be handled using the most restrictive interpretation possible rather than trying to be painstakingly precise. (BTW, Skip, I find your MUA's use of Mail-Followup-To: offensive; if you don't want a copy of the followup, set the followup address to the list, not to a random previous participant in the thread) DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Sat Jan 5 14:03:58 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 046B816A4D1; Sat, 5 Jan 2008 14:03:58 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id C79B313C46B; Sat, 5 Jan 2008 14:03:57 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 5403A2089; Sat, 5 Jan 2008 15:03:49 +0100 (CET) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: -0.2/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id C8B91207E; Sat, 5 Jan 2008 15:03:48 +0100 (CET) Received: by ds4.des.no (Postfix, from userid 1001) id AE981844C3; Sat, 5 Jan 2008 15:03:48 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Maxim Sobolev References: <477C82F0.5060809@freebsd.org> <863ateemw2.fsf@ds4.des.no> <200801032200.25650.peter.schuller@infidyne.com> <8663yac62d.fsf@ds4.des.no> <477E72FC.5070304@freebsd.org> <477EA466.6060204@FreeBSD.org> <477EC363.90902@FreeBSD.org> Date: Sat, 05 Jan 2008 15:03:48 +0100 In-Reply-To: <477EC363.90902@FreeBSD.org> (Maxim Sobolev's message of "Fri\, 04 Jan 2008 15\:38\:11 -0800") Message-ID: <86fxxc8j3v.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@FreeBSD.org, Tim Kientzle , Peter Schuller , Jason Evans , Peter Wemm Subject: Re: ELF dynamic loader name X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jan 2008 14:03:58 -0000 Maxim Sobolev writes: > I see, what about moving it into /libexec//? Is it better > approach? I'd rather see us implement variant symlinks, have /libexec symlink to /libexec.%ARCH%, and let the kernel sort'em out... DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Sat Jan 5 14:16:33 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 71B4516A420; Sat, 5 Jan 2008 14:16:33 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 40BA513C4CC; Sat, 5 Jan 2008 14:16:33 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 5FC08209C; Sat, 5 Jan 2008 15:16:24 +0100 (CET) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: -0.2/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 3CDC6207E; Sat, 5 Jan 2008 15:16:24 +0100 (CET) Received: by ds4.des.no (Postfix, from userid 1001) id 0FBE9844C3; Sat, 5 Jan 2008 15:16:24 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Tim Kientzle References: <477C82F0.5060809@freebsd.org> <863ateemw2.fsf@ds4.des.no> <200801032200.25650.peter.schuller@infidyne.com> <8663yac62d.fsf@ds4.des.no> <477E72FC.5070304@freebsd.org> <477EA466.6060204@FreeBSD.org> <477EFEAB.8090807@freebsd.org> Date: Sat, 05 Jan 2008 15:16:23 +0100 In-Reply-To: <477EFEAB.8090807@freebsd.org> (Tim Kientzle's message of "Fri\, 04 Jan 2008 19\:51\:07 -0800") Message-ID: <868x348iiw.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, Peter Schuller , Jason Evans , Peter Wemm Subject: Re: ELF dynamic loader name X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jan 2008 14:16:33 -0000 Tim Kientzle writes: > It also seems that your argument applies just as well to ld-elf.so.1 > and ld-elf32.so.1. Either way, there's more than one ld-elf.so.1, and > therefore more than one name to keep track of. We don't embed ld-elf32.so.1 in 32-bit binaries; if we did, we couldn't run unmodified i386 binaries on amd64, or move i386 binaries built on an amd64 system to a real i386 system. Instead, the kernel automagically translates ld-elf.so.1 to ld-elf32.so.1 for 32-bit binaries, and gdb is none the wiser. (see src/sys/sys/imgact_elf.h, src/sys/kern/imgact_elf.c, and the various instances of Elf_Brandinfo, Elf32_Brandinfo and Elf64_Brandinfo in the kernel for the precise details of how this is done) DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Sat Jan 5 14:19:53 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0557D16A4D0; Sat, 5 Jan 2008 14:19:53 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id C954713C442; Sat, 5 Jan 2008 14:19:52 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 1B059209C; Sat, 5 Jan 2008 15:19:44 +0100 (CET) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: -0.2/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id F0ACB207E; Sat, 5 Jan 2008 15:19:43 +0100 (CET) Received: by ds4.des.no (Postfix, from userid 1001) id CCC2B844C3; Sat, 5 Jan 2008 15:19:43 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: "Sepherosa Ziehau" References: <86ir2hznnd.fsf@ds4.des.no> <86abnpu0wv.fsf@ds4.des.no> <86abnovy4k.fsf@ds4.des.no> <86odc3dlgi.fsf@ds4.des.no> <86lk76c6t5.fsf@ds4.des.no> Date: Sat, 05 Jan 2008 15:19:43 +0100 In-Reply-To: (Sepherosa Ziehau's message of "Fri\, 4 Jan 2008 22\:20\:48 +0800") Message-ID: <864pds8idc.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: kevlo@freebsd.org, sam@freebsd.org, current@freebsd.org, net@freebsd.org Subject: Re: if_ral regression X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jan 2008 14:19:53 -0000 "Sepherosa Ziehau" writes: > This actually brings up two things: > 1) I think we should ignore seq in multicast frames; this is permitted in > 802.11 standard. In dfly I did that, since one of our users > encountered a broken commercial AP which is not 802.11e but uses > different seq for data and beacon. > 2) TX sequence. I think standards only mention QSTA/nQSTA, but not > AP. Currently our AP uses per node TX seq, which means beacon's seq > is difficult to choose, at least for 2560 based ral(4), whose beacons' > seq need to be set by software. I saw Linksys AP uses one seq for all > of the frames it sends. Sam, what's you opinion on this? > > I think if STA counts ral(4)'s beacon seq, as what we do currently, > beacon missing will quickly happen since beacons will be discarded > after first several data frames. OK, I *think* I understood most of that. Does this suggest a solution to you? I will try to get the wlandebug output tonight. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Sat Jan 5 14:44:15 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 98CE616A46C; Sat, 5 Jan 2008 14:44:15 +0000 (UTC) (envelope-from vadim_nuclight@mail.ru) Received: from mx6.mail.ru (mx6.mail.ru [194.67.23.26]) by mx1.freebsd.org (Postfix) with ESMTP id 6BBEE13C4D9; Sat, 5 Jan 2008 14:44:15 +0000 (UTC) (envelope-from vadim_nuclight@mail.ru) Received: from [78.140.2.250] (port=11767 helo=nuclight.avtf.net) by mx6.mail.ru with esmtp id 1JBAFx-000Fiv-00; Sat, 05 Jan 2008 17:44:13 +0300 Date: Sat, 05 Jan 2008 20:44:10 +0600 To: "Peter Jeremy" References: <20080104192820.GM947@server.vk2pj.dyndns.org> <20080105011027.GA21334@server.vk2pj.dyndns.org> From: "Vadim Goncharov" Organization: AVTF TPU Hostel Content-Type: text/plain; format=flowed; delsp=yes; charset=koi8-r MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <20080105011027.GA21334@server.vk2pj.dyndns.org> User-Agent: Opera M2/7.54 (Win32, build 3865) Cc: "freebsd-current@freebsd.org" , "advocacy@freebsd.org" Subject: Re: sbrk(2), OOM-killer and malloc() overcommit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jan 2008 14:44:15 -0000 05.01.08 @ 07:10 Peter Jeremy wrote: >> So why we are losing users due to this "feature", > > Other than your previous post, I don't recall seeing this claim before. > Can you provide references to people stating that they are abandoning > FreeBSD because it doesn't support swap reservation? I've had a quick > look at can't find anything. Definitely, no-one considers it enough of > a problem to have raised a PR. Those people usually do not read or write any maillists, PRs, etc. - they simply take another OS, which they heard of support from commercial vendors, and which CAN do what they want, in this case - enable space reservation for at least some processes. I don't remember all of that people, but at least one lives in my town, and it is him program (with his name/address in comments) which I gave as illustration of problem in my first letter of this thread. And this man now says everyone that FreeBSD is good for education/small systems, but unsuitable for serious data-mining tasks... >> Can I find somewhere summary of that discussions in archives? > > Since you're making the claim, how about _you_ produce the evidence. I don't have too many time to search through all bikeshedding on a non-native language. But sometime ago this topic was discussed in russian NNTP BSD group, which shown in actuality of problem for some people - as a result, I was told that Kostik Belousov made a patch partially solving problem. So - why do not have tunable, which can pleasure both camps? Every time when people want XXX and others want the opposite - make it an option to not loose any of them... > In general, swap over-commit is a good idea because it enables you to > get by with far less resources than would otherwise be necessary - I've > disabled swap reservation on some systems at work to allieviate problems > that it was causing and I haven't seen any subsequent issues due to > overcommit being in use. There were case in our town when on heavy loaded web-server apache processes were dying on memory pressure - aforementioned man said that was due to overcommit and OOM killer working. I don't know about details, but surely it could lead to switching to Linux from FreeBSD... So I think, if that users are mistaking, we need an article explaininfg why memory overcommit is good and where are they wrong - we need people think good about FreeBSD, yeah? Possibly with tunable and description of it's bad effects, of course. -- WBR, Vadim Goncharov From owner-freebsd-current@FreeBSD.ORG Sat Jan 5 15:04:17 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E44B916A4CC for ; Sat, 5 Jan 2008 15:04:17 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.freebsd.org (Postfix) with ESMTP id 128B813C4F3 for ; Sat, 5 Jan 2008 15:04:16 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 7855345EA4; Sat, 5 Jan 2008 16:04:14 +0100 (CET) Received: from localhost (unknown [10.1.0.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id C6ABF45E9C; Sat, 5 Jan 2008 16:04:02 +0100 (CET) Date: Sat, 5 Jan 2008 16:03:55 +0100 From: Pawel Jakub Dawidek To: srwadleigh Message-ID: <20080105150355.GB6472@garage.freebsd.pl> References: <20080102114327.62f661f5@udor.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/NkBOFFp2J2Af1nK" Content-Disposition: inline In-Reply-To: <20080102114327.62f661f5@udor.net> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=3.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-current@freebsd.org Subject: Re: Gjournal X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jan 2008 15:04:18 -0000 --/NkBOFFp2J2Af1nK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 02, 2008 at 11:43:27AM +0900, srwadleigh wrote: > I am having a strange problem with gjournal on a thinkpad T41, >=20 > I am running: 7.0-PRERELEASE - Wed Jan 2 06:05:20 JST 2008 > And have the problem with both a custom and generic kernel. >=20 > If I load gjournal through loader.conf or compile GEOM_JOURNAL into > the kernel, upon reboot all my slices change, and break booting. >=20 > ad0s1a becomes ad0a > ad0s1d becomes ad0d, and so on.. >=20 > If I manually run gjournal load after boot the slices are fine, > everything works as expected. >=20 > Here is my journal setup: >=20 > /dev/ad0s1f.journal 64G /usr/home >=20 > Geom name: gjournal 2080874044 > ID: 2080874044 > Providers: > 1. Name: ad0s1f.journal > Mediasize: 70812433920 (66G) > Sectorsize: 512 > Mode: r1w1e1 > Consumers: > 1. Name: ad0s1f > Mediasize: 71886176256 (67G) > Sectorsize: 512 > Mode: r1w1e1 > Jend: 71886175744 > Jstart: 70812433920 > Role: Data,Journal >=20 >=20 > Doing some research on the list I found a similar problem in the past > with gmirror, where the slice and device ending at the same place was > being confused. The solution suggested there seemed to be to hardcode > the provider names into the metadata. >=20 > http://lists.freebsd.org/pipermail/freebsd-stable/2005-May/014448.html >=20 > My question is, is this possibly the same issue now with gjournal? and > is it possible to hardcode provider names after a journal has been > created? Just unmount the file system, stop the journal and call 'gjournal label' with exactly the sam parameters as originally plus '-h' option. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --/NkBOFFp2J2Af1nK Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHf5xbForvXbEpPzQRAjOQAJ4mAIKqZH30jPMHsVG0wn7uJmXuFQCgiKOO x0QPhv404/4zklZWzKPL2FU= =m2f1 -----END PGP SIGNATURE----- --/NkBOFFp2J2Af1nK-- From owner-freebsd-current@FreeBSD.ORG Sat Jan 5 18:31:47 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 39E1A16A41A for ; Sat, 5 Jan 2008 18:31:47 +0000 (UTC) (envelope-from merlyn500@gmail.com) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.186]) by mx1.freebsd.org (Postfix) with ESMTP id D9FA113C44B for ; Sat, 5 Jan 2008 18:31:46 +0000 (UTC) (envelope-from merlyn500@gmail.com) Received: by mu-out-0910.google.com with SMTP id w8so4760403mue.4 for ; Sat, 05 Jan 2008 10:31:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date:user-agent:references:in-reply-to:cc:mime-version:content-type:content-transfer-encoding:content-disposition:message-id; bh=DNLbxrPrbGVH5/oe+RJN8iEn8HrYnlLpKRvAw/RWjjU=; b=QWYD9cMC5eEWvXcTGWguJMhNGlJNSGI/59DOTwi3el0hvZBNHegETVlyAVJTCszdBzuh06jEIafA2UwUzB9jjK2ikfNHpqPiUw5hUBIEJcAZ26vDYxVgUpK3OD2mIYm0Fz1iOBMioRmWvfzaybzcgPUnpIIO9kzafT/cPwD0f+c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:references:in-reply-to:cc:mime-version:content-type:content-transfer-encoding:content-disposition:message-id; b=xYEUlYxooKwQQkoAOnz5ZVY/fIi4Fu6abOPfmQM9Efc4J7IoUL+wTis2askCDpCVt3gTdtjZPzfwhuqFQRKutvzGBz9KmccXE7HH6gKjiISpEOqiATjE5q1yuzf0X06ttZNcR0xEE1Kc9o7brnMRhJmgHAbFp5CHAYdCyVDsxts= Received: by 10.78.183.8 with SMTP id g8mr9593933huf.55.1199557903623; Sat, 05 Jan 2008 10:31:43 -0800 (PST) Received: from ?192.168.1.3? ( [85.207.232.114]) by mx.google.com with ESMTPS id f6sm3453314nfh.21.2008.01.05.10.31.40 (version=SSLv3 cipher=OTHER); Sat, 05 Jan 2008 10:31:42 -0800 (PST) From: Milan Bartos To: Philipp Ost Date: Sat, 5 Jan 2008 19:30:25 +0100 User-Agent: KMail/1.9.7 References: <200801041816.09716.merlyn500@gmail.com> <200801051044.58548.merlyn500@gmail.com> <477FA875.2090803@smo.de> In-Reply-To: <477FA875.2090803@smo.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200801051930.26049.merlyn500@gmail.com> Cc: freebsd-current@freebsd.org Subject: Re: Ati driver xorg 1.4, works badly X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jan 2008 18:31:47 -0000 Thanks a lot for you xorg.conf. FPS with glxgears is now about 1500 (before it was about 500). But still, in glxgears window (supertux2 too) is black, only black. I have loaded 9 3 0xc0ebc000 10ebc drm.ko (/boot/kernel/drm.ko) and 10 1 0xc0ecd000 22cb4 radeon.ko (/boot/kernel/radeon.ko). Direct rendering Yes. [Vallhala]~>glxinfo |grep direct libGL warning: 3D driver claims to not support visual 0x55 direct rendering: Yes [Vallhala]~> And here is something strange: libGL warning: 3D driver claims to not support visual 0x55 And i don't know what is it. Regards Milan Dne Saturday 05 of January 2008 16:55:33 jste napsal(a): > Milan Bartos wrote: > > And can you please send me your xorg.conf? It is possible, i have > > something bad in my. > > No problem -- the working xorg.conf is attached. The only "nasty" thing > about it is that X complains about a non-matching device section for > PCI-ID 1:0:1 (or something like that). It doesn't matter if it's > configured in xorg.conf or not... > > > HTH, > Philipp From owner-freebsd-current@FreeBSD.ORG Sat Jan 5 20:56:13 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CAA2716A417 for ; Sat, 5 Jan 2008 20:56:13 +0000 (UTC) (envelope-from roberto@keltia.freenix.fr) Received: from keltia.freenix.fr (keltia.freenix.org [82.230.37.243]) by mx1.freebsd.org (Postfix) with ESMTP id 84A9C13C465 for ; Sat, 5 Jan 2008 20:56:13 +0000 (UTC) (envelope-from roberto@keltia.freenix.fr) Received: from localhost (localhost [127.0.0.1]) by keltia.freenix.fr (Postfix/TLS) with ESMTP id E2CC539B5C for ; Sat, 5 Jan 2008 21:56:11 +0100 (CET) X-Virus-Scanned: amavisd-new at keltia.freenix.fr Received: from keltia.freenix.fr ([127.0.0.1]) by localhost (keltia.freenix.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LCjJqMEJ2Oud for ; Sat, 5 Jan 2008 21:56:09 +0100 (CET) Received: by keltia.freenix.fr (Postfix/TLS, from userid 101) id 49D6839B4D; Sat, 5 Jan 2008 21:56:09 +0100 (CET) Date: Sat, 5 Jan 2008 21:56:09 +0100 From: Ollivier Robert To: freebsd-current@freebsd.org Message-ID: <20080105205609.GA30392@keltia.freenix.fr> References: <477C82F0.5060809@freebsd.org> <863ateemw2.fsf@ds4.des.no> <200801032200.25650.peter.schuller@infidyne.com> <8663yac62d.fsf@ds4.des.no> <477E72FC.5070304@freebsd.org> <477EA466.6060204@FreeBSD.org> <477EC363.90902@FreeBSD.org> <86fxxc8j3v.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <86fxxc8j3v.fsf@ds4.des.no> X-Operating-System: MacOS X / Macbook Pro - FreeBSD 6.2 / Dell D820 SMP User-Agent: Mutt/1.5.15 (2007-04-06) Subject: Re: ELF dynamic loader name X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jan 2008 20:56:13 -0000 According to Dag-Erling Smørgrav: > I'd rather see us implement variant symlinks, have /libexec symlink to > /libexec.%ARCH%, and let the kernel sort'em out... Been listening to Terry recently? ;-) -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr Darwin sidhe.keltia.net Version 8.10.1: Wed May 23 16:33:00 PDT 2007 i386 From owner-freebsd-current@FreeBSD.ORG Sat Jan 5 22:21:38 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5032216A418 for ; Sat, 5 Jan 2008 22:21:38 +0000 (UTC) (envelope-from pj@smo.de) Received: from ilk.de (mx-out13.ilk.de [194.121.104.13]) by mx1.freebsd.org (Postfix) with ESMTP id E8DFC13C44B for ; Sat, 5 Jan 2008 22:21:37 +0000 (UTC) (envelope-from pj@smo.de) Received: from bologna.intern.smo.de (pool61.ka.ilk.net [212.86.194.61]) by ilk.de (8.13.4/8.13.4/ilk-relay) with ESMTP id m05MLY3q028937; Sat, 5 Jan 2008 23:21:35 +0100 Received: from [192.168.153.208] (herdubreid.intern.smo.de [192.168.153.208]) by bologna.intern.smo.de (8.13.8+Sun/8.13.8) with ESMTP id m05MGsZl015655; Sat, 5 Jan 2008 23:16:54 +0100 (CET) Message-ID: <47800341.4020905@smo.de> Date: Sat, 05 Jan 2008 23:22:57 +0100 From: Philipp Ost User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.13) Gecko/20071021 X-Accept-Language: de, en-us, en MIME-Version: 1.0 To: Milan Bartos References: <200801041816.09716.merlyn500@gmail.com> <200801051044.58548.merlyn500@gmail.com> <477FA875.2090803@smo.de> <200801051930.26049.merlyn500@gmail.com> In-Reply-To: <200801051930.26049.merlyn500@gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Ati driver xorg 1.4, works badly X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jan 2008 22:21:38 -0000 Hi Milan, hi list, Milan Bartos wrote: > Thanks a lot for you xorg.conf. FPS with glxgears is now about 1500 (before it > was about 500). But still, in glxgears window (supertux2 too) is black, only > black. I have loaded > 9 3 0xc0ebc000 10ebc drm.ko (/boot/kernel/drm.ko) and > 10 1 0xc0ecd000 22cb4 radeon.ko (/boot/kernel/radeon.ko). I have loaded those modules, too. However, I see the gears spinning in glxgears (ca. 920 FPS, but that's more or less unimportant :-P). Don't know about supertux2 as I don't have it installed. > Direct rendering Yes. > [Vallhala]~>glxinfo |grep direct > libGL warning: 3D driver claims to not support visual 0x55 > direct rendering: Yes > [Vallhala]~> > > And here is something strange: > libGL warning: 3D driver claims to not support visual 0x55 > And i don't know what is it. Same here: $ glxinfo | grep rendering libGL warning: 3D driver claims to not support visual 0x64 direct rendering: Yes $ I did a quick search and I got a lot of results related to Compiz and AIGLX -- I'm even more confused now as I have neither of them installed... Can somebody with more wisdom shed some light on this please? I'm using a Radeon 9250 if that matters (from pciconf): vgapci0@pci0:1:0:0: class=0x030000 card=0x1013196d chip=0x59601002 rev=0x01 hdr=0x00 vendor = 'ATI Technologies Inc' device = 'RV280 Radeon 9200 Pro' class = display subclass = VGA vgapci1@pci0:1:0:1: class=0x038000 card=0x1012196d chip=0x59401002 rev=0x01 hdr=0x00 vendor = 'ATI Technologies Inc' device = 'RV280 Radeon 9200 Pro - Secondary' class = display Regards, Philipp From owner-freebsd-current@FreeBSD.ORG Sat Jan 5 22:24:32 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8790D16A418 for ; Sat, 5 Jan 2008 22:24:32 +0000 (UTC) (envelope-from peter@wemm.org) Received: from hu-out-0506.google.com (hu-out-0506.google.com [72.14.214.237]) by mx1.freebsd.org (Postfix) with ESMTP id D2CD613C45A for ; Sat, 5 Jan 2008 22:24:31 +0000 (UTC) (envelope-from peter@wemm.org) Received: by hu-out-0506.google.com with SMTP id 28so1013979hub.8 for ; Sat, 05 Jan 2008 14:24:30 -0800 (PST) Received: by 10.82.108.9 with SMTP id g9mr32488075buc.34.1199571870107; Sat, 05 Jan 2008 14:24:30 -0800 (PST) Received: by 10.82.182.2 with HTTP; Sat, 5 Jan 2008 14:24:30 -0800 (PST) Message-ID: Date: Sat, 5 Jan 2008 14:24:30 -0800 From: "Peter Wemm" To: "Danny Braniss" In-Reply-To: MIME-Version: 1.0 References: <477C82F0.5060809@freebsd.org> <863ateemw2.fsf@ds4.des.no> <200801032200.25650.peter.schuller@infidyne.com> <8663yac62d.fsf@ds4.des.no> <477E72FC.5070304@freebsd.org> <477EA466.6060204@FreeBSD.org> <477EFEAB.8090807@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: =?ISO-8859-1?Q?Dag-Erling_Sm=F8?=@freebsd.org, freebsd-current@freebsd.org, Jason Evans , Tim Kientzle , rgrav , Peter Schuller Subject: Re: ELF dynamic loader name [was: sbrk(2) broken] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jan 2008 22:24:32 -0000 On 1/4/08, Danny Braniss wrote: > > > Peter Wemm wrote: > > > > On the other hand, if ld-elf.so.1 is fairly unique in this > > > > concern, it might be simpler to rename it to: > > > > ld-elf-{i386,amd64,ppc,...}.so.1 > > > > > > While this doesn't count as an explicit vote against the rename, we > can > > > solve the chroot problem easily. > > > > Details? Does your approach also solve the problem of > > sharing /usr across different architectures (either in > > a diskless NFS environment or a dual-boot scenario with > > a shared /usr partition)? > > > > > However, renaming ld-elf.so.1 is a bad idea in general. ... things > like gdb > > > "know" how to handle ld-elf.so.1. Getting those upstream folks to add > > > additional strcmp()'s for ld-elf-i386.so.1, ld-elf-amd64.so.1 etc will > > > be hard enough, and it will add another hurdle ... > > > > I'm not sure that I see the problem. What am I missing? > > 1) gdb is built to debug binaries for a particular architecture. > > (gdb/ARM can't debug gdb/i386 binaries) > > 2) gdb therefore only needs to check for "ld-elf-"`uname -m`".so.1", > > which is easy to handle when gdb itself is built. > > > > I can see some subtleties for cross-builds, but nothing > > outrageous. > > > > It also seems that your argument applies just as well to > > ld-elf.so.1 and ld-elf32.so.1. Either way, there's more > > than one ld-elf.so.1, and therefore more than one name > > to keep track of. > > > > I'm not championing the rename by any means, just trying > > to better understand the issues. The fact that amd64 can > > run i386 binaries but not vice-versa has a lot of subtle > > implications. Also, this is the first time that FreeBSD > > has really had large user bases on two fundamentally > > different architectures, so it's the first time we've > > really had to confront some of these support issues > > (such as the shared /usr scenario). > > > > Tim Kientzle > > The main issue is NOT sharing / or /usr or /usr/local, that is peenuts. > root and usr is less that 500 MGB, /usr/local though big, is handled > neatly by amd (the automounter). > cross building is one issue, but the real problem is sharing user's > binaries. > in Apple one can compile a binary for both i386 & ppc, and the binary is > twice as big. side note, I compiled such a program, but by mistake chose > two different binaries to be joined, and imagine my surprice when it acted > differently from expected. > We have come a long way since the days that a wrong architecture a.outwould > just coredump. > In the old days, we had ~/bin/$arch in our path to keep different > binaries, it was the days of VAX/Sun, but since i386 arrived, this has > been > forgotten. Now we are concidering to deploy amd64, and it would be nice > if it can be a 2way street - amd64 can run i386, but i386 should run the > i386 > version ... > > just blaberring before coffee. > danny It isn't very hard to do this at all. I did it as a proof-of-concept a few months ago: peter@overcee[2:18pm]/tmp/demo-218> cat foo.c #include main() { #ifdef __i386__ printf("Platform = i386\n"); #endif #ifdef __amd64__ printf("Platform = amd64\n"); #endif } peter@overcee[2:18pm]/tmp/demo-219> ./foo_i386 Platform = i386 peter@overcee[2:19pm]/tmp/demo-220> ./foo_amd64 Platform = amd64 peter@overcee[2:19pm]/tmp/demo-221> cat foo.c #include main() { #ifdef __i386__ printf("Platform = i386\n"); #endif #ifdef __amd64__ printf("Platform = amd64\n"); #endif } peter@overcee[2:19pm]/tmp/demo-222> which cc /usr/bin/cc peter@overcee[2:19pm]/tmp/demo-223> cc -o foo_amd64 foo.c peter@overcee[2:19pm]/tmp/demo-224> cc -m32 -o foo_i386 foo.c peter@overcee[2:19pm]/tmp/demo-225> file foo_* foo_amd64: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), for FreeBSD 8.0 (800006), dynamically linked (uses shared libs), FreeBSD-style, not stripped foo_i386: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), for FreeBSD 8.0 (800006), dynamically linked (uses shared libs), FreeBSD-style, not stripped peter@overcee[2:19pm]/tmp/demo-226> ./foo_i386 Platform = i386 peter@overcee[2:19pm]/tmp/demo-227> ./foo_amd64 Platform = amd64 peter@overcee[2:19pm]/tmp/demo-228> uname -m amd64 What I did was a half-dozen lines of a hack to our bmake glue for gcc. It is a hack though because I did it as specs overrides rather than have it figure the correct #include paths. This means my version doesn't interact with -nostdinc mode correctly. Doing it to correctly handle the paths isn't much harder. -Peter From owner-freebsd-current@FreeBSD.ORG Sat Jan 5 22:55:46 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 13DD116A418 for ; Sat, 5 Jan 2008 22:55:46 +0000 (UTC) (envelope-from peter@wemm.org) Received: from hu-out-0506.google.com (hu-out-0506.google.com [72.14.214.228]) by mx1.freebsd.org (Postfix) with ESMTP id 8D28113C448 for ; Sat, 5 Jan 2008 22:55:45 +0000 (UTC) (envelope-from peter@wemm.org) Received: by hu-out-0506.google.com with SMTP id 28so1015413hub.8 for ; Sat, 05 Jan 2008 14:55:44 -0800 (PST) Received: by 10.82.134.12 with SMTP id h12mr32531006bud.29.1199572780202; Sat, 05 Jan 2008 14:39:40 -0800 (PST) Received: by 10.82.182.2 with HTTP; Sat, 5 Jan 2008 14:39:40 -0800 (PST) Message-ID: Date: Sat, 5 Jan 2008 14:39:40 -0800 From: "Peter Wemm" To: "Matthew Dillon" In-Reply-To: <200801042244.m04MiI6T001926@apollo.backplane.com> MIME-Version: 1.0 References: <200801012116.m01LGQhN012860@bonkers.video-collage.com> <200801032334.m03NY7Zd019292@apollo.backplane.com> <477E82E3.6000303@bellanet.org> <477E8F10.401@samsco.org> <200801042244.m04MiI6T001926@apollo.backplane.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Mikhail Teterin , efinleywork@efinley.com, current@freebsd.org, Graham Todd Subject: Re: a new way to hang 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jan 2008 22:55:46 -0000 On 1/4/08, Matthew Dillon wrote: > > :There are better lists on which to discuss DragonflyBSD vaporware. > : > :Scott > > Not having a good new year, Scott? > > Not production ready, but certainly not vaporware. > > vkernel# cd /mnt > vkernel# echo "abcd" > charlie > vkernel# sync > vkernel# hammer now > 0x477eae02 > vkernel# rm charlie > vkernel# sync > vkernel# cat charlie@@0x477eae02 > abcd > vkernel# ls > vkernel# cd @@0x477eae02 > vkernel# ls > charlie > vkernel# cd /mnt > vkernel# echo "defgh" > charlie > vkernel# sync > vkernel# hammer now > 0x477eae89 > vkernel# echo "ijkl" > charlie > vkernel# sync > vkernel# hammer now > 0x477eae8f > vkernel# cat charlie > ijkl > vkernel# cat charlie@@0x477eae89 > defgh > vkernel# cat charlie@@0x477eae02 > abcd > vkernel# cd /mnt > vkernel# cd @@0x477eae02 > vkernel# cat charlie > abcd > vkernel# > > Not only does it work, but it works on the entire filesystem state > thank > you very much. What's with all the sync commands? Just habit? Or part of the process? -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5