From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 24 01:42:33 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 23AEF16A4CE for ; Sun, 24 Oct 2004 01:42:33 +0000 (GMT) Received: from error404.nls.net (error404.nls.net [216.144.36.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7F6E543D3F for ; Sun, 24 Oct 2004 01:42:32 +0000 (GMT) (envelope-from ketrien@error404.nls.net) Received: from [192.168.0.100] (eiterra.achedra.org [192.168.0.100]) by error404.nls.net (8.12.10/8.12.10) with ESMTP id i9O1gPqP016822; Sat, 23 Oct 2004 21:42:25 -0400 (EDT) (envelope-from ketrien@error404.nls.net) Message-ID: <417B08B5.8080208@error404.nls.net> Date: Sat, 23 Oct 2004 21:43:17 -0400 From: "Ketrien I. Saihr-Kesenchedra" User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: soralx@cydem.org, hackers@freebsd.org References: <200410132110.09915.soralx@cydem.org> <200410220216.54868.soralx@cydem.org> <20041022175311.GA15960@odin.ac.hmc.edu> <200410231047.44788.soralx@cydem.org> In-Reply-To: <200410231047.44788.soralx@cydem.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PATCH] Re: Linksys PCM200 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Oct 2004 01:42:33 -0000 soralx@cydem.org wrote: >I've done a little testing under various loads. The driver switches >chip to store and forward mode soon during initial use after attaching >(I also get few messages about watchdog timeouts together with >"increasing TX threshold"). But it seems to work OK. >I haven't done any serious performance testing (maximum speed it >could reach was ~ 5Mb/s on 100baseTX/FD) nor attach/detach tests. > > That sounds about right. I don't have time to figure out a patch, since I've not figured out if_de's quirk handling, but you may want to try treating this card like a Cobalt Networks. I'm presuming (haven't watched the thread that closely) that it's a straight MII versus Cobalt's MII-on-SIO. > <>I don't see a way how it could break other cards' functionality - > should be no concerns here D-Link isn't the only 0x00a8; The AboCom FE2500MX bears 0x13d1 0xab08. >I don't see a real reson not to use more complete description. There are few resons to use it: > >0. More info is _always_ better. In any case, the message will take 2 lines on console, so shortening the description will not gain anything > > Yes, it does. It gains readability. Long descriptions should generally be reserved for pciconf -lv and driver comments. The AL985C as found on the D-Link PCM200 should be identical to the AboCom FE2500MX. (The only difference I've seen between the two is that the FE2500MX has AboCom's VendorID. Also; AboCom makes an AL985C called the PCM200. Draw your own conclusions.) > <>1. the description in `pciconf -lv` does not show card's version and > chipset No, it doesn't, and really shouldn't. The revision is read from card SROM or set in the RevID, e.g. 0x03 or 0xa3, etcetera. > <>2. when PCI IDs for previous card versions will be added, the > description will > need to be changed anyway to include the version number Only because D-Link has a 'change everything except the model name' fetish. Unless D-Link pulled the same crap they did with the DWL-520 and DWL-650, personally I don't see any compelling reason to include chipset and revision in the dev's desc. Now, if D-Link pulled the same crap on this as they did with the DWL-520, I'd say just slap Rev.D in there; there's no need for chipset name, and it's enough to differentiate from Rev.C1 which uses some other chipset. But hey, just my $0.02USD (or ~$0.0158247EUR at current exchange rates.) -ksaihr From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 24 07:20:58 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9FAFB16A4CE for ; Sun, 24 Oct 2004 07:20:58 +0000 (GMT) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5987243D4C for ; Sun, 24 Oct 2004 07:20:58 +0000 (GMT) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1CLcgT-000DbE-Gs for hackers@freebsd.org; Sun, 24 Oct 2004 09:20:57 +0200 X-Mailer: exmh version 2.7.0 06/18/2004 with nmh-1.0.4 To: hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 24 Oct 2004 09:20:57 +0200 From: Danny Braniss Message-Id: <20041024072058.5987243D4C@mx1.FreeBSD.org> Subject: GyroPoint usb mouse X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Oct 2004 07:20:58 -0000 hi all, After some efford I got this mouse working. now, to fix the driver correctly i need some help/pointers: the attach routine gets a bit confused, it thinks the mouse has 7 buttons - i can only count 4 -, and sc_iid is set to non zero, causing all mouse events to be ignored. So can someone point me to some 'human readable docs' or specs ... thanks, danny From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 24 17:18:32 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8D24216A4CE for ; Sun, 24 Oct 2004 17:18:32 +0000 (GMT) Received: from error404.nls.net (error404.nls.net [216.144.36.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id F09BB43D45 for ; Sun, 24 Oct 2004 17:18:31 +0000 (GMT) (envelope-from ketrien@error404.nls.net) Received: from [192.168.0.100] (eiterra.achedra.org [192.168.0.100]) by error404.nls.net (8.12.10/8.12.10) with ESMTP id i9OHIIqP019901; Sun, 24 Oct 2004 13:18:18 -0400 (EDT) (envelope-from ketrien@error404.nls.net) Message-ID: <417BE411.8070500@error404.nls.net> Date: Sun, 24 Oct 2004 13:19:13 -0400 From: "Ketrien I. Saihr-Kesenchedra" User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hackers@freebsd.org, soralx@cydem.org References: <200410132110.09915.soralx@cydem.org> <200410220216.54868.soralx@cydem.org> <20041022175311.GA15960@odin.ac.hmc.edu> <200410231047.44788.soralx@cydem.org> <417B08B5.8080208@error404.nls.net> In-Reply-To: <417B08B5.8080208@error404.nls.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PATCH] Re: Linksys PCM200 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Oct 2004 17:18:32 -0000 Okay, so I got unlazy and threw some stuff together. Try these patches; this will default the PCM200 cards to store-and-forward. This might help. -ksaihr --- /usr/src/sys/pci/if_dc.c Sun Oct 24 13:09:28 2004 +++ if_dc.c Sun Oct 24 12:59:07 2004 @@ -3022,6 +3022,16 @@ } } + if (DC_IS_LINKSYS(sc)) { + /* + * The Linksys PCM200 fails into store and forward mode very quickly, + * so instead of waiting, start it there. + */ + printf("dc%d: setting card to store and forward mode\n", sc->dc_unit); + DC_SETBIT(sc, DC_NETCFG, DC_NETCFG_STORENFWD); + } + + printf("dc%d: TX underrun -- ", sc->dc_unit); sc->dc_txthresh += DC_TXTHRESH_INC; if (sc->dc_txthresh > DC_TXTHRESH_MAX) { --- /usr/src/sys/pci/if_dcreg.h Thu Aug 5 13:46:14 2004 +++ if_dcreg.h Sun Oct 24 13:09:31 2004 @@ -98,6 +98,13 @@ #define DC_IS_XIRCOM(x) (x->dc_type == DC_TYPE_XIRCOM) #define DC_IS_CONEXANT(x) (x->dc_type == DC_TYPE_CONEXANT) +/* Cards requiring specific workaround */ + /* Linksys PCM200 */ +#define DC_IS_LINKSYS(x) \ + (x->dc_type == DC_TYPE_AN985 && \ + pci_get_vendor(dev) == DC_VENDORID_LINKSYS && \ + pci_get_device(dev) == DC_DEVICEID_PCM200_AB08) + /* MII/symbol mode port types */ #define DC_PMODE_MII 0x1 #define DC_PMODE_SYM 0x2 From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 24 21:28:43 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5BA6F16A4CE for ; Sun, 24 Oct 2004 21:28:43 +0000 (GMT) Received: from cydem.org (S0106000103ce4c9c.ed.shawcable.net [68.149.254.167]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5E2B343D1D for ; Sun, 24 Oct 2004 21:28:42 +0000 (GMT) (envelope-from soralx@cydem.org) Received: from S01060020ed3972ba.ed.shawcable.net (S01060020ed3972ba.ed.shawcable.net [68.149.254.42]) by cydem.org (Postfix/FreeBSD) with ESMTP id 544D938A16 for ; Sun, 24 Oct 2004 15:28:42 -0600 (MDT) From: To: freebsd-hackers@freebsd.org Date: Sun, 24 Oct 2004 15:29:05 -0600 User-Agent: KMail/1.5.4 References: <200410132110.09915.soralx@cydem.org> <200410231047.44788.soralx@cydem.org> <417B08B5.8080208@error404.nls.net> In-Reply-To: <417B08B5.8080208@error404.nls.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200410241529.05286.soralx@cydem.org> Subject: Re: [PATCH] Re: Linksys PCM200 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Oct 2004 21:28:43 -0000 > > <>I don't see a way how it could break other cards' functionality - > > should be no concerns here > D-Link isn't the only 0x00a8; The AboCom FE2500MX bears 0x13d1 0xab08. Are there any cards that have exactly the same 32-bit PCIID, and different/modified chipsets? I didn't think that something like that is possible... Anyway, the PCM200's PCIID doesn't seem to conflict with any other card's, so I'm sure it won't break anything. > >0. More info is _always_ better. In any case, the message will take 2 > > lines on console, so shortening the description will not gain anything > Yes, it does. It gains readability. compare: dc0: port 0x1000-0x10ff mem 0x88002000-0x880023ff irq 9 at device 0.0 on cardbus1 and dc0: port 0x1000-0x10ff mem 0x88002000 -0x880023ff irq 9 at device 0.0 on cardbus1 Is the latter more readable? I think they're the same. The former is even more readable for me, because the description is on one line, and all the I/O info is on the other. Also, if I will need to send dmesg to somebody (for example, the card could create a problem by conflicting with some other hardware), they will know _exactly_ what card is it (and even if they're not familiar with this card, they'll know the chipset). > Long descriptions should generally > be reserved for pciconf -lv and driver comments. for this card, `pciconf -lv` outputs not much useful info: dc0@pci2:0:0: class=0x020000 card=0xab091737 chip=0xab091737 rev=0x11 hdr=0x00 vendor = 'Linksys' device = 'PCM200 10/100 CardBus Ethernet Adapter' Even the chipID is changed. It also does not state card's version (one will need to figure that out from revID) - and, according to info in the INet, card's versions differ between each other noticeably. > > <>2. when PCI IDs for previous card versions will be added, the > > description will > > need to be changed anyway to include the version number > > Only because D-Link has a 'change everything except the model name' > fetish. Unless D-Link pulled the same crap they did with the DWL-520 and > DWL-650, personally I don't see any compelling reason to include chipset > and revision in the dev's desc. why not? there can never be too much info :) > Now, if D-Link pulled the same crap on > this as they did with the DWL-520, I'd say just slap Rev.D in there; > there's no need for chipset name chipset name makes the dmesg message separate nicely into 2 lines :p Anyway, enough on this. I'd personally prefer to see my long description commited, but seems like the FreeBSD developers know better what to do (as they were able to create such a great OS). I'll test the store-and-fwd patch later today. I thought however, that it has to swith to that mode because my notebook (and CardBus controller) isn't fast enough. Form `man 4 dc`: dc%d: TX underrun -- increasing TX threshold The device generated a transmit underrun error while attempting to DMA and transmit a packet. This happens if the host is not able to DMA the packet data into the NIC's FIFO fast enough. Timestamp: 0x417C1321 [SorAlx] http://cydem.org.ua/ ridin' VN1500-B2 From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 25 07:38:56 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CF95416A4CE for ; Mon, 25 Oct 2004 07:38:56 +0000 (GMT) Received: from www.hexe.com.pl (www.hexe.com.pl [212.160.230.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id B45E743D1D for ; Mon, 25 Oct 2004 07:38:55 +0000 (GMT) (envelope-from clamav@www.hexe.com.pl) Received: from www.hexe.com.pl (smmsp@localhost [127.0.0.1]) i9P793Ge017038; Mon, 25 Oct 2004 09:09:06 +0200 Received: (from clamav@localhost) by www.hexe.com.pl (8.12.3/8.12.3/Debian-6.6) id i9P74WiI016900; Mon, 25 Oct 2004 09:04:32 +0200 Date: Mon, 25 Oct 2004 09:04:32 +0200 Message-Id: <200410250704.i9P74WiI016900@www.hexe.com.pl> From: To: Auto-Submitted: auto-submitted (antivirus notify) X-Infected-Received-From: aig112.neoplus.adsl.tpnet.pl [83.25.214.112] X-Virus-Scanned: clamd / ClamAV version 0.75-1, clamav-milter version 0.74a on www X-Virus-Status: Clean cc: postmaster@www.hexe.com.pl cc: bialystok@hexe.com.pl Subject: Virus intercepted X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2004 07:38:57 -0000 A message you sent to contained Worm.SomeFool.X and has not been delivered. From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 24 20:40:55 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 061EC16A4CE for ; Sun, 24 Oct 2004 20:40:55 +0000 (GMT) Received: from outbox.allstream.net (outbox.allstream.net [207.245.244.41]) by mx1.FreeBSD.org (Postfix) with ESMTP id A2EC143D39 for ; Sun, 24 Oct 2004 20:40:54 +0000 (GMT) (envelope-from epilogue@allstream.net) Received: from localhost (mon-pq54-166.dial.allstream.net [216.123.143.38]) by outbox.allstream.net (Allstream MTA) with SMTP id E2DA91D0DBF for ; Sun, 24 Oct 2004 16:40:52 -0400 (EDT) Date: Sun, 24 Oct 2004 16:40:43 -0400 From: epilogue To: freebsd-hackers@freebsd.org Message-Id: <20041024164043.0675ff16@localhost> X-Mailer: Sylpheed-Claws 0.9.12 (GTK+ 1.2.10; i386-portbld-freebsd4.10) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 25 Oct 2004 12:10:15 +0000 Subject: USB developer please look at cdce driver -- (Was: Driver for Yopy PDA) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Oct 2004 20:40:55 -0000 not even a nibble from questions@. thinking that hackers@ might be a more appropriate venue. i know that everything is hectic now with 5.3, so perhaps when the dust settles a bit... thanks. --------------------- Begin forwarded message: Date: Mon, 18 Oct 2004 16:14:49 -0400 From: epilogue To: freebsd-questions@freebsd.org Cc: Raphael Langerhorst Subject: USB developer please look at cdce driver -- (Was: Driver for Yopy PDA) hello again, i just noticed this driver turn up in the openbsd code. i'm suspecting that it might resolve pc-pda connectivity issues for some users. man: http://www.openbsd.org/cgi-bin/man.cgi?query=cdce&sektion=4 cvsweb: http://www.openbsd.org/cgi-bin/cvsweb/src/sys/dev/usb/if_cdce.c http://www.openbsd.org/cgi-bin/cvsweb/src/sys/dev/usb/if_cdcereg.h would really appreciate it if a committer glanced at the code. (...and, if meritorious, eventually ported this piece over) hopefully, this will scratch someone's itch. in the meantime, knoppix it is. =] many thanks, epi ---------- On Wed, 18 Aug 2004 09:05:16 +0200 Raphael Langerhorst wrote: > Hi, > > I'm also still very interested in this driver, so far I haven't > received any response. I hope someone takes care that it is included > in FreeBSD 5. > > Raphael > > PS: I'm not registered to the freebsd-questions list, please cc me on > reply. > > On Wednesday 18 August 2004 04:04, you wrote: > > hello all, > > > > i recently received a yopy 3500 pda (yopy.com and yopydeveloper.org) > > and have been trying very much in vain to get it to speak 'ethernet > > over usb' with my fbsd 4.10 install. > > > > the only promising *bsd related threads i have been able to locate > > were: > > > > http://lists.freebsd.org/mailman/htdig/freebsd-hardware/2004-June/001703.ht > >ml > > http://lists.freebsd.org/mailman/htdig/freebsd-hardware/2003-August/000429. > >html > > > > i am hoping to learn whether: > > > > a) the 5.x driver mentioned in these messages is on its way into > > the source tree (i did not come across any if_saue entries in > > cvsweb.cgi/src/sys/dev/usb) ? > > > > b) i can help test a version designed for 4.x ? my yopy awaits your > > command =] > > > > hopefully someone will get back to me regarding these questions. in > > the meantime, linux already has driver support for the yopy, so i'm > > going to give knoppix a try. > > > > > > thanks for reading, > > epi > > > > > > p.s. comms/birda appears to be another option for connecting to the > > machine, but i haven't yet made any headway with that tool set. > > -- > G System, the evolving universe - http://www.g-system.at > _______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 25 11:50:25 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BEB1016A529 for ; Mon, 25 Oct 2004 11:50:25 +0000 (GMT) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id EC35B43D46 for ; Mon, 25 Oct 2004 11:50:24 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (rytytm@localhost [127.0.0.1]) by lurza.secnetix.de (8.12.11/8.12.11) with ESMTP id i9PBoLAN085169; Mon, 25 Oct 2004 13:50:21 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.12.11/8.12.11/Submit) id i9PBoHl5084974; Mon, 25 Oct 2004 13:50:17 +0200 (CEST) (envelope-from olli) Date: Mon, 25 Oct 2004 13:50:17 +0200 (CEST) Message-Id: <200410251150.i9PBoHl5084974@lurza.secnetix.de> From: Oliver Fromme To: freebsd-hackers@FreeBSD.ORG, walter@belgers.com In-Reply-To: <20041022144118.GA24939@willempie.het.net.je> X-Newsgroups: list.freebsd-hackers User-Agent: tin/1.5.4-20000523 ("1959") (UNIX) (FreeBSD/4.10-RELEASE (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Mon, 25 Oct 2004 12:10:15 +0000 Subject: Re: bootable install CD - relocate to subdir X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2004 11:50:25 -0000 Walter Belgers wrote: > I am a board member of the Dutch Unix Users Group, and we would like to > make a DVD with several free/open UNIX releases together with the Dutch > Hobby Computer Club/UNIX. > > The DVD boots a program that lets the user select the OS (s)he wants to > install, and then pseudo-boots the boot image of that OS. Are you using GRUB as the boot selector, or something else? (I'm interested because I'm preparing something similar.) > Problem: all the FreeBSD files need to be in /. This clashes with other > distributions on the same DVD. I would like to have everyting in > /FreeBSD or some other subdirectory instead. > > Has anybody done such a thing before, or knows of someone who has? Yes, I've done a DVD9 with several BSD variants on it. You can put FreeBSD in a subdirectory; it does _not_ have to be in the root directory of the DVD-ROM. You don't have to hack sysinstall, it already searches several possible directory names, for example the name of the release ("5.3-RELEASE"). You can find the appropriate code at the end of the file src/*/sysinstall/media.c (where * is "release" for FreeBSD 4.x and "usr.sbin" for 5.x). In short, it searches the following directories, relative to the media base: / /FreeBSD /releases /$RELNAME /releases/$RELNAME where "$RELNAME" is the release name (e.g. "5.3-RELEASE"). Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co KG, Oettingenstr. 2, 80538 München Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "Being really good at C++ is like being really good at using rocks to sharpen sticks." -- Thant Tessman From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 25 21:29:40 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 00E1F16A4CE for ; Mon, 25 Oct 2004 21:29:40 +0000 (GMT) Received: from pcp04291529pcs.newhvn01.in.comcast.net (pcp04291529pcs.newhvn01.in.comcast.net [68.54.22.46]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9B06C43D1D for ; Mon, 25 Oct 2004 21:29:39 +0000 (GMT) (envelope-from jeremiah_holt@comcast.net) Received: from .newhvn01.in.comcast.net (localhost [127.0.0.1]) id i9PLTbFC050656 for ; Mon, 25 Oct 2004 16:29:37 -0500 (EST) (envelope-from jeremiah_holt@comcast.net) Message-ID: X-Mailer: XFMail 1.5.5 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Resent-Date: Mon, 25 Oct 2004 16:00:17 -0500 (EST) Resent-Message-Id: Resent-From: jeremiah_holt@comcast.net Resent-To: freebsd-hackers@freebsd.org Date: Mon, 25 Oct 2004 16:29:37 -0500 (EST) Sender: jjholt@.newhvn01.in.comcast.net From: jeremiah_holt@comcast.net To: freebsd-hackers@freebsd.org Subject: Fwd: CMOS Checksum error X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2004 21:29:40 -0000 -----Fwd: ----- Date: Mon, 25 Oct 2004 16:00:17 -0500 (EST) Sender: jjholt@.newhvn01.in.comcast.net From: jeremiah_holt@comcast.net To: freebsd-hackers@freebsd.org Subject: CMOS Checksum error I have a interresting problem. When I go to reboot my machine with shutdown -r or reboot. The system reboots normally until POST when I get a CMOS Checksum invalid message default settings applied. However if I use halt or shutdown -h and power off then back on I don't get the error and BIOS settings are retained. ---------------------------------- E-Mail: jeremiah_holt@comcast.net Date: 25-Oct-2004 Time: 15:55:24 This message was sent by XFMail ---------------------------------- --------------End of forwarded message------------------------- ---------------------------------- E-Mail: jeremiah_holt@comcast.net Date: 25-Oct-2004 Time: 16:29:22 This message was sent by XFMail ---------------------------------- From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 25 21:42:16 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CC24316A4CE for ; Mon, 25 Oct 2004 21:42:16 +0000 (GMT) Received: from pcp04291529pcs.newhvn01.in.comcast.net (pcp04291529pcs.newhvn01.in.comcast.net [68.54.22.46]) by mx1.FreeBSD.org (Postfix) with ESMTP id 77F5F43D3F for ; Mon, 25 Oct 2004 21:42:16 +0000 (GMT) (envelope-from jeremiah_holt@comcast.net) Received: from .newhvn01.in.comcast.net (localhost [127.0.0.1]) id i9PLgDnJ055772; Mon, 25 Oct 2004 16:42:13 -0500 (EST) (envelope-from jeremiah_holt@comcast.net) Message-ID: X-Mailer: XFMail 1.5.5 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Mon, 25 Oct 2004 16:42:13 -0500 (EST) Sender: jjholt@.newhvn01.in.comcast.net From: jeremiah_holt@comcast.net To: jeremiah_holt@comcast.net cc: freebsd-hackers@freebsd.org Subject: Re: Fwd: CMOS Checksum error X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2004 21:42:16 -0000 I hate replying to my own messages however, the problem occurs in both 4.10 and 5.3-RELEASE The system is a Compaq Presario with VIA apollo chipset with a pentiumIII 500MHz with 320MB of RAM On 25-Oct-2004 jeremiah_holt@comcast.net wrote: > > -----Fwd: ----- > > Date: Mon, 25 Oct 2004 16:00:17 -0500 (EST) > Sender: jjholt@.newhvn01.in.comcast.net > From: jeremiah_holt@comcast.net > To: freebsd-hackers@freebsd.org > Subject: CMOS Checksum error > > I have a interresting problem. When I go to reboot my machine > with shutdown -r or reboot. The system reboots normally > until POST when I get a CMOS Checksum invalid message default > settings applied. However if I use halt or shutdown -h > and power off then back on I don't get the error and BIOS settings > are retained. > > ---------------------------------- > E-Mail: jeremiah_holt@comcast.net > Date: 25-Oct-2004 > Time: 15:55:24 > > This message was sent by XFMail > ---------------------------------- > > --------------End of forwarded message------------------------- > > ---------------------------------- > E-Mail: jeremiah_holt@comcast.net > Date: 25-Oct-2004 > Time: 16:29:22 > > This message was sent by XFMail > ---------------------------------- > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" ---------------------------------- E-Mail: jeremiah_holt@comcast.net Date: 25-Oct-2004 Time: 16:39:26 This message was sent by XFMail ---------------------------------- From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 26 00:55:41 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E504C16A4CE for ; Tue, 26 Oct 2004 00:55:41 +0000 (GMT) Received: from beck.quonix.net (beck.quonix.net [146.145.66.90]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4564E43D1D for ; Tue, 26 Oct 2004 00:55:41 +0000 (GMT) (envelope-from john@essenz.com) Received: from [192.168.1.100] (pool-151-197-57-65.phil.east.verizon.net [151.197.57.65]) by beck.quonix.net (8.12.11/8.12.11) with ESMTP id i9Q0tZqM004230; Mon, 25 Oct 2004 20:55:35 -0400 (EDT) In-Reply-To: <20041009044403.P39589-100000@mxb.saturn-tech.com> References: <20041009044403.P39589-100000@mxb.saturn-tech.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <76A94E35-26E8-11D9-839A-0003933DDCFA@essenz.com> Content-Transfer-Encoding: 7bit From: John Von Essen Date: Mon, 25 Oct 2004 20:46:24 -0400 To: Doug Russell X-Mailer: Apple Mail (2.619) X-SpamAssassin-2.64-Score: 0.5/6 RCVD_IN_NJABL_DUL,RCVD_IN_SORBS_DUL X-MimeDefang-2.44: beck.quonix.net X-Scanned-By: MIMEDefang 2.44 cc: freebsd-hackers@freebsd.org Subject: Re: hacking SCO.... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2004 00:55:42 -0000 This may be a dumb question, but if you make a cpio tape archive from data on an SCO system (HTFS filesystem), you can still restore the data off the tape to another system, like FreeBSD with a UFS filesystem, right? And the followup, can FreeBSD run SCO binaries (SCO Unix 5.0.1)? I am going to try and convert these people from their SCO box over to a FreeBSD system. Just want to make sure the data will come off the tape. -John On Oct 9, 2004, at 6:51 AM, Doug Russell wrote: > > On Fri, 8 Oct 2004, Sergey Babkin wrote: > >> Try to use the "Verify" menu from the Adaptec BIOS. It finds and tries >> to re-map the bad sectors (it tries to preserve data during this too, >> unless the sector is completely unreadable). > > The verify commands issued by the BIOS are virtually useless compared > to > the type of tests done my sformat. If you enable automatic read > re-allocation, it is almost the same as simply reading your whole disk > with dd. > >>> I do the full 14 pattern tests before I put a SCSI disk in service. >> >> When a disk starts losing blocks like this, usually they only multiply >> over time. The best thing you can do is replace the disk and >> move the data before you lost more of it. > > NO! Not necessarily! > > If a disk has simply grown a few new defects since it was new, it does > not > necessarily mean it is going to die. I have many disks that had minor > bad > spots on them that weren't even always found by the factory format > routines, or had appeared since (due to transport, debris in the HDA, > poor > holding power for the magnetic fields in some area, etc). If the drive > passes through a few full patern tests without problems and doesn't > continue to grow new defects, it is likely just fine. > > I've got all kinds of old SCSI disks that were 'discarded' due to > errors. > Only a couple are truly dead... the rest have been running for years > with > no problems after making a real grown defect list from the pattern > tests. > > This is something I learned many many years ago when running my old > Miniscribe 3650s on a Perstor high density controller. It formated the > drives to 31 sectors per track instead of 17. Hard on the disks, and > the > media, but a good drive, after being properly tested, would run > flawlessly > for years being hammered 24/7 on BBS machines. Got 78 megs per drive > instead of 42.whatever it was. :) > > Later...... > > > John Von Essen (john@essenz.com) President, Essenz Consulting (www.essenz.com) Phone: (800) 248-1736 Fax: (800) 852-3387 From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 26 02:22:21 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 207B216A4CE for ; Tue, 26 Oct 2004 02:22:21 +0000 (GMT) Received: from skippyii.compar.com (www.compar.com [216.208.38.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7F94643D46 for ; Tue, 26 Oct 2004 02:22:20 +0000 (GMT) (envelope-from matt@gsicomp.on.ca) Received: from hermes (CPE00062566c7bb-CM000039c69a66.cpe.net.cable.rogers.com [69.193.82.185])i9Q2Sjhg014433; Mon, 25 Oct 2004 22:28:50 -0400 (EDT) (envelope-from matt@gsicomp.on.ca) Message-ID: <001f01c4bb02$39602ef0$1200a8c0@gsicomp.on.ca> From: "Matt Emmerton" To: "John Von Essen" , "Doug Russell" References: <20041009044403.P39589-100000@mxb.saturn-tech.com> <76A94E35-26E8-11D9-839A-0003933DDCFA@essenz.com> Date: Mon, 25 Oct 2004 22:19:17 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 cc: freebsd-hackers@freebsd.org Subject: Re: hacking SCO.... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2004 02:22:21 -0000 > This may be a dumb question, but if you make a cpio tape archive from > data on an SCO system (HTFS filesystem), you can still restore the data > off the tape to another system, like FreeBSD with a UFS filesystem, > right? This should work. If you run into any issues they will be incompatibilities between SCO's cpio and the GNU cpio that FreeBSD uses. > And the followup, can FreeBSD run SCO binaries (SCO Unix 5.0.1)? I am > going to try and convert these people from their SCO box over to a > FreeBSD system. Just want to make sure the data will come off the tape. Yes, but support is really limited. You need to copy a bunch of core libraries onto the FreeBSD machine from the SCO machine to make things work. (We just emulate the syscall interface -- you need libc and friends from SCO.) Matt > > -John > > On Oct 9, 2004, at 6:51 AM, Doug Russell wrote: > > > > > On Fri, 8 Oct 2004, Sergey Babkin wrote: > > > >> Try to use the "Verify" menu from the Adaptec BIOS. It finds and tries > >> to re-map the bad sectors (it tries to preserve data during this too, > >> unless the sector is completely unreadable). > > > > The verify commands issued by the BIOS are virtually useless compared > > to > > the type of tests done my sformat. If you enable automatic read > > re-allocation, it is almost the same as simply reading your whole disk > > with dd. > > > >>> I do the full 14 pattern tests before I put a SCSI disk in service. > >> > >> When a disk starts losing blocks like this, usually they only multiply > >> over time. The best thing you can do is replace the disk and > >> move the data before you lost more of it. > > > > NO! Not necessarily! > > > > If a disk has simply grown a few new defects since it was new, it does > > not > > necessarily mean it is going to die. I have many disks that had minor > > bad > > spots on them that weren't even always found by the factory format > > routines, or had appeared since (due to transport, debris in the HDA, > > poor > > holding power for the magnetic fields in some area, etc). If the drive > > passes through a few full patern tests without problems and doesn't > > continue to grow new defects, it is likely just fine. > > > > I've got all kinds of old SCSI disks that were 'discarded' due to > > errors. > > Only a couple are truly dead... the rest have been running for years > > with > > no problems after making a real grown defect list from the pattern > > tests. > > > > This is something I learned many many years ago when running my old > > Miniscribe 3650s on a Perstor high density controller. It formated the > > drives to 31 sectors per track instead of 17. Hard on the disks, and > > the > > media, but a good drive, after being properly tested, would run > > flawlessly > > for years being hammered 24/7 on BBS machines. Got 78 megs per drive > > instead of 42.whatever it was. :) > > > > Later...... > > > > > > > John Von Essen (john@essenz.com) > President, Essenz Consulting (www.essenz.com) > Phone: (800) 248-1736 > Fax: (800) 852-3387 > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 26 02:42:38 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 71F1916A4CE for ; Tue, 26 Oct 2004 02:42:38 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2A0DC43D1F for ; Tue, 26 Oct 2004 02:42:37 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (harmony.village.org [10.0.0.6]) by harmony.village.org (8.13.1/8.13.1) with ESMTP id i9Q2dS83040759; Mon, 25 Oct 2004 20:39:44 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 25 Oct 2004 20:40:00 -0600 (MDT) Message-Id: <20041025.204000.118529340.imp@bsdimp.com> To: jeremiah_holt@comcast.net From: "M. Warner Losh" In-Reply-To: References: X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org Subject: Re: CMOS Checksum error X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2004 02:42:38 -0000 In message: jeremiah_holt@comcast.net writes: : I have a interresting problem. When I go to reboot my machine : with shutdown -r or reboot. The system reboots normally : until POST when I get a CMOS Checksum invalid message default : settings applied. However if I use halt or shutdown -h : and power off then back on I don't get the error and BIOS settings : are retained. Sounds like a dead CMOS battery in an older system. Or at least a marginal one. Warner From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 26 10:14:48 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F071E16A4CE; Tue, 26 Oct 2004 10:14:47 +0000 (GMT) Received: from asterix.rsu.ru (relay.r61.net [195.208.245.250]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1F6B343D41; Tue, 26 Oct 2004 10:14:46 +0000 (GMT) (envelope-from bushman@rsu.ru) Received: from [195.208.252.82] (stinger.cc.rsu.ru [195.208.252.82]) by asterix.rsu.ru (8.13.1/8.13.1) with ESMTP id i9QAEb56015953; Tue, 26 Oct 2004 14:14:37 +0400 (MSD) (envelope-from bushman@rsu.ru) From: Michael Bushkov To: hackers@freebsd.org Content-Type: multipart/mixed; boundary="=-NBIlVcBobXF4E8EHBWGR" Organization: Rostov State University Message-Id: <1098785868.61417.39.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 26 Oct 2004 14:17:49 +0400 X-Spam-Status: No, hits=-104.8 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=2.64 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on asterix.rsu.ru cc: "Jacques A. Vidrine" cc: "Christian S.J. Peron" Subject: nsdispatch services patch + lookupd X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: bushman@rsu.ru List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2004 10:14:48 -0000 --=-NBIlVcBobXF4E8EHBWGR Content-Type: text/plain Content-Transfer-Encoding: 7bit Hello! I've been asking to commit nsdispatch services patch (the patch, which makes getserv* functions run over nsdispatch interface) since the middle of summer. And it's still not committed. The problem is that the next release of the lookupd daemon (which i support) depends on this patch, as it implements 'services' data source. I've included the patch once again here. Is it possible to commit it in the nearest future? P.S. Patch should be applied in /usr/src/lib/libc/net. -- Michael Bushkov Rostov State University --=-NBIlVcBobXF4E8EHBWGR Content-Disposition: attachment; filename=getserv.patch Content-Type: text/x-patch; name=getserv.patch; charset=KOI8-R Content-Transfer-Encoding: 7bit *** ./initial/getservent.c Wed Jul 14 18:06:32 2004 --- getservent.c Thu Jul 15 13:21:01 2004 *************** *** 29,44 **** --- 29,49 ---- * 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. */ + /* + * getserv* functions implementation was adapted to nsswitch model by Michael Bushkov + */ + #if defined(LIBC_SCCS) && !defined(lint) static char sccsid[] = "@(#)getservent.c 8.1 (Berkeley) 6/4/93"; #endif /* LIBC_SCCS and not lint */ #include __FBSDID("$FreeBSD: src/lib/libc/net/getservent.c,v 1.12 2003/02/27 13:40:00 nectar Exp $"); + #include "namespace.h" #include #include #include #include #include *************** *** 46,91 **** #include #ifdef YP #include #include #include - static int serv_stepping_yp = 0; #endif #include "libc_private.h" #define MAXALIASES 35 ! static FILE *servf = NULL; ! static char line[BUFSIZ+1]; ! static struct servent serv; ! static char *serv_aliases[MAXALIASES]; ! int _serv_stayopen; #ifdef YP ! char *___getservbyname_yp = NULL; ! char *___getservbyproto_yp = NULL; ! int ___getservbyport_yp = 0; ! static char *yp_domain = NULL; static int ! _getservbyport_yp(line) ! char *line; { char *result; int resultlen; char buf[YPMAXRECORD + 2]; int rv; ! snprintf(buf, sizeof(buf), "%d/%s", ntohs(___getservbyport_yp), ! ___getservbyproto_yp); ! ___getservbyport_yp = 0; ! ___getservbyproto_yp = NULL; ! if(!yp_domain) { ! if(yp_get_default_domain(&yp_domain)) ! return (0); } /* * We have to be a little flexible here. Ideally you're supposed * to have both a services.byname and a services.byport map, but --- 51,602 ---- #include #ifdef YP #include #include #include #endif + #include + #include + #include + #include #include "libc_private.h" + #include "nss_tls.h" #define MAXALIASES 35 ! /* ! * declarations' beginning ! */ ! #define _SERVENT_UNPACK_AGAIN -1 ! #define _SERVENT_UNPACK_RETURN 0 ! ! static const ns_src defaultsrc[] = { ! { NSSRC_COMPAT, NS_SUCCESS }, ! { 0 } ! }; ! ! ! struct files_state { ! FILE * servf; ! char line[BUFSIZ+1]; ! struct servent serv; ! char *serv_aliases[MAXALIASES]; ! int _serv_stayopen; ! ! int _notfound_block; ! }; ! ! static void files_endstate(void * files_state); ! NSS_TLS_HANDLING(files); ! ! static int _files_setservent(void *, void *, va_list); ! static int _files_endservent(void *, void *, va_list); ! static int _files_getservent(void *, void *, va_list); ! static int _files_getservbyname(void *, void *, va_list); ! static int _files_getservbyport(void *, void *, va_list); ! ! #ifdef YP ! struct nis_state { ! char *yp_domain; ! int serv_stepping_yp; ! ! char *key; ! int keylen; ! ! char line[BUFSIZ+1]; ! struct servent serv; ! char *serv_aliases[MAXALIASES]; ! ! int _notfound_block; ! }; ! ! static void nis_endstate(void * nis_state); ! NSS_TLS_HANDLING(nis); ! ! static int _nis_setservent(void *, void *, va_list); ! static int _nis_endservent(void *, void *, va_list); ! static int _nis_getservent(void *, void *, va_list); ! static int _nis_getservbyname(void *, void *, va_list); ! static int _nis_getservbyport(void *, void *, va_list); ! #endif ! ! /* ! * indicates what source is currently used by compat mode ! */ ! enum compat_condition { ! FILES_STATE = 0 ! #ifdef YP ! , NIS_STATE = 1 ! #endif ! }; ! ! /* ! * compat mode uses existing files_state and nis_state structures, because it ! * should combine files and nis modules functionality ! */ ! struct compat_state { ! struct files_state files_st; ! #ifdef YP ! struct nis_state nis_st; ! #endif ! ! enum compat_condition current_condition; ! }; ! ! static void compat_endstate(void * compat_state); ! NSS_TLS_HANDLING(compat); ! ! static int _compat_setservent(void *, void *, va_list); ! static int _compat_endservent(void *, void *, va_list); ! static int _compat_getservent(void *, void *, va_list); ! static int _compat_getservbyname(void *, void *, va_list); ! static int _compat_getservbyport(void *, void *, va_list); ! ! /* ! * declarations' ending ! */ ! ! /* ! * processes the line, pointed by p and fills the dest structure ! * q is the pointer, which should be kept during one service entry ! * traversal ! */ ! static int ! _servent_unpack(struct servent * dest,char ** serv_aliases, char *p, char *** q) ! { ! char *cp; ! ! if (*p == '#') ! return _SERVENT_UNPACK_AGAIN; ! cp = strpbrk(p, "#\n"); ! if (cp == NULL) ! return _SERVENT_UNPACK_AGAIN; ! *cp = '\0'; ! dest->s_name = p; ! p = strpbrk(p, " \t"); ! if (p == NULL) ! return _SERVENT_UNPACK_AGAIN; ! *p++ = '\0'; ! while (*p == ' ' || *p == '\t') ! p++; ! cp = strpbrk(p, ",/"); ! if (cp == NULL) ! return _SERVENT_UNPACK_AGAIN; ! *cp++ = '\0'; ! dest->s_port = htons((u_short)atoi(p)); ! dest->s_proto = cp; ! *q = dest->s_aliases = serv_aliases; ! cp = strpbrk(cp, " \t"); ! if (cp != NULL) ! *cp++ = '\0'; ! while (cp && *cp) { ! if (*cp == ' ' || *cp == '\t') { ! cp++; ! continue; ! } ! if (*q < &(serv_aliases)[MAXALIASES - 1]) ! *(*q)++ = cp; ! cp = strpbrk(cp, " \t"); ! if (cp != NULL) ! *cp++ = '\0'; ! } ! ! *(*q) = NULL; ! return _SERVENT_UNPACK_RETURN; ! } ! ! ! static void ! files_endstate(void * p) ! { ! FILE * f; ! ! if (p == NULL) ! return; ! f = ((struct files_state *)p)->servf; ! if (f != NULL) ! fclose(f); ! free(p); ! } ! ! /* ! * gets compat's files state if we are in compat mode and global files state otherwise ! */ ! static int ! _get_compat_files_state(struct files_state ** state,void * mdata) ! { ! int rv; ! enum compat_condition * current_condition; ! ! current_condition=(enum compat_condition *)mdata; ! if (current_condition==NULL) { ! rv=files_getstate(state); ! if (rv != 0) ! return -1; ! } else { ! struct compat_state * c_st; ! ! rv=compat_getstate(&c_st); ! if (rv !=0) ! return -1; ! ! *state=&c_st->files_st; ! } ! return 0; ! } ! ! /* ! * changes compat_condition state, passed as mdata pointer ! */ ! static int ! _redispatch_to_nis(void * mdata) ! { ! #ifdef YP ! if (mdata==NULL) ! return -1; ! else { ! enum compat_condition * current_condition; ! current_condition=(enum compat_condition *)mdata; ! *current_condition=NIS_STATE; ! return 0; ! } ! #else ! return -1; ! #endif ! } ! ! static int ! _files_setservent(void *retval, void *mdata, va_list ap) ! { ! struct files_state * st; ! int f, rv; ! ! f = va_arg(ap, int); ! rv=_get_compat_files_state(&st,mdata); ! if (rv != 0) ! return (NS_UNAVAIL); ! ! if (st->servf == NULL) ! st->servf = fopen(_PATH_SERVICES, "r" ); ! else ! rewind(st->servf); ! st->_serv_stayopen |= f; ! st->_notfound_block = 0; ! ! return (NS_UNAVAIL); ! } ! ! static int ! _files_endservent(void *retval, void *mdata, va_list ap) ! { ! int rv; ! struct files_state * st; ! ! rv=_get_compat_files_state(&st,mdata); ! if (rv != 0) ! return (NS_UNAVAIL); ! ! if (st->servf) { ! fclose(st->servf); ! st->servf = NULL; ! } ! st->_serv_stayopen = 0; ! st->_notfound_block=0; ! ! return (NS_UNAVAIL); ! } ! ! static int ! _files_getservent(void *retval, void *mdata, va_list ap) ! { ! int rv; ! struct files_state * st; ! ! char *p, **q; ! int parse_retval=_SERVENT_UNPACK_RETURN; ! ! rv=_get_compat_files_state(&st,mdata); ! if (rv != 0) ! return (NS_UNAVAIL); ! ! if (st->_notfound_block!=0) ! return (NS_NOTFOUND); ! ! if (st->servf == NULL && (st->servf = fopen(_PATH_SERVICES, "r" )) == NULL) ! return (NS_UNAVAIL); ! ! do { ! if ((p = fgets(st->line, BUFSIZ, st->servf)) == NULL) { ! st->_notfound_block=1; ! return (NS_NOTFOUND); ! } ! ! if (*p=='+') { ! if (_redispatch_to_nis(mdata)==0) ! return (NS_UNAVAIL); ! else { ! parse_retval=_SERVENT_UNPACK_AGAIN; ! continue; ! } ! } ! ! parse_retval=_servent_unpack(&st->serv,st->serv_aliases,p,&q); ! } while (parse_retval==_SERVENT_UNPACK_AGAIN); ! ! *(struct servent **)retval=&st->serv; ! return (NS_SUCCESS); ! } ! ! static int ! _files_getservbyname(void *retval, void *mdata, va_list ap) ! { ! struct files_state * st; ! int rv; ! ! char *curline, **q; ! int parse_retval=_SERVENT_UNPACK_RETURN; ! ! struct servent *p; ! char **cp; ! ! const char * name; ! const char * proto; ! ! name = va_arg(ap, const char *); ! proto = va_arg(ap, const char *); ! ! rv=_get_compat_files_state(&st,mdata); ! if (rv != 0) ! return (NS_UNAVAIL); ! ! /* setservent analog */ ! if (st->servf == NULL) ! st->servf = fopen(_PATH_SERVICES, "r" ); ! else ! rewind(st->servf); ! ! for (;;) { ! do { ! if ((curline = fgets(st->line, BUFSIZ, st->servf)) == NULL) ! return (NS_NOTFOUND); ! ! if (*curline=='+') { ! if ((mdata!=NULL) && (_nis_getservbyname(retval,mdata,ap)==(NS_SUCCESS))) { ! if (!st->_serv_stayopen) ! _files_endservent(retval,mdata,ap); ! return (NS_SUCCESS); ! } else ! continue; ! } ! ! parse_retval=_servent_unpack(&st->serv,st->serv_aliases,curline,&q); ! } while (parse_retval==_SERVENT_UNPACK_AGAIN); ! ! p=&(st->serv); ! ! if (strcmp(name, p->s_name) == 0) ! goto gotname; ! for (cp = p->s_aliases; *cp; cp++) ! if (strcmp(name, *cp) == 0) ! goto gotname; ! ! continue; ! ! gotname: ! if (proto == 0 || strcmp(p->s_proto, proto) == 0) ! break; ! } ! ! if (!st->_serv_stayopen) ! _files_endservent(retval,mdata,ap); ! ! if (p==NULL) ! return (NS_NOTFOUND); ! else { ! *(struct servent **)retval=&st->serv; ! return (NS_SUCCESS); ! } ! } ! ! static int ! _files_getservbyport(void *retval, void *mdata, va_list ap) ! { ! struct files_state * st; ! int rv; ! ! char *curline, **q; ! int parse_retval=_SERVENT_UNPACK_RETURN; ! ! int port; ! const char * proto; ! ! struct servent *p; ! ! port = va_arg(ap, int); ! proto = va_arg(ap, const char *); ! ! rv=_get_compat_files_state(&st,mdata); ! if (rv != 0) ! return (NS_UNAVAIL); ! ! /* setservent analog */ ! if (st->servf == NULL) ! st->servf = fopen(_PATH_SERVICES, "r" ); ! else ! rewind(st->servf); ! ! for (;;) { ! do { ! if ((curline = fgets(st->line, BUFSIZ, st->servf)) == NULL) ! return (NS_NOTFOUND); ! ! if (*curline=='+') { ! if ((mdata!=NULL) && (_nis_getservbyport(retval,mdata,ap)==(NS_SUCCESS))) { ! if (!st->_serv_stayopen) ! _files_endservent(retval,mdata,ap); ! return (NS_SUCCESS); ! } else ! continue; ! } ! ! parse_retval=_servent_unpack(&st->serv,st->serv_aliases,curline,&q); ! } while (parse_retval==_SERVENT_UNPACK_AGAIN); ! ! ! p=&(st->serv); ! ! if (p->s_port != port) ! continue; ! if (proto == 0 || strcmp(p->s_proto, proto) == 0) ! break; ! } ! ! if (!st->_serv_stayopen) ! _files_endservent(retval,mdata,ap); ! ! if (p==NULL) ! return (NS_NOTFOUND); ! else { ! *(struct servent **)retval=&(st->serv); ! return (NS_SUCCESS); ! } ! } ! #ifdef YP ! ! static void ! nis_endstate(void * p) ! { ! struct nis_state * st; ! if (p == NULL) ! return; ! ! ! st=(struct nis_state *)p; ! if (st->key) ! free(st->key); ! free(p); ! } ! ! /* ! * gets compat's nis state if we are in compat mode and global nis state otherwise ! */ ! static int ! _get_compat_nis_state(struct nis_state ** state,void * mdata) ! { ! int rv; ! enum compat_condition * current_condition; ! ! current_condition=(enum compat_condition *)mdata; ! if (current_condition==NULL) { ! rv=nis_getstate(state); ! if (rv != 0) ! return -1; ! } else { ! struct compat_state * c_st; ! ! rv=compat_getstate(&c_st); ! if (rv !=0) ! return -1; ! ! *state=&c_st->nis_st; ! } ! return 0; ! } static int ! _nis_getservbyname(void *retval, void *mdata, va_list ap) { + char ** q; char *result; int resultlen; char buf[YPMAXRECORD + 2]; + + const char * name; + const char * proto; + + struct nis_state * st; int rv; ! rv=_get_compat_nis_state(&st,mdata); ! if (rv != 0) ! return (NS_UNAVAIL); ! ! name = va_arg(ap, const char *); ! proto = va_arg(ap, const char *); ! ! if(!st->yp_domain) { ! if(yp_get_default_domain(&st->yp_domain)) ! return (NS_UNAVAIL); ! } ! snprintf(buf, sizeof(buf), "%s/%s", name, proto); ! if (yp_match(st->yp_domain, "services.byname", buf, strlen(buf), ! &result, &resultlen)) { ! return(NS_NOTFOUND); ! } ! ! /* getservent() expects lines terminated with \n -- make it happy */ ! snprintf(st->line, BUFSIZ, "%.*s\n", resultlen, result); ! free(result); ! ! if (_servent_unpack(&st->serv,st->serv_aliases,st->line,&q)!=_SERVENT_UNPACK_RETURN) ! return (NS_UNAVAIL); ! ! *(struct servent **)retval=&st->serv; ! return (NS_SUCCESS); ! } ! ! static int ! _nis_getservbyport(void *retval, void *mdata, va_list ap) ! { ! char ** q; ! ! int port; ! const char * proto; ! ! char *result; ! int resultlen; ! char buf[YPMAXRECORD + 2]; ! int rv; ! ! struct nis_state * st; ! rv=_get_compat_nis_state(&st,mdata); ! if (rv != 0) ! return (NS_UNAVAIL); ! ! port = va_arg(ap, int); ! proto = va_arg(ap, const char *); ! ! snprintf(buf, sizeof(buf), "%d/%s", ntohs(port), ! proto); ! ! if(!st->yp_domain) { ! if(yp_get_default_domain(&st->yp_domain)) ! return (NS_UNAVAIL); } /* * We have to be a little flexible here. Ideally you're supposed * to have both a services.byname and a services.byport map, but *************** *** 93,280 **** * by putting the services.byport information in the same map as * services.byname so that either case will work. We allow for both * possibilities here: if there is no services.byport map, we try * services.byname instead. */ ! if ((rv = yp_match(yp_domain, "services.byport", buf, strlen(buf), &result, &resultlen))) { if (rv == YPERR_MAP) { ! if (yp_match(yp_domain, "services.byname", buf, strlen(buf), &result, &resultlen)) ! return(0); } else ! return(0); } /* getservent() expects lines terminated with \n -- make it happy */ ! snprintf(line, BUFSIZ, "%.*s\n", resultlen, result); ! free(result); ! return(1); } static int ! _getservbyname_yp(line) ! char *line; { ! char *result; ! int resultlen; ! char buf[YPMAXRECORD + 2]; ! ! if(!yp_domain) { ! if(yp_get_default_domain(&yp_domain)) ! return (0); ! } ! snprintf(buf, sizeof(buf), "%s/%s", ___getservbyname_yp, ! ___getservbyproto_yp); ! ___getservbyname_yp = 0; ! ___getservbyproto_yp = NULL; ! if (yp_match(yp_domain, "services.byname", buf, strlen(buf), ! &result, &resultlen)) { ! return(0); ! } ! /* getservent() expects lines terminated with \n -- make it happy */ ! snprintf(line, BUFSIZ, "%.*s\n", resultlen, result); ! ! free(result); ! return(1); } static int ! _getservent_yp(line) ! char *line; { ! static char *key = NULL; ! static int keylen; char *lastkey, *result; int resultlen; int rv; ! if(!yp_domain) { ! if(yp_get_default_domain(&yp_domain)) ! return (0); } ! if (!serv_stepping_yp) { ! if (key) ! free(key); ! if ((rv = yp_first(yp_domain, "services.byname", &key, &keylen, &result, &resultlen))) { ! serv_stepping_yp = 0; ! return(0); ! } ! serv_stepping_yp = 1; } else { ! lastkey = key; ! rv = yp_next(yp_domain, "services.byname", key, keylen, &key, ! &keylen, &result, &resultlen); free(lastkey); if (rv) { ! serv_stepping_yp = 0; ! return (0); } } /* getservent() expects lines terminated with \n -- make it happy */ ! snprintf(line, BUFSIZ, "%.*s\n", resultlen, result); ! free(result); ! return(1); } #endif ! void ! setservent(f) ! int f; { ! if (servf == NULL) ! servf = fopen(_PATH_SERVICES, "r" ); else ! rewind(servf); ! _serv_stayopen |= f; } void ! endservent() { ! if (servf) { ! fclose(servf); ! servf = NULL; ! } ! _serv_stayopen = 0; } ! struct servent * ! getservent() { ! char *p; ! char *cp, **q; #ifdef YP ! if (serv_stepping_yp && _getservent_yp(line)) { ! p = (char *)&line; ! goto unpack; ! } ! tryagain: ! #endif ! if (servf == NULL && (servf = fopen(_PATH_SERVICES, "r" )) == NULL) ! return (NULL); ! again: ! if ((p = fgets(line, BUFSIZ, servf)) == NULL) ! return (NULL); ! #ifdef YP ! if (*p == '+' && _yp_check(NULL)) { ! if (___getservbyname_yp != NULL) { ! if (!_getservbyname_yp(line)) ! goto tryagain; ! } ! else if (___getservbyport_yp != 0) { ! if (!_getservbyport_yp(line)) ! goto tryagain; ! } ! else if (!_getservent_yp(line)) ! goto tryagain; ! } ! unpack: #endif ! if (*p == '#') ! goto again; ! cp = strpbrk(p, "#\n"); ! if (cp == NULL) ! goto again; ! *cp = '\0'; ! serv.s_name = p; ! p = strpbrk(p, " \t"); ! if (p == NULL) ! goto again; ! *p++ = '\0'; ! while (*p == ' ' || *p == '\t') ! p++; ! cp = strpbrk(p, ",/"); ! if (cp == NULL) ! goto again; ! *cp++ = '\0'; ! serv.s_port = htons((u_short)atoi(p)); ! serv.s_proto = cp; ! q = serv.s_aliases = serv_aliases; ! cp = strpbrk(cp, " \t"); ! if (cp != NULL) ! *cp++ = '\0'; ! while (cp && *cp) { ! if (*cp == ' ' || *cp == '\t') { ! cp++; ! continue; ! } ! if (q < &serv_aliases[MAXALIASES - 1]) ! *q++ = cp; ! cp = strpbrk(cp, " \t"); ! if (cp != NULL) ! *cp++ = '\0'; ! } ! *q = NULL; ! return (&serv); } --- 604,950 ---- * by putting the services.byport information in the same map as * services.byname so that either case will work. We allow for both * possibilities here: if there is no services.byport map, we try * services.byname instead. */ ! if ((rv = yp_match(st->yp_domain, "services.byport", buf, strlen(buf), &result, &resultlen))) { if (rv == YPERR_MAP) { ! if (yp_match(st->yp_domain, "services.byname", buf, strlen(buf), &result, &resultlen)) ! return(NS_NOTFOUND); } else ! return(NS_NOTFOUND); } /* getservent() expects lines terminated with \n -- make it happy */ ! snprintf(st->line, BUFSIZ, "%.*s\n", resultlen, result); free(result); ! ! if (_servent_unpack(&st->serv,st->serv_aliases,st->line,&q)!=_SERVENT_UNPACK_RETURN) ! return (NS_UNAVAIL); ! ! *(struct servent **)retval=&st->serv; ! return (NS_SUCCESS); } static int ! _nis_setservent(void *retval, void *mdata, va_list ap) { ! struct nis_state * st; ! int rv; ! rv=_get_compat_nis_state(&st,mdata); ! if (rv != 0) ! return (NS_UNAVAIL); ! ! st->serv_stepping_yp=0; ! st->_notfound_block=0; ! return (NS_UNAVAIL); ! } ! static int ! _nis_endservent(void *retval, void *mdata, va_list ap) ! { ! struct nis_state * st; ! int rv; ! rv=_get_compat_nis_state(&st,mdata); ! if (rv != 0) ! return (NS_UNAVAIL); ! st->yp_domain=NULL; ! st->serv_stepping_yp=0; ! st->_notfound_block=0; ! return (NS_UNAVAIL); } static int ! _nis_getservent(void *retval, void *mdata, va_list ap) { ! struct nis_state * st; ! ! char *p,**q; ! char *lastkey, *result; int resultlen; int rv; ! rv=_get_compat_nis_state(&st,mdata); ! if (rv != 0) ! return (NS_UNAVAIL); ! ! if (st->_notfound_block!=0) ! return (NS_NOTFOUND); ! ! if(!st->yp_domain) { ! if(yp_get_default_domain(&st->yp_domain)) ! return (NS_UNAVAIL); } ! if (!st->serv_stepping_yp) { ! if (st->key) ! free(st->key); ! if ((rv = yp_first(st->yp_domain, "services.byname", &st->key, &st->keylen, &result, &resultlen))) { ! st->serv_stepping_yp = 0; ! return(NS_NOTFOUND); ! } else ! st->serv_stepping_yp = 1; } else { ! lastkey = st->key; ! rv = yp_next(st->yp_domain, "services.byname", st->key, st->keylen, &st->key, ! &st->keylen, &result, &resultlen); free(lastkey); if (rv) { ! st->serv_stepping_yp = 0; ! st->_notfound_block=1; ! return (NS_NOTFOUND); } } /* getservent() expects lines terminated with \n -- make it happy */ ! snprintf(st->line, BUFSIZ, "%.*s\n", resultlen, result); free(result); ! p=st->line; ! if (_servent_unpack(&st->serv,st->serv_aliases,p,&q)!=_SERVENT_UNPACK_RETURN) ! return (NS_UNAVAIL); ! ! *(struct servent **)retval=&st->serv; ! return(NS_SUCCESS); } + #endif + + static void + compat_endstate(void * p) + { + struct compat_state * st; + if (p == NULL) + return; ! st=(struct compat_state *)p; ! if (st->files_st.servf!=NULL) ! fclose(st->files_st.servf); ! #ifdef YP ! if (st->nis_st.key!=NULL) ! free(st->nis_st.key); ! #endif ! free(p); ! } ! ! static int ! _compat_setservent(void *retval, void *mdata, va_list ap) { ! struct compat_state * st; ! int rv; ! ! rv=compat_getstate(&st); ! if (rv != 0) ! return (NS_UNAVAIL); ! ! _files_setservent(retval,&st->current_condition,ap); ! #ifdef YP ! _nis_setservent(retval,&st->current_condition,ap); ! st->current_condition=FILES_STATE; ! #endif ! return (NS_UNAVAIL); ! } ! ! static int ! _compat_endservent(void *retval, void *mdata, va_list ap) ! { ! struct compat_state * st; ! int rv; ! ! rv=compat_getstate(&st); ! if (rv != 0) ! return (NS_UNAVAIL); ! ! _files_endservent(retval,&st->current_condition,ap); ! #ifdef YP ! _nis_endservent(retval,&st->current_condition,ap); ! st->current_condition=FILES_STATE; ! #endif ! return (NS_UNAVAIL); ! } ! ! static int ! _compat_getservent(void *retval, void *mdata, va_list ap) ! { ! struct compat_state * st; ! int rv; ! ! int continue_flag=0; ! ! rv=compat_getstate(&st); ! if (rv != 0) ! return (NS_UNAVAIL); ! ! #ifdef YP ! do { ! switch (st->current_condition) { ! case FILES_STATE: ! rv=_files_getservent(retval,&st->current_condition,ap); ! if (st->current_condition==NIS_STATE) ! continue_flag=1; ! else ! return rv; ! break; ! ! case NIS_STATE: ! rv=_nis_getservent(retval,&st->current_condition,ap); ! if (rv!=NS_SUCCESS) { ! st->current_condition=FILES_STATE; ! continue_flag=1; ! } else ! return NS_SUCCESS; ! break; ! ! default: ! /* NOT REACHED */ ! break; ! } ! } while (continue_flag==1); ! #else ! return _files_getservent(retval,&st->current_condition,ap); ! #endif ! ! /* NOT REACHED */ ! return (NS_UNAVAIL); ! } ! ! static int ! _compat_getservbyname(void *retval, void *mdata, va_list ap) ! { ! struct compat_state * st; ! int rv; ! ! enum compat_condition current_condition; ! ! rv=compat_getstate(&st); ! if (rv != 0) ! return (NS_UNAVAIL); ! ! current_condition=FILES_STATE; ! rv=_files_getservbyname(retval,¤t_condition,ap); ! ! return rv; ! } ! ! static int ! _compat_getservbyport(void *retval, void *mdata, va_list ap) ! { ! struct compat_state * st; ! int rv; ! ! enum compat_condition current_condition; ! ! rv=compat_getstate(&st); ! if (rv != 0) ! return (NS_UNAVAIL); ! ! current_condition=FILES_STATE; ! rv=_files_getservbyport(retval,¤t_condition,ap); ! ! return rv; ! } ! ! struct servent * ! getservent(void) ! { ! struct servent * sv = 0; ! int rval; ! ! static const ns_dtab dtab[] = { ! { NSSRC_FILES, _files_getservent, NULL }, ! #ifdef YP ! { NSSRC_NIS, _nis_getservent, NULL }, ! #endif ! { NSSRC_COMPAT, _compat_getservent, NULL }, ! { NULL, NULL, NULL } ! }; ! ! rval = _nsdispatch( (void *) &sv, dtab, NSDB_SERVICES, "getservent", defaultsrc, 0); ! ! if (rval != NS_SUCCESS) ! return NULL; else ! return sv; } void ! setservent(int stayopen) { ! static const ns_dtab dtab[] = { ! { NSSRC_FILES, _files_setservent, NULL }, ! #ifdef YP ! { NSSRC_NIS, _nis_setservent, NULL }, ! #endif ! { NSSRC_COMPAT, _compat_setservent, NULL}, ! { NULL, NULL, NULL } ! }; ! ! (void)_nsdispatch(NULL, dtab, NSDB_SERVICES, "setservent", defaultsrc, 0); } ! void ! endservent(void) { ! static const ns_dtab dtab[] = { ! { NSSRC_FILES, _files_endservent, NULL }, ! #ifdef YP ! { NSSRC_NIS, _nis_endservent, NULL }, ! #endif ! { NSSRC_COMPAT, _compat_endservent, NULL}, ! { NULL, NULL, NULL } ! }; ! ! (void)_nsdispatch(NULL, dtab, NSDB_SERVICES, "endservent", defaultsrc, 0); ! } + struct servent * + getservbyname(const char * name, const char * proto) + { + struct servent * sv = 0; + int rval; + + static const ns_dtab dtab[] = { + { NSSRC_FILES,_files_getservbyname,NULL }, #ifdef YP ! { NSSRC_NIS,_nis_getservbyname,NULL }, #endif ! { NSSRC_COMPAT, _compat_getservbyname, NULL }, ! { 0 } ! }; ! ! rval = _nsdispatch( (void *) &sv, dtab, NSDB_SERVICES, "getservbyname", defaultsrc, name, proto); ! ! if (rval != NS_SUCCESS) ! return NULL; ! else ! return sv; } + + struct servent * + getservbyport(int port, const char * proto) + { + struct servent * sv = 0; + int rval; + + static const ns_dtab dtab[] = { + { NSSRC_FILES,_files_getservbyport,NULL }, + #ifdef YP + { NSSRC_NIS, _nis_getservbyport,NULL }, + #endif + { NSSRC_COMPAT, _compat_getservbyport, NULL } , + { 0 } + }; + + rval = _nsdispatch( (void *) &sv, dtab, NSDB_SERVICES, "getservbyport", defaultsrc, port, proto); + + if (rval != NS_SUCCESS) + return NULL; + else + return sv; + } *** ./initial/getservbyname.c Wed Jul 14 18:06:32 2004 --- getservbyname.c Wed Jul 14 18:05:10 2004 *************** *** 38,81 **** __FBSDID("$FreeBSD: src/lib/libc/net/getservbyname.c,v 1.4 2002/03/21 18:49:23 obrien Exp $"); #include #include - extern int _serv_stayopen; - - struct servent * - getservbyname(name, proto) - const char *name, *proto; - { - struct servent *p; - char **cp; - - #ifdef YP - extern char *___getservbyname_yp; - extern char *___getservbyproto_yp; - - ___getservbyname_yp = (char *)name; - ___getservbyproto_yp = (char *)proto; - #endif - - setservent(_serv_stayopen); - while ( (p = getservent()) ) { - if (strcmp(name, p->s_name) == 0) - goto gotname; - for (cp = p->s_aliases; *cp; cp++) - if (strcmp(name, *cp) == 0) - goto gotname; - continue; - gotname: - if (proto == 0 || strcmp(p->s_proto, proto) == 0) - break; - } - if (!_serv_stayopen) - endservent(); - - #ifdef YP - ___getservbyname_yp = NULL; - ___getservbyproto_yp = NULL; - #endif - - return (p); - } --- 38,42 ---- *** ./initial/getservbyport.c Wed Jul 14 18:06:32 2004 --- getservbyport.c Wed Jul 14 18:05:17 2004 *************** *** 38,76 **** __FBSDID("$FreeBSD: src/lib/libc/net/getservbyport.c,v 1.4 2002/03/21 18:49:23 obrien Exp $"); #include #include - extern int _serv_stayopen; - - struct servent * - getservbyport(port, proto) - int port; - const char *proto; - { - struct servent *p; - - #ifdef YP - extern int ___getservbyport_yp; - extern char *___getservbyproto_yp; - - ___getservbyport_yp = port; - ___getservbyproto_yp = (char *)proto; - #endif - - setservent(_serv_stayopen); - while ( (p = getservent()) ) { - if (p->s_port != port) - continue; - if (proto == 0 || strcmp(p->s_proto, proto) == 0) - break; - } - if (!_serv_stayopen) - endservent(); - - #ifdef YP - ___getservbyport_yp = 0; - ___getservbyproto_yp = NULL; - #endif - - return (p); - } --- 38,42 ---- --=-NBIlVcBobXF4E8EHBWGR-- From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 26 14:13:05 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 93CC616A4CE for ; Tue, 26 Oct 2004 14:13:05 +0000 (GMT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id 453D943D2D for ; Tue, 26 Oct 2004 14:13:05 +0000 (GMT) (envelope-from simon.burke@gmail.com) Received: by wproxy.gmail.com with SMTP id 65so195527wri for ; Tue, 26 Oct 2004 07:13:01 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=EgXt0zu0x34oxJJlS8zmNM4Q8eoh1xETIIaDjZnluiyy4n5OEJEqz4QGbqlrQu/lcHEMu9A+eRyocz2SCCGFiucLGP5jo3OynN12rxItzVEhFYnW5QTvVd25F+tmsqwa7SNTXV7TpHnvmxdxnOgwPBFw3WjEFmu0Qcsf4aFw9gc= Received: by 10.38.149.71 with SMTP id w71mr320083rnd; Tue, 26 Oct 2004 07:13:01 -0700 (PDT) Received: by 10.38.125.77 with HTTP; Tue, 26 Oct 2004 07:13:01 -0700 (PDT) Message-ID: <2d7d2dd204102607136949411b@mail.gmail.com> Date: Tue, 26 Oct 2004 15:13:01 +0100 From: Simon Burke To: freebsd-hackers@freebsd.org In-Reply-To: <20041025.204000.118529340.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20041025.204000.118529340.imp@bsdimp.com> Subject: Re: CMOS Checksum error X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Simon Burke List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2004 14:13:05 -0000 > : When I go to reboot my machine > : with shutdown -r or reboot. The system reboots normally > : until POST when I get a CMOS Checksum invalid message default > : settings applied. However if I use halt or shutdown -h > : and power off then back on I don't get the error and BIOS settings > : are retained. > > Sounds like a dead CMOS battery in an older system. Or at least a > marginal one. > > Warner > > I concur. I seriously doubt that this is caused by the OS, I'd recommend replacing the CMOS battery as that is most likely the cause. However on another note, i did once expeience a simular problem where i got the same post error, but it was a problem with memory as the memory wasnt registered ECC memory, when it was supposd to be, but i doubt this is your issue. Try the battery first. -- Theres no place like ::1 Thanks, SimonB From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 26 15:14:51 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9DACA16A4CE for ; Tue, 26 Oct 2004 15:14:51 +0000 (GMT) Received: from out014.verizon.net (out014pub.verizon.net [206.46.170.46]) by mx1.FreeBSD.org (Postfix) with ESMTP id 33C7043D2D for ; Tue, 26 Oct 2004 15:14:51 +0000 (GMT) (envelope-from babkin@bellatlantic.net) Received: from outgoing.verizon.net ([192.168.1.2]) by out014.verizon.net ESMTP <20041026151450.CYXZ25088.out014.verizon.net@outgoing.verizon.net>; Tue, 26 Oct 2004 10:14:50 -0500 X-Mailer: Openwave WebEngine, version 2.8.12 (webedge20-101-197-20030912) From: To: "Matt Emmerton" , "John Von Essen" , "Doug Russell" Date: Tue, 26 Oct 2004 11:14:50 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH at out014.verizon.net from [192.168.1.2] at Tue, 26 Oct 2004 10:14:50 -0500 Message-Id: <20041026151450.CYXZ25088.out014.verizon.net@outgoing.verizon.net> cc: freebsd-hackers@freebsd.org Subject: Re: Re: hacking SCO.... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2004 15:14:51 -0000 > > This may be a dumb question, but if you make a cpio tape archive from > > data on an SCO system (HTFS filesystem), you can still restore the data > > off the tape to another system, like FreeBSD with a UFS filesystem, > > right? > > This should work. If you run into any issues they will be incompatibilities > between SCO's cpio and the GNU cpio that FreeBSD uses. Sometimes you have to not use the option -c on the GNU cpio when extracting an archive created on SysV (somehow GNU cpio has a different idea about the -c format but if left out, it will figure it out well automatically). > > And the followup, can FreeBSD run SCO binaries (SCO Unix 5.0.1)? I am > > going to try and convert these people from their SCO box over to a > > FreeBSD system. Just want to make sure the data will come off the tape. > > Yes, but support is really limited. You need to copy a bunch of core > libraries onto the FreeBSD machine from the SCO machine to make things work. > (We just emulate the syscall interface -- you need libc and friends from > SCO.) And if you want to stay out of lawsuits, you will also need a separate license from SCO for these libraries (something like $700). It's kind of stupid but the SCO lawyers believe that if you've bought these libraries as a part of OpenServer, you can't run them on any other OS. The product is called something like SVLL which stands for System V Libraries for Linux. -SB not working for SCO any more From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 26 15:14:56 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 963D216A4EA; Tue, 26 Oct 2004 15:14:56 +0000 (GMT) Received: from eva.fit.vutbr.cz (eva.fit.vutbr.cz [147.229.10.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id C948443D2D; Tue, 26 Oct 2004 15:14:55 +0000 (GMT) (envelope-from xdivac02@stud.fit.vutbr.cz) Received-SPF: pass (eva.fit.vutbr.cz: domain of xdivac02@eva.fit.vutbr.cz designates 127.0.0.1 as permitted sender) receiver=eva.fit.vutbr.cz; client_ip=127.0.0.1; envelope-from=xdivac02@eva.fit.vutbr.cz; Received: from eva.fit.vutbr.cz (localhost [127.0.0.1]) by eva.fit.vutbr.cz (8.12.11/8.12.11) with ESMTP id i9QFEhux021704 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 26 Oct 2004 17:14:43 +0200 (CEST) Received: (from xdivac02@localhost) by eva.fit.vutbr.cz (8.12.11/8.12.5/Submit) id i9QFEhmW021703; Tue, 26 Oct 2004 17:14:43 +0200 (CEST) Date: Tue, 26 Oct 2004 17:14:43 +0200 From: Divacky Roman To: current@freebsd.org Message-ID: <20041026151443.GA21112@stud.fit.vutbr.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2i X-Scanned-By: MIMEDefang 2.16 (www . roaringpenguin . com / mimedefang) cc: hackers@freebsd.org Subject: removing dependancy on COMPAT_43 from linuxator X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2004 15:14:56 -0000 Hi I wrote a patch which removes dependancy on COMPAT_43 from linux abi simulator. It introduces new option COMPAT_43FORLIN (name should be changed), ie. it peels of the kernel all the unecessary stuff noone these days use while keeping linux emulation working... its kern/73165, pls take a look roman From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 26 20:20:24 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7B79A16A4CF for ; Tue, 26 Oct 2004 20:20:24 +0000 (GMT) Received: from mwinf0208.wanadoo.fr (smtp2.wanadoo.fr [193.252.22.29]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0539C43D2F for ; Tue, 26 Oct 2004 20:20:24 +0000 (GMT) (envelope-from rmkml@wanadoo.fr) Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf0208.wanadoo.fr (SMTP Server) with SMTP id 65B9318000DF for ; Tue, 26 Oct 2004 22:20:22 +0200 (CEST) Received: from crusoecids.dyndns.org (AVelizy-151-1-36-222.w82-120.abo.wanadoo.fr [82.120.18.222]) by mwinf0208.wanadoo.fr (SMTP Server) with SMTP id 1D88D18000C6 for ; Tue, 26 Oct 2004 22:20:22 +0200 (CEST) Received: (qmail 27624 invoked from network); 27 Oct 2004 20:08:21 -0000 Received: from unknown (HELO hp) (192.168.1.2) by 192.168.1.1 with SMTP; 27 Oct 2004 20:08:21 -0000 Date: Wed, 27 Oct 2004 00:19:23 +0200 (CEST) From: rmkml X-X-Sender: rmkml@hp To: freebsd-hackers@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Pb seeking with less on file more size 2Go X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2004 20:20:24 -0000 Hi, I running less with file more size 2Go on fbsd v4.10R and if execute 'G' on less cmd G not seek on end file ... Possible you have same pb/question ? Regards Rmkml@Wanadoo.fr From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 26 21:06:16 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B59C516A4CE for ; Tue, 26 Oct 2004 21:06:16 +0000 (GMT) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [69.194.102.143]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8DA6843D1D for ; Tue, 26 Oct 2004 21:06:16 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 915D553369; Tue, 26 Oct 2004 14:07:12 -0700 (PDT) Date: Tue, 26 Oct 2004 14:07:12 -0700 From: Kris Kennaway To: rmkml Message-ID: <20041026210712.GA82324@xor.obsecurity.org> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="huq684BweRXVnRxX" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i cc: freebsd-hackers@freebsd.org Subject: Re: Pb seeking with less on file more size 2Go X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2004 21:06:16 -0000 --huq684BweRXVnRxX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 27, 2004 at 12:19:23AM +0200, rmkml wrote: > Hi, >=20 > I running less with file more size 2Go >=20 > on fbsd v4.10R >=20 > and if execute 'G' on less cmd >=20 > G not seek on end file ... >=20 > Possible you have same pb/question ? You should try talking to the less developers, since this utility is maintained by a third party. Kris --huq684BweRXVnRxX Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBfryAWry0BWjoQKURAmtmAJ9nNwBHWfl4IFlo+2ExQvk6iGEepACg4cgW oLmamfBQFIaBKRqGyl+AAIQ= =QdD/ -----END PGP SIGNATURE----- --huq684BweRXVnRxX-- From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 26 21:18:09 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ACB3016A4CE for ; Tue, 26 Oct 2004 21:18:09 +0000 (GMT) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4714C43D49 for ; Tue, 26 Oct 2004 21:18:09 +0000 (GMT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.12.11/8.13.1) id i9QLI8Z6098153; Tue, 26 Oct 2004 16:18:08 -0500 (CDT) (envelope-from dan) Date: Tue, 26 Oct 2004 16:18:08 -0500 From: Dan Nelson To: rmkml Message-ID: <20041026211808.GA37795@dan.emsphone.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-OS: FreeBSD 5.3-BETA7 X-message-flag: Outlook Error User-Agent: Mutt/1.5.6i cc: freebsd-hackers@freebsd.org Subject: Re: Pb seeking with less on file more size 2Go X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2004 21:18:09 -0000 In the last episode (Oct 27), rmkml said: > I running less with file more size 2Go > > on fbsd v4.10R > > and if execute 'G' on less cmd > > G not seek on end file ... > > Possible you have same pb/question ? I just tested it on an 8GB file, and although I don't get any error, it only seeks to ~3.7GB into the file, so the version of less that comes with 4.10 probably uses an "unsigned int" someplace. The version you get when you build the ports/misc/less port does work correctly, though. If you install that, you should be okay. -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 26 23:04:48 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3393016A4CF for ; Tue, 26 Oct 2004 23:04:48 +0000 (GMT) Received: from tower.berklix.org (bsd.bsn.com [194.221.32.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id F2E7043D66 for ; Tue, 26 Oct 2004 23:04:46 +0000 (GMT) (envelope-from jhs@flat.berklix.net) Received: from js.berklix.net (pD9E4DF82.dip.t-dialin.net [217.228.223.130]) (authenticated bits=0) by tower.berklix.org (8.12.9p2/8.12.9) with ESMTP id i9QN4g03052605; Wed, 27 Oct 2004 01:04:43 +0200 (CEST) (envelope-from jhs@flat.berklix.net) Received: from laps.jhs.private (laps.jhs.private [192.168.91.56]) by js.berklix.net (8.12.11/8.12.11) with ESMTP id i9QN4el3004477; Wed, 27 Oct 2004 01:04:41 +0200 (CEST) (envelope-from jhs@flat.berklix.net) Received: from laps.jhs.private (localhost [127.0.0.1]) by laps.jhs.private (8.13.1/8.13.1) with ESMTP id i9QN4de5011212; Wed, 27 Oct 2004 01:04:40 +0200 (CEST) (envelope-from jhs@laps.jhs.private) Message-Id: <200410262304.i9QN4de5011212@laps.jhs.private> To: freebsd-hackers@freebsd.org From: "Julian Stacey" Organization: http://berklix.com/~jhs/ User-agent: EXMH http://beedub.com/exmh/ on FreeBSD http://freebsd.org Date: Wed, 27 Oct 2004 01:04:38 +0200 Sender: jhs@flat.berklix.net cc: Jürgen Seeger Subject: German iX magazine has released a trial 7 Meg free PDF in English. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2004 23:04:48 -0000 freebsd-hackers@ readers (& bcc'd 2 local Munich lists, mecc@ & bim@), This isnt FreeBSD specific, but may interest many. http://www.ix.de/en/ has a trial run in English of the German IX magazine. Theyre assesing market for a monthly PDF paid subscription version in English of their paper printed German magazine. Disclaimer/ Suggestion for CT mag: I'm just an occasional customer/ browser of IX mag (lack of time), & English, resident in Germany. What some of you folks in rest of world might really give your eye teeth for, if you ever knew it, & if you were ever given the opportunity, would be an English translation of CT mag, from the same publishers as iX mag. (Heise Verlag), but CT is also only in German far as I know. CT is not yet another PC Soft/ DOS rag, but a decent electronic hardware & software mag, maybe as unique & good as or better than Byte mag was unique & good maybe around 1978/82, before Byte became just another PC software mag among many (well apologies if Byte has improved since, but when last I looked it was (imported to Germany) expensive & no real interest to me. CT is Good, certainly better than anything I've ever found in trips back to England, & would be nice if English speakers had access to it too (though after 19 years in Germany I personaly read either happily in the original :-) The chief editor of iX is quoted below writing to his authors in German about this trial run, (but that's just for reference if you happen to speak German, if not just download the free trial Mag in English, (they ask you to answer a feedback questionaire after you've read the mag.) - Julian Stacey. Unix,C,Net & Sys. Eng. Consultant, Munich. http://berklix.com Mail Ascii; Html deleted as Spam. Ihr Rauch = mein allergischer Kopfschmerz. ------- Forwarded Message via: Benedikt Stockebrand ... From: From: =?iso-8859-1?q?J=FCrgen_Seeger?= Subject: iX jetzt auch auf Englisch Message-Id: Date: Mon, 25 Oct 2004 18:30:54 +0200 Liebe iX-Autorinnen und -Autoren, iX gibt es jetzt auch auf Englisch. Genauer gesagt: unter http://www.ix.de/en/ steht eine englischsprachige Nullnummer zum Download zur Verf=FCgung. Wir wollen damit feststellen, wie gro=DF das Interesse an iX au=DFerhalb des deutschen Sprachraums ist. Geplant ist eine digitale Distribution (auf PDF-Basis) in Form eines bezahlten Abonnements, die Nullnummer ist nat=FCrlich kostenlos und kann (und soll) frei verbreitet werden. Wir m=F6chten Sie/Euch bitten, potentielle Interessenten auf das Projekt aufmerksam zu machen. Auf der erw=E4hnten Webseite k=F6nnen diese auch Ihr Urteil =FCber "iX international" abgeben, abh=E4ngig von der Resonanz wird der Verlag entscheiden, ob iX k=FCnftig regelm=E4=DFig auf Englisch erscheint. Mit freundlichen Gr=FC=DFen J=FCrgen Seeger Chefredakteur iX From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 27 00:27:54 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4D4A416A4CE; Wed, 27 Oct 2004 00:27:54 +0000 (GMT) Received: from beer.ux6.net (beer.ux6.net [64.62.253.29]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3362F43D53; Wed, 27 Oct 2004 00:27:54 +0000 (GMT) (envelope-from miha@ghuug.org) Received: from [64.62.253.84] (helo=m) by beer.ux6.net with esmtpa (Exim 4.43 (FreeBSD)) id 1CMbfM-0003az-R9; Tue, 26 Oct 2004 17:27:54 -0700 From: "Mikhail P." To: freebsd-stable@freebsd.org Date: Wed, 27 Oct 2004 00:27:47 +0000 User-Agent: KMail/1.7 Organization: Ghana Unix Users Group MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200410270027.47092.miha@ghuug.org> X-Spam-Score: -4.9 (----) X-Spam-Report: Spam detection software, running on the system "beer.ux6.net", hasmessageblock similar future email. If you have any questions, see the administrator of that system for details. Content preview: Hello, On our next file server, I want to make one large FTP area out of 4 drives (so that system sees them as onewith Vinum previously, but hear a lot about it. My question is how to Vinum, and what will happen if let's say one drive fails in volume? Am I loosing the whole data, or I can just unplug the drive, tell vinum to use remaining drives with the data each drive holds? I'm not looking for fault tolerance solution. [...] Content analysis details: (-4.9 points, 6.0 required) pts rule name description --------------------------------------------------1% [score: 0.0000] cc: freebsd-hackers@freebsd.org Subject: question on vinum X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: miha@ghuug.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2004 00:27:54 -0000 Hello, On our next file server, I want to make one large FTP area out of 4 drives = (so=20 that system sees them as one volume). Vinum appears to be exactly what I=20 need. I haven't worked with Vinum previously, but hear a lot about it. My questio= n=20 is how to implement the above (unite four drives into single volume) using= =20 Vinum, and what will happen if let's say one drive fails in volume? Am I=20 loosing the whole data, or I can just unplug the drive, tell vinum to use=20 remaining drives with the data each drive holds? I'm not looking for fault= =20 tolerance solution. =46rom my understanding, in above scenario, Vinum will first fill up the fi= rst=20 drive, then second, etc. I have read the handbook articles, and I got general understanding of Vinum. I'm particularly interested to know if I will still be able to use volume i= n=20 case of failed drive. Some minimal configuration examples would be greatly appreciated! Server will be running FreeBSD-4.10. regards, M. From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 27 07:33:35 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D8C9816A4CE; Wed, 27 Oct 2004 07:33:35 +0000 (GMT) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8B74343D55; Wed, 27 Oct 2004 07:33:35 +0000 (GMT) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1CMiJK-0006ZE-0v; Wed, 27 Oct 2004 09:33:34 +0200 X-Mailer: exmh version 2.7.0 06/18/2004 with nmh-1.0.4 To: bushman@rsu.ru In-Reply-To: Message from Michael Bushkov <1098785868.61417.39.camel@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 27 Oct 2004 09:33:33 +0200 From: Danny Braniss Message-Id: <20041027073335.8B74343D55@mx1.FreeBSD.org> cc: "Jacques A. Vidrine" cc: hackers@freebsd.org cc: "Christian S.J. Peron" Subject: Re: nsdispatch services patch + lookupd X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2004 07:33:36 -0000 while trying to add hesiod/dns support, i've noticed, what looks as a problem: in nss_tls.h, the function name##_getstate(...) can return a static pointer, which gets freed in name##_endstate(...), as far as i know, freeing a non malloced memory is asking for trouble. proposed fix, instead of static, also do a calloc(...). danny From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 26 20:22:11 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A7D5F16A4CE for ; Tue, 26 Oct 2004 20:22:11 +0000 (GMT) Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 733A043D31 for ; Tue, 26 Oct 2004 20:22:11 +0000 (GMT) (envelope-from root@comcast.net) Received: from pcp630416pcs.newhvn01.in.comcast.net ([68.53.193.233]) by comcast.net (rwcrmhc13) with SMTP id <2004102620221001500mtu9fe>; Tue, 26 Oct 2004 20:22:10 +0000 Date: Tue, 26 Oct 2004 15:52:45 -0500 (EST) From: Jeremiah Holt X-X-Sender: root@localhost.localdomain.com To: freebsd-hackers@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Wed, 27 Oct 2004 12:30:12 +0000 Subject: CMOS Checksum Error X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2004 20:22:11 -0000 I've replaced the battery with a new one. Alsa in Linux and Windows98/NT4/XP on the same system do not cause the problem even after running for long periods of time only after rebooting from FreeBSD does it appear From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 26 20:27:43 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 30CB616A4CF for ; Tue, 26 Oct 2004 20:27:43 +0000 (GMT) Received: from localhost.localdomain.com (pcp630416pcs.newhvn01.in.comcast.net [68.53.193.233]) by mx1.FreeBSD.org (Postfix) with ESMTP id B206143D55 for ; Tue, 26 Oct 2004 20:27:42 +0000 (GMT) (envelope-from root@localhost.localdomain.com) Received: from localhost.localdomain.com (localhost [127.0.0.1]) i9QKwimP022135 for ; Tue, 26 Oct 2004 15:58:44 -0500 Received: (from root@localhost)i9QKwiJA022134 for freebsd-hackers@freebsd.org; Tue, 26 Oct 2004 15:58:44 -0500 From: root@localhost.localdomain.com Date: Tue, 26 Oct 2004 15:58:44 -0500 To: freebsd-hackers@freebsd.org Message-ID: <417EBA84.mailH2T19CUW7@localhost> User-Agent: nail 10.7 3/19/04 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 27 Oct 2004 12:30:12 +0000 Subject: CMOS Checksum Error X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2004 20:27:43 -0000 I've replaced the Battery with a new one. Also Linux, Windows98/NT4/XP and BeOS do not exibit this problem and FreeBSD only exibit's it on a warm boot on a power off/on the problem doesn't occur From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 27 14:14:20 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8C54916A4CE for ; Wed, 27 Oct 2004 14:14:20 +0000 (GMT) Received: from ussenterprise.ufp.org (ussenterprise.ufp.org [208.185.30.210]) by mx1.FreeBSD.org (Postfix) with ESMTP id F337243D46 for ; Wed, 27 Oct 2004 14:14:19 +0000 (GMT) (envelope-from bicknell@ussenterprise.ufp.org) Received: from ussenterprise.ufp.org (bicknell@localhost [127.0.0.1]) by ussenterprise.ufp.org (8.12.9/8.12.9) with ESMTP id i9REEJaK036912 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 27 Oct 2004 10:14:19 -0400 (EDT) Received: (from bicknell@localhost) by ussenterprise.ufp.org (8.12.9/8.12.9/Submit) id i9REEJ9C036911 for freebsd-hackers@freebsd.org; Wed, 27 Oct 2004 10:14:19 -0400 (EDT) Date: Wed, 27 Oct 2004 10:14:19 -0400 From: Leo Bicknell To: freebsd-hackers@freebsd.org Message-ID: <20041027141419.GA36554@ussenterprise.ufp.org> Mail-Followup-To: freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IJpNTDwzlM2Ie8A6" Content-Disposition: inline Organization: United Federation of Planets X-PGP-Key: http://www.ufp.org/~bicknell/ Subject: Busy BIND + 5.2.1 = UDP Packet Loss X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2004 14:14:20 -0000 --IJpNTDwzlM2Ie8A6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I recently upgraded a fairly busy nameserver to FreeBSD 5.2.1, and I'm seeing packet loss from time to time on the box. I've done some digging, and the box seems to be dropping UDP packets. Netstat output: udp: 177604011 datagrams received 0 with incomplete header 7 with bad data length field 2735233 with bad checksum 83753 with no checksum 205540 dropped due to no socket 1917 broadcast/multicast datagrams dropped due to no socket 10627437 dropped due to full socket buffers 0 not for hashed pcb 164033877 delivered 169793422 datagrams output The "dropped due to full socket buffers" seems to be the issue. I am also concerned by the number of packets with bad checksums, but I have no previous data point. I am seeing loss with DNS, but also with ping and given the few pauses in my ssh sessions with TCP as well. I don't see anything remarkable with the TCP or ICMP statistics. I don't think there's anything wrong in MBUF land, statistics here for reference: % netstat -m mbuf usage: GEN cache: 0/256 (in use/in pool) CPU #0 cache: 335/672 (in use/in pool) Total: 335/928 (in use/in pool) Mbuf cache high watermark: 512 Maximum possible: 51200 Allocated mbuf types: 291 mbufs allocated to data 14 mbufs allocated to ancillary data 16 mbufs allocated to fragment reassembly queue headers 14 mbufs allocated to socket names and addresses 1% of mbuf map consumed mbuf cluster usage: GEN cache: 0/152 (in use/in pool) CPU #0 cache: 289/400 (in use/in pool) Total: 289/552 (in use/in pool) Cluster cache high watermark: 128 Maximum possible: 25600 2% of cluster map consumed 1336 KBytes of wired memory reserved (49% in use) 0 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines The only other thing I found of interest was some interrupt drops: % sysctl -a | grep drops net.inet.ip.intr_queue_drops: 13981 So, given the traffic profile (nameserver, heavy UDP) and the info here can someone help point me in the right direction? I'm not sure where to go from here? --=20 Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org --IJpNTDwzlM2Ie8A6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFBf607Nh6mMG5yMTYRAqUsAJ9BMN6aEuXXWrJJc3+tXePO8O2J7wCaA5Ub Hu08eain/jiTlscA5i1XyUM= =A613 -----END PGP SIGNATURE----- --IJpNTDwzlM2Ie8A6-- From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 28 01:00:48 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E857D16A4D7 for ; Thu, 28 Oct 2004 01:00:48 +0000 (GMT) Received: from adsl-68-76-19-75.dsl.klmzmi.ameritech.net (adsl-68-76-19-75.dsl.klmzmi.ameritech.net [68.76.19.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id C9A4A43D41 for ; Thu, 28 Oct 2004 01:00:43 +0000 (GMT) (envelope-from luke@foolishgames.com) Received: from [192.168.0.50] (24.176.8.69.kzo.mi.chartermi.net [24.176.8.69]) (authenticated bits=0)ESMTP id i9S10tih055840; Wed, 27 Oct 2004 21:00:56 -0400 (EDT) (envelope-from luke@foolishgames.com) X-Authentication-Warning: adsl-68-76-19-75.dsl.klmzmi.ameritech.net: Host 24.176.8.69.kzo.mi.chartermi.net [24.176.8.69] claimed to be [192.168.0.50] Message-Id: X-Habeas-Swe-6: email in exchange for a license for this Habeas X-Habeas-Swe-3: like Habeas SWE (tm) Date: Wed, 27 Oct 2004 21:00:30 -0400 X-Habeas-Swe-8: Message (HCM) and not spam. Please report use of this From: Lucas Holt X-Habeas-Swe-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-Swe-2: brightly anticipated In-Reply-To: References: To: jeremiah_holt@comcast.net X-Habeas-Swe-7: warrant mark warrants that this is a Habeas Compliant Mime-Version: 1.0 (Apple Message framework v619) X-Habeas-Swe-4: Copyright 2002 Habeas (tm) Content-Type: text/plain; charset=US-ASCII; format=flowed X-Habeas-Swe-1: winter into spring Content-Transfer-Encoding: 7bit X-Habeas-Swe-9: mark in spam to . X-Mailer: Apple Mail (2.619) X-Virus-Scanned: ClamAV 0.80/550/Mon Oct 25 11:39:01 2004 clamav-milter version 0.80j11:39:01 2004 clamav-milter version 0.80j X-Virus-Status: Clean cc: freebsd-hackers@freebsd.org Subject: Re: CMOS Checksum error X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2004 01:00:49 -0000 Its possible it might be os related in the sense that freebsd does something different with the state of the machine on a reboot. The thing is it works fine for everyone else. Have you checked for a cmos update on compaq's site? Could be a bug in the bios code that windows and linux don't trigger. Lucas Holt Luke@FoolishGames.com ________________________________________________________ FoolishGames.com (Jewel Fan Site) JustJournal.com (Free blogging) From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 28 10:23:05 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 47F1016A4CE for ; Thu, 28 Oct 2004 10:23:05 +0000 (GMT) Received: from mail815.megamailservers.com (mail815.carrierinternetsolutions.com [69.49.106.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 972F443D2F for ; Thu, 28 Oct 2004 10:23:04 +0000 (GMT) (envelope-from strick@covad.net) X-POP-User: strick.covad.net Received: from mist.nodomain (h-67-101-98-29.snfccasy.dynamic.covad.net [67.101.98.29])i9SAN31l027305 for ; Thu, 28 Oct 2004 06:23:03 -0400 Received: from mist.nodomain (localhost [127.0.0.1]) by mist.nodomain (8.12.11/8.12.11) with ESMTP id i9SAN2Ci001782; Thu, 28 Oct 2004 03:23:02 -0700 (PDT) (envelope-from dan@mist.nodomain) Received: (from dan@localhost) by mist.nodomain (8.12.11/8.12.11/Submit) id i9SAN27L001781; Thu, 28 Oct 2004 03:23:02 -0700 (PDT) (envelope-from dan) Date: Thu, 28 Oct 2004 03:23:02 -0700 (PDT) From: Dan Strick Message-Id: <200410281023.i9SAN27L001781@mist.nodomain> To: freebsd-hackers@freebsd.org cc: dan@mist.nodomain Subject: questionable feature in FreeBSD pmake X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2004 10:23:05 -0000 I just spent a *very* frustrating hour trying to figure out why the FreeBSD make program was invoking all commands to make things in a subdirectory named "obj". I eventually discovered this gem in the make man page: In addition, make sets or knows about the following internal variables or environment variables: ... .OBJDIR A path to the directory where the targets are built. At startup, make searches for an alternate directory to place target files. It will attempt to change into this special directory and will search this directory for makefiles not found in the current directory. The following directories are tried in order: 1. ${MAKEOBJDIRPREFIX}/`pwd` 2. ${MAKEOBJDIR} 3. obj.${MACHINE} 4. obj 5. /usr/obj/`pwd` I believe this feature is a real botch because it is magic, unintuitive, and so *exceedingly* easy to invoke by mistake. It happens that I really really want to have a subdirectory named "obj" and I really really don't want to cd into it. The only workaround seems to be to define the MAKEOBJDIR variable and that would be disgustingly ugly because it makes no obvious sense unless you are aware of the magic feature. Rules 3-5 look like they were invented without careful consideration to avoid the minor effort required to use one of the first 2 rules. Does anyone know where this feature came from? The .OBJDIR variable was recognized by the pmake distributed with 4.4 BSD, but the man page for that version of make does not mention the gratuitous magic rules for changing the make working directory. The older make program found in 4.3 BSD does not seem to use the .OBJDIR variable at all. This feature is not mentioned in the pmake tutorial found in /usr/share/doc/psd/12.make. Is it a FreeBSD-ism? Dan Strick strick@covad.net From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 28 10:53:47 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1F68F16A4D1 for ; Thu, 28 Oct 2004 10:53:47 +0000 (GMT) Received: from gandalf.online.bg (gandalf.online.bg [217.75.128.9]) by mx1.FreeBSD.org (Postfix) with SMTP id 4941643D41 for ; Thu, 28 Oct 2004 10:53:45 +0000 (GMT) (envelope-from roam@ringlet.net) Received: (qmail 7123 invoked from network); 28 Oct 2004 10:53:40 -0000 Received: from unknown (HELO straylight.ringlet.net) (217.75.134.254) by gandalf.online.bg with SMTP; 28 Oct 2004 10:53:40 -0000 Received: (qmail 2143 invoked by uid 1000); 28 Oct 2004 10:51:00 -0000 Date: Thu, 28 Oct 2004 13:51:00 +0300 From: Peter Pentchev To: Dan Strick Message-ID: <20041028105100.GB975@straylight.m.ringlet.net> Mail-Followup-To: Dan Strick , freebsd-hackers@freebsd.org, dan@mist.nodomain References: <200410281023.i9SAN27L001781@mist.nodomain> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xgyAXRrhYN0wYx8y" Content-Disposition: inline In-Reply-To: <200410281023.i9SAN27L001781@mist.nodomain> User-Agent: Mutt/1.5.6i cc: freebsd-hackers@freebsd.org cc: dan@mist.nodomain Subject: Re: questionable feature in FreeBSD pmake X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2004 10:53:47 -0000 --xgyAXRrhYN0wYx8y Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Oct 28, 2004 at 03:23:02AM -0700, Dan Strick wrote: > I just spent a *very* frustrating hour trying to figure out why the > FreeBSD make program was invoking all commands to make things in a > subdirectory named "obj". I eventually discovered this gem in the > make man page: [snip] > .OBJDIR A path to the directory where the targets are built. [snip] > 1. ${MAKEOBJDIRPREFIX}/`pwd` > 2. ${MAKEOBJDIR} > 3. obj.${MACHINE} > 4. obj > 5. /usr/obj/`pwd` >=20 > I believe this feature is a real botch because it is magic, unintuitive, > and so *exceedingly* easy to invoke by mistake. Actually, this feature lies at the base of the FreeBSD base system build infrastructure, and it is pretty much The Feature that allows us to build from read-only and/or NFS-mounted sources shared among wide swarms of machines :) [snip] > This feature is not mentioned in the pmake tutorial found in > /usr/share/doc/psd/12.make. Is it a FreeBSD-ism? A quick glance at other BSD's make(1) manual pages, all available from , seems to show that .OBJDIR and MAKEOBJDIRPREFIX handling is present in all of them, and OpenBSD's make(1) manual lists the same search order, including 'obj.${MACHINE}' and 'obj'. G'luck, Peter --=20 Peter Pentchev roam@ringlet.net roam@cnsys.bg roam@FreeBSD.org PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 I am jealous of the first word in this sentence. --xgyAXRrhYN0wYx8y Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBgM8U7Ri2jRYZRVMRAgYmAJ0cMqxY2iazcvLCVR3IogCUJVQ/tQCeMqsI 420A6u8zttsfgsQ4wD3bvBc= =HlnN -----END PGP SIGNATURE----- --xgyAXRrhYN0wYx8y-- From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 28 10:56:30 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 30E9816A4CE for ; Thu, 28 Oct 2004 10:56:30 +0000 (GMT) Received: from gandalf.online.bg (gandalf.online.bg [217.75.128.9]) by mx1.FreeBSD.org (Postfix) with SMTP id 395BD43D54 for ; Thu, 28 Oct 2004 10:56:29 +0000 (GMT) (envelope-from roam@ringlet.net) Received: (qmail 8101 invoked from network); 28 Oct 2004 10:56:24 -0000 Received: from unknown (HELO straylight.ringlet.net) (217.75.134.254) by gandalf.online.bg with SMTP; 28 Oct 2004 10:56:24 -0000 Received: (qmail 3140 invoked by uid 1000); 28 Oct 2004 10:56:52 -0000 Date: Thu, 28 Oct 2004 13:56:52 +0300 From: Peter Pentchev To: Dan Strick Message-ID: <20041028105652.GC975@straylight.m.ringlet.net> Mail-Followup-To: Dan Strick , freebsd-hackers@FreeBSD.org References: <200410281023.i9SAN27L001781@mist.nodomain> <20041028105100.GB975@straylight.m.ringlet.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="JgQwtEuHJzHdouWu" Content-Disposition: inline In-Reply-To: <20041028105100.GB975@straylight.m.ringlet.net> User-Agent: Mutt/1.5.6i cc: freebsd-hackers@FreeBSD.org Subject: Re: questionable feature in FreeBSD pmake X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2004 10:56:30 -0000 --JgQwtEuHJzHdouWu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Oct 28, 2004 at 01:51:00PM +0300, Peter Pentchev wrote: > On Thu, Oct 28, 2004 at 03:23:02AM -0700, Dan Strick wrote: > > I just spent a *very* frustrating hour trying to figure out why the > > FreeBSD make program was invoking all commands to make things in a > > subdirectory named "obj". I eventually discovered this gem in the > > make man page: > [snip] > > .OBJDIR A path to the directory where the targets are built. > [snip] > > 1. ${MAKEOBJDIRPREFIX}/`pwd` > > 2. ${MAKEOBJDIR} > > 3. obj.${MACHINE} > > 4. obj > > 5. /usr/obj/`pwd` > >=20 > > I believe this feature is a real botch because it is magic, unintuitive, > > and so *exceedingly* easy to invoke by mistake. >=20 > Actually, this feature lies at the base of the FreeBSD base system build > infrastructure, and it is pretty much The Feature that allows us to > build from read-only and/or NFS-mounted sources shared among wide swarms > of machines :) Oh, and let's not forget cross-platform builds, too. G'luck, Peter --=20 Peter Pentchev roam@ringlet.net roam@cnsys.bg roam@FreeBSD.org PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 If I had finished this sentence, --JgQwtEuHJzHdouWu Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBgNB07Ri2jRYZRVMRAuehAJ9tdy5l+vAovQ73grok51BD4LtbuQCdH25/ zloLytOrcAIBTWbxF+Qt14c= =xTkv -----END PGP SIGNATURE----- --JgQwtEuHJzHdouWu-- From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 28 11:09:54 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B1E5716A4CE for ; Thu, 28 Oct 2004 11:09:54 +0000 (GMT) Received: from beer.ux6.net (beer.ux6.net [64.62.253.29]) by mx1.FreeBSD.org (Postfix) with ESMTP id 927C443D2F for ; Thu, 28 Oct 2004 11:09:54 +0000 (GMT) (envelope-from miha@ghuug.org) Received: from [64.62.253.84] (helo=m) by beer.ux6.net with esmtpa (Exim 4.43 (FreeBSD)) id 1CN8AC-000BX9-JN; Thu, 28 Oct 2004 04:09:54 -0700 From: "Mikhail P." To: freebsd-hackers@freebsd.org Date: Thu, 28 Oct 2004 11:09:48 +0000 User-Agent: KMail/1.7 References: <200410081937.15068.miha@ghuug.org> <200410091843.06854.miha@ghuug.org> <4168F9E7.9040408@DeepCore.dk> In-Reply-To: <4168F9E7.9040408@DeepCore.dk> Organization: Ghana Unix Users Group MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200410281109.48424.miha@ghuug.org> X-Spam-Score: -4.9 (----) X-Spam-Report: Spam detection software, running on the system "beer.ux6.net", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or block similar future email. If you have any questions, see the administrator of that system for details. Content preview: On Sunday 10 October 2004 08:59, Søren Schmidt wrote: > There is definitly something fishy here, since I dont have either the > disks nor any VIA chips here in the lab I cannot do any testing here. > However I dont know of any problems with the VIA chips in this regard, > so that leaves the disks for scrutiny. One thing to try is change the > tripping point where we switch from 28bit mode to 48 bit mode, could be > a 1 off error in the firmware... [...] Content analysis details: (-4.9 points, 6.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -4.9 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] cc: =?iso-8859-1?q?S=F8ren_Schmidt?= Subject: Re: ad0: FAILURE - WRITE_DMA X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: miha@ghuug.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2004 11:09:54 -0000 On Sunday 10 October 2004 08:59, S=F8ren Schmidt wrote: > There is definitly something fishy here, since I dont have either the > disks nor any VIA chips here in the lab I cannot do any testing here. > However I dont know of any problems with the VIA chips in this regard, > so that leaves the disks for scrutiny. One thing to try is change the > tripping point where we switch from 28bit mode to 48 bit mode, could be > a 1 off error in the firmware... I apologize for bumping that old thread.. I have received both 200G drives (the ones that were giving me "adX: FAILUR= E -=20 WRITE_DMA" on 5.2.1 system). I have plugged both drives into running 4.10 system, re-formatted them to U= =46S1=20 from sysinstall. After filling those drives with 180G of data each (files=20 ranging in size from 10k to 1G), I did a lot of load on them (e.g. transfer= ed=20 data between other drives in the system, deleted random files, "dd", etc) a= nd=20 those adX failures did not appear anymore (in fact, I'm running those drive= s=20 on the file server for 5 days now, and there is no single failure/timeout s= o=20 far - system has been very stable all the time on FreeBSD-4.10) On the side note - I did changes to the tripping point as suggested above a= nd=20 re-compiled kernel on 5.2.1 running system - disk operations dramatically=20 decreased as expected, but number of timeouts decreased too (per dmesg -=20 one-two timeouts in 3-4 days). I should probably also note another interesting thing - on another system w= ith=20 4 hard drives (20G, 60G, 120G, 200G) where I ran RELENG_5 for the past week= ,=20 timeouts and failures were appearing randomly under heavy disk writes. That system had a mix of filesystems - primary 20G drive had UFS2, and the= =20 rest of the drives were UFS1 (as they hold data, and I ran 4.7 on that syst= em=20 half a year ago) - data transfer between interfaces was horrible, less than= =20 8-10mb/sec, even when system was IDLE. After re-installing system to 4.10 (no changes to hardware/etc - all remain= ed=20 the same apart from OS), I don't see timeouts/errors anymore, and speed of= =20 transfers between the drives got back to 20-25mb/sec, that's including that= =20 system isn't IDLE. There is also a third system with 2 x 200G ide drives and FBSD-5.2.1. Today= , I=20 had to transfer approx. 160G of data from one of the drives to another syst= em=20 via NFS, and unfortunately some files could not be transfered due to the sa= me=20 ad1 failures as above.. I'm going to mount drive in "ro", to finish the=20 transfer. regards, M. From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 28 01:48:24 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 602E016A4D0; Thu, 28 Oct 2004 01:48:24 +0000 (GMT) Received: from orthanc.ca (orthanc.ca [209.89.70.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 105AF43D4C; Thu, 28 Oct 2004 01:48:24 +0000 (GMT) (envelope-from lyndon@orthanc.ca) Received: from d154-5-25-163.bchsia.telus.net (d154-5-25-163.bchsia.telus.net [154.5.25.163]) (authenticated bits=0) by orthanc.ca (8.13.1/8.13.1) with ESMTP id i9S1mIr2067362 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Oct 2004 19:48:20 -0600 (MDT) (envelope-from lyndon@orthanc.ca) Date: Wed, 27 Oct 2004 18:48:17 -0700 From: Lyndon Nerenberg To: freebsd-hackers@freebsd.org, Giorgos Keramidas Message-ID: <83E94C56ED57A6FAEC5C8F33@peregrin.orthanc.ca> In-Reply-To: <20041002081928.GA21439@gothmog.gr> References: <20041002081928.GA21439@gothmog.gr> X-Mailer: Mulberry/4.0.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-DCC-WEiAPG-Metrics: orthanc.ca 1072; Body=2 Fuz1=2 Fuz2=2 X-Spam-Status: No, score=3.4 required=5.0 tests=AWL,BAYES_00, HELO_DYNAMIC_IPADDR,RCVD_IN_NJABL_DUL,RCVD_IN_SORBS_DUL autolearn=no version=3.0.1 X-Spam-Level: *** X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on orthanc.ca X-Mailman-Approved-At: Thu, 28 Oct 2004 12:30:58 +0000 Subject: Re: Protection from the dreaded "rm -fr /" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2004 01:48:24 -0000 --On 2004-10-2 11:19 AM +0300 Giorgos Keramidas wrote: > John Beck, who works for Sun, has posted an entry in his blog > yesterday about "rm -fr /" protection, which I liked a lot: > http://blogs.sun.com/roller/page/jbeck/20041001#rm_rf_protection The best protection from 'rm -rf /' is an AT&T 3B4000 computer. I had the misfortune of dealing with one in the late '80s. After I convinced management that it was ... well ... a waste of time, we held a de-commissioning party. Somewhere around 2030 (hours) I took the liberty to do something I have wanted to do on a live production system for a long time: 1. login as root 2. rm -rf / We did this, in party mode, with a couple of bottles of champaign, streamers, and a bit of Frank Zappa and Cap't Beefheart in the background. By midnight, we were getting worried that last call at the pub would end before the machine. So, we left. And came back. And left again to come back with offsales, on account of said machine not only being deathly slow in life, but also in suicide. I think we gave up around 0530 and just pulled the AC from the box and went home. Or back to the bar. For a month. To get over the brain damage of the 3B4K. (We inflicted less upon ourselves :-) Of course, this was just a little while after All Of Usenet hit 5MB per day, so I don't expect anyone to get this anecdote correct on their MCSE exam :-) --lyndon From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 28 15:19:53 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3809716A4CE for ; Thu, 28 Oct 2004 15:19:53 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id A2E5C43D1F for ; Thu, 28 Oct 2004 15:19:52 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (harmony.village.org [10.0.0.6]) by harmony.village.org (8.13.1/8.13.1) with ESMTP id i9SFJRr5080961; Thu, 28 Oct 2004 09:19:27 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 28 Oct 2004 09:20:03 -0600 (MDT) Message-Id: <20041028.092003.54188194.imp@bsdimp.com> To: strick@covad.net From: "M. Warner Losh" In-Reply-To: <200410281023.i9SAN27L001781@mist.nodomain> References: <200410281023.i9SAN27L001781@mist.nodomain> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org cc: dan@mist.nodomain Subject: Re: questionable feature in FreeBSD pmake X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2004 15:19:53 -0000 In message: <200410281023.i9SAN27L001781@mist.nodomain> Dan Strick writes: : Does anyone know where this feature came from? The .OBJDIR variable was : recognized by the pmake distributed with 4.4 BSD, but the man page for : that version of make does not mention the gratuitous magic rules for : changing the make working directory. The older make program found in : 4.3 BSD does not seem to use the .OBJDIR variable at all. : : This feature is not mentioned in the pmake tutorial found in : /usr/share/doc/psd/12.make. Is it a FreeBSD-ism? Both FreeBSD and NetBSD have this feature. Early in the FreeBSD life cycle, it was imported from NetBSD shortly after the 2.0 tree was imported from 4.4-lite. Warner From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 28 19:50:52 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 719F516A4CE for ; Thu, 28 Oct 2004 19:50:52 +0000 (GMT) Received: from mail805.megamailservers.com (mail805.carrierinternetsolutions.com [69.49.106.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0AD3C43D2F for ; Thu, 28 Oct 2004 19:50:52 +0000 (GMT) (envelope-from strick@covad.net) X-POP-User: strick.covad.net Received: from mist.nodomain (h-67-101-98-29.snfccasy.dynamic.covad.net [67.101.98.29])i9SC1WUs022885; Thu, 28 Oct 2004 08:01:33 -0400 Received: from mist.nodomain (localhost [127.0.0.1]) by mist.nodomain (8.12.11/8.12.11) with ESMTP id i9SC1WvB002008; Thu, 28 Oct 2004 05:01:32 -0700 (PDT) (envelope-from dan@mist.nodomain) Received: (from dan@localhost) by mist.nodomain (8.12.11/8.12.11/Submit) id i9SC1Vk8002007; Thu, 28 Oct 2004 05:01:31 -0700 (PDT) (envelope-from dan) Date: Thu, 28 Oct 2004 05:01:31 -0700 (PDT) From: Dan Strick Message-Id: <200410281201.i9SC1Vk8002007@mist.nodomain> To: freebsd-hackers@freebsd.org cc: dan@mist.nodomain Subject: Re: questionable feature in FreeBSD pmake X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2004 19:50:52 -0000 On Thu, 28 Oct 2004 03:23:02 -0700, I wrote: > > I just spent a *very* frustrating hour trying to figure out why the > FreeBSD make program was invoking all commands to make things in a > subdirectory named "obj". I eventually discovered this gem in the > make man page: > > In addition, make sets or knows about the following internal > variables or environment variables: > > ... > > .OBJDIR A path to the directory where the targets are built. At > startup, make searches for an alternate directory to place > target files. It will attempt to change into this special > directory and will search this directory for > found in the current directory. The following directories > are tried in order: > > 1. ${MAKEOBJDIRPREFIX}/`pwd` > 2. ${MAKEOBJDIR} > 3. obj.${MACHINE} > 4. obj > 5. /usr/obj/`pwd` > ... > A little while later Peter Pentchev responded: > > Actually, this feature lies at the base of the FreeBSD base system build > infrastructure, and it is pretty much The Feature that allows us to > build from read-only and/or NFS-mounted sources shared among wide swarms > of machines :) > and > > Oh, and let's not forget cross-platform builds, too. > It is clear that a great deal of current FreeBSD OS makefile practice depends on the feature. The tragedy is that it was never necessary to make the feature unavoidable. Its invocation should have been dependent on using a special environment variable or make command option or makefile command or makefile variable. Unfortunately, it seems that its invocation depends only on the presence of a subdirectory named "obj" in the directory in which the make command is invoked and there is NO WAY to avoid it. There seems to be absolutely nothing that I can put in my makefile to turn the feature off or to undo its effect. It seems that I have no alternative but to rename my "obj" directory. Can someone suggest an alternative? Note that it is not possible for me to set an environment variable (i.e. MAKEOBJDIR) before running make or to add an option to the make command line. Any fix must be contained entirely within the makefile. Setting .OBJDIR or MAKEOBJDIR within the makefile does not work. Placing a "cd .." or "cd $(.CURDIR)" in front of every set of makefile shell commands is unthinkable. Dan Strick strick@covad.net (now *immensely* frustrated) From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 29 03:23:04 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A228816A4CF for ; Fri, 29 Oct 2004 03:23:04 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id A176743D49 for ; Fri, 29 Oct 2004 03:23:03 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (harmony.village.org [10.0.0.6]) by harmony.village.org (8.13.1/8.13.1) with ESMTP id i9T3K358087717; Thu, 28 Oct 2004 21:20:03 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 28 Oct 2004 21:20:41 -0600 (MDT) Message-Id: <20041028.212041.42773022.imp@bsdimp.com> To: strick@covad.net From: "M. Warner Losh" In-Reply-To: <200410281201.i9SC1Vk8002007@mist.nodomain> References: <200410281201.i9SC1Vk8002007@mist.nodomain> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org cc: dan@mist.nodomain Subject: Re: questionable feature in FreeBSD pmake X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2004 03:23:04 -0000 In message: <200410281201.i9SC1Vk8002007@mist.nodomain> Dan Strick writes: : Unfortunately, it seems that its invocation : depends only on the presence of a subdirectory named "obj" in the directory : in which the make command is invoked and there is NO WAY to avoid it. setenv MAKEOBJDIR something-long-and-unlikely So there is a way to avoid it. Warner From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 29 04:12:58 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CEBC216A4CE for ; Fri, 29 Oct 2004 04:12:58 +0000 (GMT) Received: from mail.farley.org (farley.org [67.64.95.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7450B43D1F for ; Fri, 29 Oct 2004 04:12:58 +0000 (GMT) (envelope-from sean-freebsd@farley.org) Received: from thor.farley.org (bwrlvz8gkiej7ltt@thor.farley.org [IPv6:2002:4340:5fcd:1::5]) by mail.farley.org (8.13.1/8.13.1) with ESMTP id i9T4CpkX087047; Thu, 28 Oct 2004 23:12:51 -0500 (CDT) (envelope-from sean-freebsd@farley.org) Received: from thor.farley.org (localhost [127.0.0.1]) by thor.farley.org (8.13.1/8.13.1) with ESMTP id i9T4Co4p044784; Thu, 28 Oct 2004 23:12:50 -0500 (CDT) (envelope-from sean-freebsd@farley.org) Received: from localhost (sean@localhost)i9T4CoVM044781; Thu, 28 Oct 2004 23:12:50 -0500 (CDT) (envelope-from sean-freebsd@farley.org) X-Authentication-Warning: thor.farley.org: sean owned process doing -bs Date: Thu, 28 Oct 2004 23:12:50 -0500 (CDT) From: Sean Farley X-X-Sender: sean@thor.farley.org To: Dan Strick In-Reply-To: <200410281201.i9SC1Vk8002007@mist.nodomain> Message-ID: <20041028225223.W44325@thor.farley.org> References: <200410281201.i9SC1Vk8002007@mist.nodomain> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: freebsd-hackers@freebsd.org cc: dan@mist.nodomain Subject: Re: questionable feature in FreeBSD pmake X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2004 04:12:58 -0000 On Thu, 28 Oct 2004, Dan Strick wrote: > On Thu, 28 Oct 2004 03:23:02 -0700, Dan Strick wrote: >> >> I just spent a *very* frustrating hour trying to figure out why the >> FreeBSD make program was invoking all commands to make things in a >> subdirectory named "obj". I just noticed this is in the BUGS section of make: The determination of .OBJDIR is contorted to the point of absurdity. > It seems that I have no alternative but to rename my "obj" directory. > Can someone suggest an alternative? Note that it is not possible for > me to set an environment variable (i.e. MAKEOBJDIR) before running > make or to add an option to the make command line. Any fix must be > contained entirely within the makefile. Setting .OBJDIR or MAKEOBJDIR > within the makefile does not work. Placing a "cd .." or "cd > $(.CURDIR)" in front of every set of makefile shell commands is > unthinkable. Why are you unable to do anything with the command-line? Any of these will solve your problem. Bourne: MAKEOBJDIR=/no_obj_here make Bourne or CSH: env MAKEOBJDIR=/no_obj_here make Here is a Makefile that does not use obj/. The special targets can be placed into a file to be included into all your Makefiles. It only suffers from a failed build where it will not rename obj to tmpobj. ----------------------- .BEGIN: mv tmpobj obj || mkdir obj .INTERRUPT: mv obj tmpobj .END: mv obj tmpobj all: touch testing clean: rm -f testing ----------------------- Sean -- sean-freebsd@farley.org From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 29 06:50:50 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0C32716A4CE for ; Fri, 29 Oct 2004 06:50:50 +0000 (GMT) Received: from n33.kp.t-systems-sfr.com (n33.kp.t-systems-sfr.com [129.247.16.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id 207FE43D46 for ; Fri, 29 Oct 2004 06:50:49 +0000 (GMT) (envelope-from harti@freebsd.org) Received: from n81.sp.op.dlr.de (n81g.sp.op.dlr.de [129.247.163.1]) i9T6oTU265968; Fri, 29 Oct 2004 08:50:30 +0200 Received: from zeus.nt.op.dlr.de (zeus.nt.op.dlr.de [129.247.173.3]) i9T6oSI132194; Fri, 29 Oct 2004 08:50:28 +0200 Received: from beagle.kn.op.dlr.de (opkndnwsbsd178 [129.247.173.178]) by zeus.nt.op.dlr.de (8.11.7+Sun/8.9.1) with ESMTP id i9T6ohe03024; Fri, 29 Oct 2004 08:50:44 +0200 (MET DST) Date: Fri, 29 Oct 2004 08:50:29 +0200 (CEST) From: Harti Brandt X-X-Sender: brandt@beagle.kn.op.dlr.de To: Dan Strick In-Reply-To: <200410281201.i9SC1Vk8002007@mist.nodomain> Message-ID: <20041029084715.C52069@beagle.kn.op.dlr.de> References: <200410281201.i9SC1Vk8002007@mist.nodomain> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-hackers@freebsd.org cc: dan@mist.nodomain Subject: Re: questionable feature in FreeBSD pmake X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Harti Brandt List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2004 06:50:50 -0000 On Thu, 28 Oct 2004, Dan Strick wrote: DS>On Thu, 28 Oct 2004 03:23:02 -0700, I wrote: DS>> DS>> I just spent a *very* frustrating hour trying to figure out why the DS>> FreeBSD make program was invoking all commands to make things in a DS>> subdirectory named "obj". I eventually discovered this gem in the DS>> make man page: DS>> DS>> In addition, make sets or knows about the following internal DS>> variables or environment variables: DS>> DS>> ... DS>> DS>> .OBJDIR A path to the directory where the targets are built. At DS>> startup, make searches for an alternate directory to place DS>> target files. It will attempt to change into this special DS>> directory and will search this directory for DS>> found in the current directory. The following directories DS>> are tried in order: DS>> DS>> 1. ${MAKEOBJDIRPREFIX}/`pwd` DS>> 2. ${MAKEOBJDIR} DS>> 3. obj.${MACHINE} DS>> 4. obj DS>> 5. /usr/obj/`pwd` DS>> ... DS>> DS> DS>A little while later Peter Pentchev responded: DS>> DS>> Actually, this feature lies at the base of the FreeBSD base system build DS>> infrastructure, and it is pretty much The Feature that allows us to DS>> build from read-only and/or NFS-mounted sources shared among wide swarms DS>> of machines :) DS>> DS>and DS>> DS>> Oh, and let's not forget cross-platform builds, too. DS>> DS> DS>It is clear that a great deal of current FreeBSD OS makefile practice DS>depends on the feature. The tragedy is that it was never necessary to DS>make the feature unavoidable. Its invocation should have been dependent DS>on using a special environment variable or make command option or makefile DS>command or makefile variable. Unfortunately, it seems that its invocation DS>depends only on the presence of a subdirectory named "obj" in the directory DS>in which the make command is invoked and there is NO WAY to avoid it. DS>There seems to be absolutely nothing that I can put in my makefile to DS>turn the feature off or to undo its effect. I think this should be made conditional on the .POSIX target in the makefile. This way we don't loose this feature for system build but make our make more useable for outside packages. I have not yet looked into this. harti DS> DS>It seems that I have no alternative but to rename my "obj" directory. DS>Can someone suggest an alternative? Note that it is not possible for me DS>to set an environment variable (i.e. MAKEOBJDIR) before running make or DS>to add an option to the make command line. Any fix must be contained DS>entirely within the makefile. Setting .OBJDIR or MAKEOBJDIR within the DS>makefile does not work. Placing a "cd .." or "cd $(.CURDIR)" in front of DS>every set of makefile shell commands is unthinkable. DS> DS>Dan Strick DS>strick@covad.net DS> DS>(now *immensely* frustrated) DS>_______________________________________________ DS>freebsd-hackers@freebsd.org mailing list DS>http://lists.freebsd.org/mailman/listinfo/freebsd-hackers DS>To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" DS> DS> DS> From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 29 07:02:14 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7417F16A4CE for ; Fri, 29 Oct 2004 07:02:14 +0000 (GMT) Received: from n33.kp.t-systems-sfr.com (n33.kp.t-systems-sfr.com [129.247.16.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id A397743D58 for ; Fri, 29 Oct 2004 07:02:11 +0000 (GMT) (envelope-from harti@freebsd.org) Received: from n81.sp.op.dlr.de (n81g.sp.op.dlr.de [129.247.163.1]) i9T71uU577580; Fri, 29 Oct 2004 09:01:56 +0200 Received: from zeus.nt.op.dlr.de (zeus.nt.op.dlr.de [129.247.173.3]) i9T71tI137480; Fri, 29 Oct 2004 09:01:55 +0200 Received: from beagle.kn.op.dlr.de (opkndnwsbsd178 [129.247.173.178]) by zeus.nt.op.dlr.de (8.11.7+Sun/8.9.1) with ESMTP id i9T72Ae03163; Fri, 29 Oct 2004 09:02:11 +0200 (MET DST) Date: Fri, 29 Oct 2004 09:01:57 +0200 (CEST) From: Harti Brandt X-X-Sender: brandt@beagle.kn.op.dlr.de To: Sean Farley In-Reply-To: <20041028225223.W44325@thor.farley.org> Message-ID: <20041029090051.M52069@beagle.kn.op.dlr.de> References: <200410281201.i9SC1Vk8002007@mist.nodomain> <20041028225223.W44325@thor.farley.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Dan Strick cc: freebsd-hackers@freebsd.org Subject: Re: questionable feature in FreeBSD pmake X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Harti Brandt List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2004 07:02:14 -0000 On Thu, 28 Oct 2004, Sean Farley wrote: SF>On Thu, 28 Oct 2004, Dan Strick wrote: SF> SF>> On Thu, 28 Oct 2004 03:23:02 -0700, Dan Strick wrote: SF>> > SF>> > I just spent a *very* frustrating hour trying to figure out why the SF>> > FreeBSD make program was invoking all commands to make things in a SF>> > subdirectory named "obj". SF> SF>I just noticed this is in the BUGS section of make: SF> The determination of .OBJDIR is contorted to the point of SF> absurdity. SF> SF>> It seems that I have no alternative but to rename my "obj" directory. SF>> Can someone suggest an alternative? Note that it is not possible for SF>> me to set an environment variable (i.e. MAKEOBJDIR) before running SF>> make or to add an option to the make command line. Any fix must be SF>> contained entirely within the makefile. Setting .OBJDIR or MAKEOBJDIR SF>> within the makefile does not work. Placing a "cd .." or "cd SF>> $(.CURDIR)" in front of every set of makefile shell commands is SF>> unthinkable. SF> SF>Why are you unable to do anything with the command-line? Any of these SF>will solve your problem. SF>Bourne: SF>MAKEOBJDIR=/no_obj_here make SF> SF>Bourne or CSH: SF>env MAKEOBJDIR=/no_obj_here make SF> SF>Here is a Makefile that does not use obj/. The special targets can be SF>placed into a file to be included into all your Makefiles. It only SF>suffers from a failed build where it will not rename obj to tmpobj. SF> SF>----------------------- SF>.BEGIN: SF> mv tmpobj obj || mkdir obj SF> SF>.INTERRUPT: SF> mv obj tmpobj .INTERRUPT is dangerous at the moment, because it is not called always and it's sometimes called in the wrong place. I have a fix for this. harti SF> SF>.END: SF> mv obj tmpobj SF> SF>all: SF> touch testing SF> SF>clean: SF> rm -f testing SF>----------------------- SF> SF>Sean SF> From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 29 00:30:34 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C8C9E16A4CE for ; Fri, 29 Oct 2004 00:30:34 +0000 (GMT) Received: from simmts8-srv.bellnexxia.net (simmts8.bellnexxia.net [206.47.199.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6B3E343D3F for ; Fri, 29 Oct 2004 00:30:33 +0000 (GMT) (envelope-from allan@skene.net) Received: from kipper ([142.177.207.2]) by simmts8-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with SMTP id <20041029003032.XTBF1692.simmts8-srv.bellnexxia.net@kipper> for ; Thu, 28 Oct 2004 20:30:32 -0400 Message-ID: <028f01c4bd4e$88167b50$6600a8c0@kipper> From: "Allan Marshall" To: Date: Thu, 28 Oct 2004 21:30:45 -0300 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailman-Approved-At: Fri, 29 Oct 2004 12:22:01 +0000 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: 4.8-STABLE kernel crash X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2004 00:30:35 -0000 The box has been quite unstable, with restarts every few days this is the first dump ive got with DDB I realize this likely isnt enough information, but if you could point me = in the right direction I can provide anymore information required. uname -a FreeBSD ******************* 4.8-STABLE FreeBSD 4.8-STABLE #1: Sun Sep 19 = 21:04:55 GMT 2004 Allan@********:/usr/src/sys/compile/IRCD i386 (kgdb) where #0 dumpsys () at ../../kern/kern_shutdown.c:487 #1 0xc017c3af in boot (howto=3D256) at ../../kern/kern_shutdown.c:316 #2 0xc017c7d4 in poweroff_wait (junk=3D0xc02b182c, howto=3D-1070918865) at ../../kern/kern_shutdown.c:595 #3 0xc0261e1a in trap_fatal (frame=3D0xf79ace3c, eva=3D983060) at ../../i386/i386/trap.c:974 #4 0xc0261aed in trap_pfault (frame=3D0xf79ace3c, usermode=3D0, = eva=3D983060) at ../../i386/i386/trap.c:867 #5 0xc02616d7 in trap (frame=3D{tf_fs =3D -1070923760, tf_es =3D = -147914736, tf_ds =3D 16973840, tf_edi =3D 672440320, tf_esi =3D 227, tf_ebp = =3D -140849532, tf_isp =3D -140849560, tf_ebx =3D -148367476, tf_edx =3D 983040, tf_ecx =3D 250428367, tf_eax =3D 524281, tf_trapno =3D 12, tf_err = =3D 0, tf_eip =3D -1071494896, tf_cs =3D 8, tf_eflags =3D 66054, tf_esp = =3D 0, tf_ss =3D -140786112}) at ../../i386/i386/trap.c:466 #6 0xc0224910 in vm_page_lookup (object=3D0xf728178c, pindex=3D227) at ../../vm/vm_page.c:515 #7 0xc021cc70 in vm_fault (map=3D0xf79bc640, vaddr=3D672440320, fault_type=3D1 '\001', fault_flags=3D0) at ../../vm/vm_fault.c:292 #8 0xc0261a82 in trap_pfault (frame=3D0xf79acfa8, usermode=3D1, = eva=3D672441792) at ../../i386/i386/trap.c:847 #9 0xc02615ab in trap (frame=3D{tf_fs =3D 47, tf_es =3D 47, tf_ds =3D = 47, tf_edi =3D 672514096, tf_esi =3D 0, tf_ebp =3D -1077937344, tf_isp =3D -140849196, tf_ebx =3D 672505356, tf_edx =3D 0, tf_ecx = =3D 134533128, tf_eax =3D 1008, tf_trapno =3D 12, tf_err =3D 4, tf_eip =3D = 672010244, tf_cs =3D 31, tf_eflags =3D 66054, tf_esp =3D -1077937368, tf_ss = =3D 47}) at ../../i386/i386/trap.c:377 #10 0x280e1004 in ?? () #11 0x280e10bd in ?? () #12 0x280e70e5 in ?? () #13 0x28085174 in ?? () #14 0x8048f66 in ?? () #15 0x8048e4a in ?? () (kgdb) From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 29 11:17:41 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B2A7916A4CE for ; Fri, 29 Oct 2004 11:17:41 +0000 (GMT) Received: from tx5.mail.ox.ac.uk (tx5.mail.ox.ac.uk [163.1.2.169]) by mx1.FreeBSD.org (Postfix) with ESMTP id C4A1743D55 for ; Fri, 29 Oct 2004 11:17:40 +0000 (GMT) (envelope-from neil.hoggarth@physiol.ox.ac.uk) Received: from scan5.mail.ox.ac.uk ([163.1.2.177] helo=localhost) by tx5.mail.ox.ac.uk with esmtp (Exim 4.42) id 1CNUlH-0000zc-I3 for freebsd-hackers@freebsd.org; Fri, 29 Oct 2004 12:17:39 +0100 Received: from rx5.mail.ox.ac.uk ([163.1.2.168]) by localhost (scan5.mail.ox.ac.uk [163.1.2.177]) (amavisd-new, port 25) with ESMTP id 03432-01 for ; Fri, 29 Oct 2004 12:17:39 +0100 (BST) Received: from wren.physiol.ox.ac.uk ([163.1.249.100] helo=mail.physiol.ox.ac.uk) by rx5.mail.ox.ac.uk with esmtp (Exim 4.42) id 1CNUlG-0000zE-JA; Fri, 29 Oct 2004 12:17:38 +0100 Received: from saros.physiol (saros.physiol [163.1.249.131]) i9TBHcpX011312; Fri, 29 Oct 2004 12:17:38 +0100 (BST) Date: Fri, 29 Oct 2004 12:17:35 +0100 (BST) From: Neil Hoggarth X-X-Sender: njh@saros.physiol To: freebsd-hackers@freebsd.org In-Reply-To: <4168F9E7.9040408@DeepCore.dk> Message-ID: References: <200410081937.15068.miha@ghuug.org> <41682D3F.4060902@DeepCore.dk> <200410091843.06854.miha@ghuug.org> <4168F9E7.9040408@DeepCore.dk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE X-Mailman-Approved-At: Fri, 29 Oct 2004 12:22:01 +0000 cc: =?iso-8859-1?Q?S=F8ren_Schmidt?= Subject: Re: ad0: FAILURE - WRITE_DMA X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2004 11:17:41 -0000 On 8th October, Mikhail P. reported the error: ad0: FAILURE - WRITE_DMA status=3D51 error=3D10 LBA=3D268435455 On Sun, 10 Oct 2004, S=F8ren Schmidt wrote: > so that leaves the disks for scrutiny. One thing to try is change the > tripping point where we switch from 28bit mode to 48 bit mode, could be > a 1 off error in the firmware... This sounds very possible to me. I have been experiencing the same error, on a system that I've been trying to set up using 5.3-RC1 and a new 160Gbyte SATA drives My hardware is: atapci0: port 0xb000-0xb00f,0xac00-0xac03,0xa= 800-0xa807,0xa400-0xa403,0xa000-0xa007 mem 0xdf081000-0xdf0811ff irq 18 at = device 11.0 on pci1 ad4: 152627MB [310101/16/63] at ata2-master SATA150 (I notice that Michail and I both have Seagate drives ...). I had problems with a filesystem on a partition which crossed the LBA=3D268435455 threshold. After googling and reading this thread and S=F8ren's posting, I tried removing the filesystem and making a little 1000 sector partition which straddled the lba48 transition sector - I was able to get read and write failure messages of the above form reproducibly, by dd-ing between the test partition and /dev/zero. I edited the /usr/src/sys/dev/ata/ata-lowlevel.c file and reduced the 48-bit trigger level by one: --- ata-lowlevel.c.orig Fri Oct 29 12:06:09 2004 +++ ata-lowlevel.c Fri Oct 29 12:05:38 2004 @@ -700,7 +700,7 @@ ATA_IDX_OUTB(atadev->channel, ATA_ALTSTAT, ATA_A_4BIT); /* only use 48bit addressing if needed (avoid bugs and overhead) */ - if ((lba > 268435455 || count > 256) && atadev->param && + if ((lba > 268435454 || count > 256) && atadev->param && atadev->param->support.command2 & ATA_SUPPORT_ADDRESS48) { /* translate command into 48bit version */ and built a new kernel (I'm using the stock GENERIC configuration). The resulting kernel was able to dd to and from the test partition without error. I've now created a new filesystem that uses this part of the disk and restored the contents from backup, and have been actively using the filesystem for the last day without observing any further problems. Regards, --=20 Neil Hoggarth Departmental Computing Manager Laboratory of Physiology http://www.physiol.ox.ac.uk/~njh/ University of Oxford, UK From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 29 14:14:51 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E11B916A4CE for ; Fri, 29 Oct 2004 14:14:51 +0000 (GMT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9B1D543D46 for ; Fri, 29 Oct 2004 14:14:51 +0000 (GMT) (envelope-from joseph.koshy@gmail.com) Received: by wproxy.gmail.com with SMTP id 65so671607wri for ; Fri, 29 Oct 2004 07:14:32 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=XzeJGFccLOjesgZNtdV9B/2LwxhciquDnZczb5nFa8FNzMw8cu196FfR4QcY0eqcaVkWTCABgBqs4ytpx9uD4ZiZLr6vubWFQ1/wYuLYtmT918ZhLL7jTnFpFTLAZklW9DOPMnvMeFM3YxKeCqg9iXC5AzaiNXGmCKgF9lDqGKQ= Received: by 10.38.218.39 with SMTP id q39mr1847292rng; Fri, 29 Oct 2004 07:14:31 -0700 (PDT) Received: by 10.38.13.37 with HTTP; Fri, 29 Oct 2004 07:14:31 -0700 (PDT) Message-ID: <84dead72041029071432cb3195@mail.gmail.com> Date: Fri, 29 Oct 2004 14:14:31 +0000 From: Joseph Koshy To: Allan Marshall In-Reply-To: <028f01c4bd4e$88167b50$6600a8c0@kipper> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <028f01c4bd4e$88167b50$6600a8c0@kipper> cc: hackers@freebsd.org Subject: Re: 4.8-STABLE kernel crash X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Joseph Koshy List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2004 14:14:52 -0000 On Thu, 28 Oct 2004 21:30:45 -0300, Allan Marshall wrote: > The box has been quite unstable, with restarts every few days > this is the first dump ive got with DDB > I realize this likely isnt enough information, but if you could point me in the right direction > I can provide anymore information required. 1) dmesg output please 2) Is this a new problem? Did the box run FreeBSD stably earlier? From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 29 15:35:09 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B620A16A4CE for ; Fri, 29 Oct 2004 15:35:09 +0000 (GMT) Received: from mailserv1.neuroflux.com (mailserv1.neuroflux.com [204.228.228.92]) by mx1.FreeBSD.org (Postfix) with ESMTP id 68FF543D3F for ; Fri, 29 Oct 2004 15:35:09 +0000 (GMT) (envelope-from ryans@gamersimpact.com) Received: (qmail 72499 invoked by uid 89); 29 Oct 2004 15:32:38 -0000 Received: from unknown (HELO www2.neuroflux.com) (127.0.0.1) by localhost with SMTP; 29 Oct 2004 15:32:38 -0000 Received: from 128.101.36.205 (SquirrelMail authenticated user ryans@gamersimpact.com); by www2.neuroflux.com with HTTP; Fri, 29 Oct 2004 09:32:38 -0600 (MDT) Message-ID: <18888.128.101.36.205.1099063958.squirrel@128.101.36.205> Date: Fri, 29 Oct 2004 09:32:38 -0600 (MDT) From: "Ryan Sommers" To: hackers@freebsd.org User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: GEOM whitepaper? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2004 15:35:09 -0000 Are there any whitepapers, documentation, etc (aside from the new book about 5.2) on GEOM? I've been reading over the code and it would be nice to have an annotation to go with it. -- Ryan Sommers ryans@gamersimpact.com From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 29 16:01:45 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 304EA16A4CE for ; Fri, 29 Oct 2004 16:01:45 +0000 (GMT) Received: from smtp.des.no (flood.des.no [217.116.83.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8D9AE43D2D for ; Fri, 29 Oct 2004 16:01:44 +0000 (GMT) (envelope-from des@des.no) Received: by smtp.des.no (Pony Express, from userid 666) id D89B65311; Fri, 29 Oct 2004 18:01:42 +0200 (CEST) Received: from dwp.des.no (des.no [80.203.228.37]) by smtp.des.no (Pony Express) with ESMTP id 1396C530A; Fri, 29 Oct 2004 18:01:35 +0200 (CEST) Received: by dwp.des.no (Postfix, from userid 2602) id DB335B85E; Fri, 29 Oct 2004 18:01:35 +0200 (CEST) To: "Ryan Sommers" References: <18888.128.101.36.205.1099063958.squirrel@128.101.36.205> From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) Date: Fri, 29 Oct 2004 18:01:35 +0200 In-Reply-To: <18888.128.101.36.205.1099063958.squirrel@128.101.36.205> (Ryan Sommers's message of "Fri, 29 Oct 2004 09:32:38 -0600 (MDT)") Message-ID: User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on flood.des.no X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.64 cc: hackers@freebsd.org Subject: Re: GEOM whitepaper? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2004 16:01:45 -0000 "Ryan Sommers" writes: > Are there any whitepapers, documentation, etc (aside from the new book > about 5.2) on GEOM? I've been reading over the code and it would be nice > to have an annotation to go with it. http://www.google.com/search?q=3Dphk+geom+paper DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 29 16:44:47 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9D5FE16A4CE for ; Fri, 29 Oct 2004 16:44:47 +0000 (GMT) Received: from cydem.org (S0106000103ce4c9c.ed.shawcable.net [68.149.254.167]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3322943D45 for ; Fri, 29 Oct 2004 16:44:47 +0000 (GMT) (envelope-from soralx@cydem.org) Received: from S01060020ed3972ba.ed.shawcable.net (S01060020ed3972ba.ed.shawcable.net [68.149.254.42]) by cydem.org (Postfix/FreeBSD) with ESMTP id 62C3138A84 for ; Fri, 29 Oct 2004 10:44:46 -0600 (MDT) From: To: freebsd-hackers@freebsd.org Date: Fri, 29 Oct 2004 10:44:34 -0600 User-Agent: KMail/1.5.4 References: <200410081937.15068.miha@ghuug.org> <4168F9E7.9040408@DeepCore.dk> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Message-Id: <200410291044.34973.soralx@cydem.org> Subject: Re: ad0: FAILURE - WRITE_DMA X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2004 16:44:47 -0000 > This sounds very possible to me. I have been experiencing the same > error, on a system that I've been trying to set up using 5.3-RC1 and > a new 160Gbyte SATA drives My hardware is: > > atapci0: port > 0xb000-0xb00f,0xac00-0xac03,0xa800-0xa807,0xa400-0xa403,0xa000-0xa007 mem > 0xdf081000-0xdf0811ff irq 18 at device 11.0 on pci1 ad4: 152627MB > [310101/16/63] at ata2-master SATA150 > > (I notice that Michail and I both have Seagate drives ...). > > I had problems with a filesystem on a partition which crossed the > LBA=268435455 threshold. After googling and reading this thread and > Søren's posting, I tried removing the filesystem and making a little > 1000 sector partition which straddled the lba48 transition sector - I was > able to get read and write failure messages of the above form > reproducibly, by dd-ing between the test partition and /dev/zero. The same problem with similar IDE Seagate HDD: ad0: ATA-6 disk at ata0-master ad0: 152627MB (312581808 sectors), 310101 C, 16 H, 63 S, 512 B [...] ad0: FAILURE - READ_DMA status=51 error=10 LBA=268435455 It had 312581808 sectors, but failed at >= 268435455 : bash-2.05b# dd if=/dev/ad0 of=/dev/null bs=512 skip=268435453 dd: /dev/ad0: Input/output error 2+0 records in 2+0 records out 1024 bytes transferred in 0.163827 secs (6250 bytes/sec) bash-2.05b# dd if=/dev/ad0 of=/dev/null bs=512 skip=268435454 dd: /dev/ad0: Input/output error 1+0 records in 1+0 records out 512 bytes transferred in 0.156888 secs (3263 bytes/sec) bash-2.05b# dd if=/dev/ad0 of=/dev/null bs=512 skip=268435455 dd: /dev/ad0: Input/output error 0+0 records in 0+0 records out 0 bytes transferred in 0.149888 secs (0 bytes/sec) Decreasing the 48-bit LBA threshold by 1 really helped: bash-2.05b# dd if=/dev/ad0 bs=512 skip=312581808 0+0 records in 0+0 records out 0 bytes transferred in 0.000088 secs (0 bytes/sec) bash-2.05b# dd if=/dev/ad0 bs=512 skip=312581807 1+0 records in 1+0 records out 512 bytes transferred in 0.019809 secs (25847 bytes/sec) Timestamp: 0x41826DE9 [SorAlx] http://cydem.org.ua/ ridin' VN1500-B2 From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 29 16:49:25 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A66EC16A4CE for ; Fri, 29 Oct 2004 16:49:25 +0000 (GMT) Received: from mail-svr1.cs.utah.edu (brahma.cs.utah.edu [155.98.64.200]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5000943D1F for ; Fri, 29 Oct 2004 16:49:25 +0000 (GMT) (envelope-from saggarwa@cs.utah.edu) Received: from faith.cs.utah.edu (faith.cs.utah.edu [155.98.65.40]) by mail-svr1.cs.utah.edu (Postfix) with ESMTP id CFA5A346F4 for ; Fri, 29 Oct 2004 10:49:24 -0600 (MDT) Received: by faith.cs.utah.edu (Postfix, from userid 4973) id B21182EC21; Fri, 29 Oct 2004 10:49:24 -0600 (MDT) Received: from localhost (localhost [127.0.0.1]) by faith.cs.utah.edu (Postfix) with ESMTP id A9CB934406 for ; Fri, 29 Oct 2004 16:49:24 +0000 (UTC) Date: Fri, 29 Oct 2004 10:49:24 -0600 (MDT) From: Siddharth Aggarwal To: freebsd-hackers@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: flushing disk buffer cache X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2004 16:49:25 -0000 Hi, I am writing this pseudo disk driver for disk checkpointing, which intercepts write requests to the disk (ad0s1) and performs a copy on write of the old contents to another partition (ad0s4) before writing out the new contents. So the driver (called shd) is mounted as /dev/shd0a on / /dev/shd0f on /usr So each time the user creates a new checkpoint (basically initialize new data structures in memory for a new checkpoint), right before that inside the driver, I explicitly do a sync() to flush out the disk buffer cache, so that disk state is consistent when the checkpoint was taken. Then, I have hacked the reboot system call to revert to a previous checkpoint after unmounting all the filesystems but before halting the system. This revert basically involves copying some blocks from ad0s4 to ad0s1. However, when the system reboots, fsck shows up inconsistencies in the filesystem and so fsck needs to be run manually. So I suspect that the reason for this problem is that when a checkpoint is taken, the filesystem on ad0s1 is active and more write operations are coming in i.e. filesystem on ad0s1 is still dirty. Hence I explicitly called sync() before returning from the checkpoint command but I think sync() doesnt guarantee that everything was actually flushed out. So I implemented a more mandatory way of syncing, i.e. just got part of the code from boot() system call. The code is as below, and it is called whenever a checkpoint command is fired. Does anyone think if this is the right way of flushing the cache? Is there anything I can do to ensure the filesystem is consistent during reboot? I don't think this is a problem in the driver code, because when I created a new filesystem on ad0s3 and shadowed that using the driver, everything ran perfectly fine, but the difference was that I could unmount the filesystem before "restoring the checkpoint" and hence wasnt necessary to do it during reboot time. void sync_before_checkpoint (void) { register struct buf *bp; int iter, nbusy, pbusy; waittime = 0; sync(&proc0, NULL); /* * With soft updates, some buffers that are * written will be remarked as dirty until other * buffers are written. */ for (iter = pbusy = 0; iter < 20; iter++) { nbusy = 0; for (bp = &buf[nbuf]; --bp >= buf; ) { if ((bp->b_flags & B_INVAL) == 0 && BUF_REFCNT(bp) > 0) { nbusy++; } else if ((bp->b_flags & (B_DELWRI | B_INVAL)) == B_DELWRI) { /* bawrite(bp);*/ nbusy++; } } if (nbusy == 0) break; printf("%d ", nbusy); if (nbusy < pbusy) iter = 0; pbusy = nbusy; if (iter > 5 && bioops.io_sync) (*bioops.io_sync)(NULL); sync(&proc0, NULL); DELAY(50000 * iter); } /* * Count only busy local buffers to prevent forcing * a fsck if we're just a client of a wedged NFS server */ nbusy = 0; for (bp = &buf[nbuf]; --bp >= buf; ) { if (((bp->b_flags&B_INVAL) == 0 && BUF_REFCNT(bp)) || ((bp->b_flags & (B_DELWRI|B_INVAL)) == B_DELWRI)) { if (bp->b_dev == NODEV) { TAILQ_REMOVE(&mountlist, bp->b_vp->v_mount, mnt_list); continue; } nbusy++; } } if (nbusy) { /* * Failed to sync all blocks. Indicate this and don't * unmount filesystems (thus forcing an fsck on reboot). */ printf("giving up on %d buffers\n", nbusy); DELAY(5000000); /* 5 seconds */ } } From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 29 16:50:50 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4F52516A4FF for ; Fri, 29 Oct 2004 16:50:50 +0000 (GMT) Received: from beer.ux6.net (beer.ux6.net [64.62.253.29]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9A10943D4C for ; Fri, 29 Oct 2004 16:50:49 +0000 (GMT) (envelope-from miha@ghuug.org) Received: from [64.62.253.84] (helo=m) by beer.ux6.net with esmtpa (Exim 4.43 (FreeBSD)) id 1CNZxP-0002Yn-Dm for freebsd-hackers@freebsd.org; Fri, 29 Oct 2004 09:50:33 -0700 From: "Mikhail P." To: freebsd-hackers@freebsd.org Date: Fri, 29 Oct 2004 16:50:27 +0000 User-Agent: KMail/1.7 References: <200410081937.15068.miha@ghuug.org> <200410291044.34973.soralx@cydem.org> In-Reply-To: <200410291044.34973.soralx@cydem.org> Organization: Ghana Unix Users Group MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200410291650.27058.miha@ghuug.org> X-Spam-Score: -4.9 (----) X-Spam-Report: Spam detection software, running on the system "beer.ux6.net", hasmessageblock similar future email. If you have any questions, see the administrator of that system for details. Content preview: On Friday 29 October 2004 16:44, soralx@cydem.org wrote: > The same problem with similar IDE Seagate HDD: > > ad0: (312581808READ_DMA statusQ error > LBA&8435455 [...] Content analysis details: (-4.9 points, 6.0 required) pts rule name description --------------------------------------------------1% [score: 0.0000] 0.0 UPPERCASE_25_50 message body is 25-50% uppercase Subject: Re: ad0: FAILURE - WRITE_DMA X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: miha@ghuug.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2004 16:50:50 -0000 On Friday 29 October 2004 16:44, soralx@cydem.org wrote: > The same problem with similar IDE Seagate HDD: > > ad0: ATA-6 disk at ata0-master > ad0: 152627MB (312581808 sectors), 310101 C, 16 H, 63 S, 512 B > [...] > ad0: FAILURE - READ_DMA status=51 error=10 > LBA=268435455 Perhaps it is only Seagate <-> FreeBSD5-related. Same drives, but with FreeBSD4 do work well together without a glitch. regards, M. From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 29 16:57:43 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DC2D816A4CE for ; Fri, 29 Oct 2004 16:57:43 +0000 (GMT) Received: from beer.ux6.net (beer.ux6.net [64.62.253.29]) by mx1.FreeBSD.org (Postfix) with ESMTP id C797943D2D for ; Fri, 29 Oct 2004 16:57:43 +0000 (GMT) (envelope-from miha@ghuug.org) Received: from [64.62.253.84] (helo=m) by beer.ux6.net with esmtpa (Exim 4.43 (FreeBSD)) id 1CNa4H-000I9K-PK for freebsd-hackers@freebsd.org; Fri, 29 Oct 2004 09:57:41 -0700 From: "Mikhail P." To: freebsd-hackers@freebsd.org Date: Fri, 29 Oct 2004 16:57:33 +0000 User-Agent: KMail/1.7 References: <200410081937.15068.miha@ghuug.org> <200410291044.34973.soralx@cydem.org> <200410291650.27058.miha@ghuug.org> In-Reply-To: <200410291650.27058.miha@ghuug.org> Organization: Ghana Unix Users Group MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200410291657.33606.miha@ghuug.org> X-Spam-Score: -4.9 (----) X-Spam-Report: Spam detection software, running on the system "beer.ux6.net", hasmessageblock similar future email. If you have any questions, see the administrator of that system for details.>with > FreeBSD4 do work well together without a glitch. Actually not only seagates.. similar happened on a 200GB Western Digital drive to me, FreeBSD-5.3. [...] Content analysis details: (-4.9 points, 6.0 required) pts rule name description --------------------------------------------------1% [score: 0.0000] Subject: Re: ad0: FAILURE - WRITE_DMA X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: miha@ghuug.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2004 16:57:44 -0000 On Friday 29 October 2004 16:50, Mikhail P. wrote: > Perhaps it is only Seagate <-> FreeBSD5-related. Same drives, but with > FreeBSD4 do work well together without a glitch. Actually not only seagates.. similar happened on a 200GB Western Digital drive to me, FreeBSD-5.3. regards, M. From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 29 17:31:45 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 16E1216A4CE for ; Fri, 29 Oct 2004 17:31:45 +0000 (GMT) Received: from mail-svr1.cs.utah.edu (brahma.cs.utah.edu [155.98.64.200]) by mx1.FreeBSD.org (Postfix) with ESMTP id DA97D43D1D for ; Fri, 29 Oct 2004 17:31:44 +0000 (GMT) (envelope-from saggarwa@cs.utah.edu) Received: from faith.cs.utah.edu (faith.cs.utah.edu [155.98.65.40]) by mail-svr1.cs.utah.edu (Postfix) with ESMTP id 83DAC346FC for ; Fri, 29 Oct 2004 11:31:44 -0600 (MDT) Received: by faith.cs.utah.edu (Postfix, from userid 4973) id E5BB82EC21; Fri, 29 Oct 2004 11:31:43 -0600 (MDT) Received: from localhost (localhost [127.0.0.1]) by faith.cs.utah.edu (Postfix) with ESMTP id 6BA9834406 for ; Fri, 29 Oct 2004 17:31:43 +0000 (UTC) Date: Fri, 29 Oct 2004 11:31:43 -0600 (MDT) From: Siddharth Aggarwal To: freebsd-hackers@freebsd.org In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: flushing disk buffer cache X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2004 17:31:45 -0000 Another related question ... Is it possible to delay or queue up disk writes until I exit from my function in the kernel (where I am trying to sync with the disk)? Or make sure that my sync function never goes to sleep waiting for the disk driver to signal completion of flushes to disk? On Fri, 29 Oct 2004, Siddharth Aggarwal wrote: > > > Hi, > > I am writing this pseudo disk driver for disk checkpointing, which > intercepts write requests to the disk (ad0s1) and performs a copy on write > of the old contents to another partition (ad0s4) before writing out the > new contents. So the driver (called shd) is mounted as > > /dev/shd0a on / > /dev/shd0f on /usr > > > So each time the user creates a new checkpoint (basically initialize new > data structures in memory for a new checkpoint), right before that inside > the driver, I explicitly do a sync() to flush out the disk buffer cache, > so that disk state is consistent when the checkpoint was taken. > > Then, I have hacked the reboot system call to revert to a previous > checkpoint after unmounting all the filesystems but before halting the > system. This revert basically involves copying some blocks from ad0s4 to > ad0s1. > > However, when the system reboots, fsck shows up inconsistencies in the > filesystem and so fsck needs to be run manually. > > So I suspect that the reason for this problem is that when a checkpoint is > taken, the filesystem on ad0s1 is active and more write operations are > coming in i.e. filesystem on ad0s1 is still dirty. Hence I explicitly > called sync() before returning from the checkpoint command but I think > sync() doesnt guarantee that everything was actually flushed out. So I > implemented a more mandatory way of syncing, i.e. just got part of the > code from boot() system call. The code is as below, and it is called > whenever a checkpoint command is fired. > > Does anyone think if this is the right way of flushing the cache? Is there > anything I can do to ensure the filesystem is consistent during reboot? > I don't think this is a problem in the driver code, because when I created > a new filesystem on ad0s3 and shadowed that using the driver, everything > ran perfectly fine, but the difference was that I could unmount the > filesystem before "restoring the checkpoint" and hence wasnt necessary to > do it during reboot time. > > > void sync_before_checkpoint (void) > { > register struct buf *bp; > int iter, nbusy, pbusy; > > waittime = 0; > sync(&proc0, NULL); > > /* > * With soft updates, some buffers that are > * written will be remarked as dirty until other > * buffers are written. > */ > > for (iter = pbusy = 0; iter < 20; iter++) { > nbusy = 0; > for (bp = &buf[nbuf]; --bp >= buf; ) { > if ((bp->b_flags & B_INVAL) == 0 && > BUF_REFCNT(bp) > 0) { > nbusy++; > } else if ((bp->b_flags & (B_DELWRI | B_INVAL)) > == B_DELWRI) { > /* bawrite(bp);*/ > nbusy++; > } > } > if (nbusy == 0) > break; > printf("%d ", nbusy); > if (nbusy < pbusy) > iter = 0; > pbusy = nbusy; > if (iter > 5 && bioops.io_sync) > (*bioops.io_sync)(NULL); > sync(&proc0, NULL); > DELAY(50000 * iter); > } > /* > * Count only busy local buffers to prevent forcing > * a fsck if we're just a client of a wedged NFS server > */ > nbusy = 0; > for (bp = &buf[nbuf]; --bp >= buf; ) { > if (((bp->b_flags&B_INVAL) == 0 && BUF_REFCNT(bp)) || > ((bp->b_flags & (B_DELWRI|B_INVAL)) == B_DELWRI)) { > if (bp->b_dev == NODEV) { > TAILQ_REMOVE(&mountlist, > bp->b_vp->v_mount, mnt_list); > continue; > } > nbusy++; > } > } > if (nbusy) { > /* > * Failed to sync all blocks. Indicate this and don't > * unmount filesystems (thus forcing an fsck on reboot). > */ > printf("giving up on %d buffers\n", nbusy); > DELAY(5000000); /* 5 seconds */ > } > } > > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 29 19:04:34 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 036E316A4CE for ; Fri, 29 Oct 2004 19:04:34 +0000 (GMT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 85F0443D39 for ; Fri, 29 Oct 2004 19:04:33 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.1/8.13.1) with ESMTP id i9TJ1u0A026971; Fri, 29 Oct 2004 12:04:30 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200410291904.i9TJ1u0A026971@gw.catspoiler.org> Date: Fri, 29 Oct 2004 12:01:56 -0700 (PDT) From: Don Lewis To: saggarwa@cs.utah.edu In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: freebsd-hackers@FreeBSD.org Subject: Re: flushing disk buffer cache X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2004 19:04:34 -0000 On 29 Oct, Siddharth Aggarwal wrote: > > Another related question ... > > Is it possible to delay or queue up disk writes until I exit from my > function in the kernel (where I am trying to sync with the disk)? Or > make sure that my sync function never goes to sleep waiting for the disk > driver to signal completion of flushes to disk? Take a look at how the snapshot code handles this. It has to be done above the level of individual disk operations because certain file system operations require multiple disk I/O operations to transform the file system from one consistent state to another consistent state. If you try to checkpoint in the middle of this sequence, you will capture a state where the file system is internally inconsistent. From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 29 19:30:55 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E884816A4CE; Fri, 29 Oct 2004 19:30:55 +0000 (GMT) Received: from mail-svr1.cs.utah.edu (brahma.cs.utah.edu [155.98.64.200]) by mx1.FreeBSD.org (Postfix) with ESMTP id B61D543D39; Fri, 29 Oct 2004 19:30:55 +0000 (GMT) (envelope-from saggarwa@cs.utah.edu) Received: from faith.cs.utah.edu (faith.cs.utah.edu [155.98.65.40]) by mail-svr1.cs.utah.edu (Postfix) with ESMTP id E389E34846; Fri, 29 Oct 2004 13:30:40 -0600 (MDT) Received: by faith.cs.utah.edu (Postfix, from userid 4973) id B46D72EC21; Fri, 29 Oct 2004 13:30:38 -0600 (MDT) Received: from localhost (localhost [127.0.0.1]) by faith.cs.utah.edu (Postfix) with ESMTP id EB63734406; Fri, 29 Oct 2004 19:30:38 +0000 (UTC) Date: Fri, 29 Oct 2004 13:30:38 -0600 (MDT) From: Siddharth Aggarwal To: Don Lewis In-Reply-To: <200410291904.i9TJ1u0A026971@gw.catspoiler.org> Message-ID: References: <200410291904.i9TJ1u0A026971@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-hackers@FreeBSD.org Subject: Re: flushing disk buffer cache X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2004 19:30:56 -0000 Thanks for your reply. Hmm. At the moment, the user can send an ioctl to define a checkpoint. But I would guess that this could happen between 2 strategy() function calls corresponding to the same filesystem operation? So if there a way to block filesystem operations while a snapshot is taken? I can't unmount an active filesystem before the snapshot and remount it after. Any suggestions? On Fri, 29 Oct 2004, Don Lewis wrote: > On 29 Oct, Siddharth Aggarwal wrote: > > > > Another related question ... > > > > Is it possible to delay or queue up disk writes until I exit from my > > function in the kernel (where I am trying to sync with the disk)? Or > > make sure that my sync function never goes to sleep waiting for the disk > > driver to signal completion of flushes to disk? > > Take a look at how the snapshot code handles this. It has to be done > above the level of individual disk operations because certain file > system operations require multiple disk I/O operations to transform the > file system from one consistent state to another consistent state. If > you try to checkpoint in the middle of this sequence, you will capture a > state where the file system is internally inconsistent. > > > From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 29 19:56:23 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B55D416A4CE for ; Fri, 29 Oct 2004 19:56:23 +0000 (GMT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7956E43D1D for ; Fri, 29 Oct 2004 19:56:23 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.1/8.13.1) with ESMTP id i9TJu8fL027071; Fri, 29 Oct 2004 12:56:16 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200410291956.i9TJu8fL027071@gw.catspoiler.org> Date: Fri, 29 Oct 2004 12:56:08 -0700 (PDT) From: Don Lewis To: saggarwa@cs.utah.edu In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: freebsd-hackers@FreeBSD.org Subject: Re: flushing disk buffer cache X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2004 19:56:23 -0000 On 29 Oct, Siddharth Aggarwal wrote: > > Thanks for your reply. > > Hmm. At the moment, the user can send an ioctl to define a checkpoint. But > I would guess that this could happen between 2 strategy() function calls > corresponding to the same filesystem operation? Yes. > So if there a way to block > filesystem operations while a snapshot is taken? I can't unmount an active > filesystem before the snapshot and remount it after. Any suggestions? Yes, this is done by the following code in ffs_snapshot(): /* * Suspend operation on filesystem. */ for (;;) { vn_finished_write(wrtmp); if ((error = vfs_write_suspend(vp->v_mount)) != 0) { vn_start_write(NULL, &wrtmp, V_WAIT); vn_lock(vp, LK_EXCLUSIVE | LK_RETRY, td); goto out; } if (mp->mnt_kern_flag & MNTK_SUSPENDED) break; vn_start_write(NULL, &wrtmp, V_WAIT); } I think the snapshot code works at a higher level than what you are implementing, so I believe that the snapshot code doesn't need to sync all the files to create a consistent snapshot. You may run into problems with syncing unwritten data while writing is suspended, but I'm not sure because don't understand the code all that well. From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 29 20:47:49 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 712B716A4CE for ; Fri, 29 Oct 2004 20:47:49 +0000 (GMT) Received: from hq.sectorb.msk.ru (petaflop.b.gz.ru [217.67.124.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id E2BEF43D62 for ; Fri, 29 Oct 2004 20:47:47 +0000 (GMT) (envelope-from chinhngt@sectorb.msk.ru) Received: from unix.local (unix.local [172.16.12.120]) by hq.sectorb.msk.ru (Postfix) with ESMTP id 24A8819D2; Sat, 30 Oct 2004 00:47:45 +0400 (MSD) Date: Sat, 30 Oct 2004 00:48:08 +0400 (MSD) From: Nguyen Tam Chinh X-X-Sender: chinhngt@unix.local To: "Mikhail P." In-Reply-To: <200410291657.33606.miha@ghuug.org> Message-ID: <20041030004556.B13046@unix.local> References: <200410081937.15068.miha@ghuug.org> <200410291044.34973.soralx@cydem.org> <200410291657.33606.miha@ghuug.org> X-System: FreeBSD 4.9 REL i386 X-Website: http://chinhngt.svmgu.com X-Home-Addr: Vietnam:Hue_city:45_Le_Huan_St. X-Current-Addr: Russian_Federation:Moscow:119234:Main_Building-MSU:Sector_B:Room_539 Keywords: 216091683 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-hackers@freebsd.org Subject: Re: ad0: FAILURE - WRITE_DMA X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2004 20:47:49 -0000 On Fri, 29 Oct 2004, Mikhail P. wrote: > On Friday 29 October 2004 16:50, Mikhail P. wrote: > > Perhaps it is only Seagate <-> FreeBSD5-related. Same drives, but with > > FreeBSD4 do work well together without a glitch. > > Actually not only seagates.. similar happened on a 200GB Western Digital drive > to me, FreeBSD-5.3. > In FreeBSD 5.3b7 I have the same problem with the Maxtor 120GB IDE ad2: 117246MB [238216/16/63] at ata1-master UDMA66 ad2: TIMEOUT - WRITE_DMA retrying (2 retries left) LBA=14301663 ad2: TIMEOUT - WRITE_DMA retrying (2 retries left) LBA=14301663 ad2: TIMEOUT - WRITE_DMA retrying (2 retries left) LBA=14301663 ad2: TIMEOUT - WRITE_DMA retrying (2 retries left) LBA=14301663 ad2: TIMEOUT - WRITE_DMA retrying (2 retries left) LBA=14301663 ad2: TIMEOUT - WRITE_DMA retrying (2 retries left) LBA=14301663 ad2: TIMEOUT - READ_DMA retrying (2 retries left) LBA=160532482 ad2: TIMEOUT - READ_DMA retrying (2 retries left) LBA=209834594 ad2: TIMEOUT - READ_DMA retrying (2 retries left) LBA=218490706 ad2: TIMEOUT - READ_DMA retrying (2 retries left) LBA=211340046 ad2: TIMEOUT - READ_DMA retrying (2 retries left) LBA=209834594 ad2: TIMEOUT - READ_DMA retrying (2 retries left) LBA=163587418 ad2: TIMEOUT - READ_DMA retrying (2 retries left) LBA=209834786 ad2: TIMEOUT - READ_DMA retrying (2 retries left) LBA=17312287 ----- With best regards, | The Power to Serve Nguyen Tam Chinh | http://www.FreeBSD.org Loc: sp.cs.msu.ru | http://chinhngt.svmgu.com | http://www.gnu.org/copyleft/copyleft.html Tel: +7 905 7814187 | From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 29 22:30:39 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8DAF916A4CE for ; Fri, 29 Oct 2004 22:30:39 +0000 (GMT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id 38E2943D45 for ; Fri, 29 Oct 2004 22:30:39 +0000 (GMT) (envelope-from aaron.glenn@gmail.com) Received: by wproxy.gmail.com with SMTP id 65so740066wri for ; Fri, 29 Oct 2004 15:30:32 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=NMhGZtdtKcVKsfELdjWJtMEdYaEm/Vm2DW950wSEFB8VrRwZARvFh76VUQ3p9yV8AyQaLYtYLSh+smxAl15+QXWiUTsEWYzsabdToQlEobvBSGw4g/krr0KERn6iQrP059K3Jzn1oWJP72uU6/Jpnwaczkv7bKY01XVEM8kvCNo= Received: by 10.38.76.80 with SMTP id y80mr1994828rna; Fri, 29 Oct 2004 15:30:32 -0700 (PDT) Received: by 10.38.151.56 with HTTP; Fri, 29 Oct 2004 15:30:32 -0700 (PDT) Message-ID: <18f6019404102915302f2d4771@mail.gmail.com> Date: Fri, 29 Oct 2004 15:30:32 -0700 From: Aaron Glenn To: miha@ghuug.org In-Reply-To: <200410291657.33606.miha@ghuug.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <200410081937.15068.miha@ghuug.org> <200410291044.34973.soralx@cydem.org> <200410291650.27058.miha@ghuug.org> <200410291657.33606.miha@ghuug.org> cc: freebsd-hackers@freebsd.org Subject: Re: ad0: FAILURE - WRITE_DMA X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Aaron Glenn List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2004 22:30:39 -0000 Add Western Digital Raptors to the list as well. However I have not had a problem since 5.3-BETA3. aaron.glenn On Fri, 29 Oct 2004 16:57:33 +0000, Mikhail P. wrote: > On Friday 29 October 2004 16:50, Mikhail P. wrote: > > Perhaps it is only Seagate <-> FreeBSD5-related. Same drives, but with > > FreeBSD4 do work well together without a glitch. > > Actually not only seagates.. similar happened on a 200GB Western Digital drive > to me, FreeBSD-5.3. > > > > regards, > M. > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 30 01:39:36 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 357F216A4CE for ; Sat, 30 Oct 2004 01:39:36 +0000 (GMT) Received: from mail825.megamailservers.com (mail825.carrierinternetsolutions.com [69.49.106.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id C2E1F43D41 for ; Sat, 30 Oct 2004 01:39:35 +0000 (GMT) (envelope-from strick@covad.net) X-POP-User: sftravel.covad.net Received: from mist.nodomain (h-67-101-99-151.snfccasy.dynamic.covad.net [67.101.99.151])i9U1dGg5032247; Fri, 29 Oct 2004 21:39:17 -0400 Received: from mist.nodomain (localhost [127.0.0.1]) by mist.nodomain (8.12.11/8.12.11) with ESMTP id i9U1dEup000640; Fri, 29 Oct 2004 18:39:14 -0700 (PDT) (envelope-from dan@mist.nodomain) Received: (from dan@localhost) by mist.nodomain (8.12.11/8.12.11/Submit) id i9U1dDnY000639; Fri, 29 Oct 2004 18:39:13 -0700 (PDT) (envelope-from dan) Date: Fri, 29 Oct 2004 18:39:13 -0700 (PDT) From: Dan Strick Message-Id: <200410300139.i9U1dDnY000639@mist.nodomain> To: freebsd-hackers@freebsd.org cc: dan@mist.nodomain cc: sean-freebsd@farley.org Subject: Re: questionable feature in FreeBSD pmake X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Oct 2004 01:39:36 -0000 > > Why are you unable to do anything with the command-line? Any of these > will solve your problem. > Bourne: > MAKEOBJDIR=/no_obj_here make > > Bourne or CSH: > env MAKEOBJDIR=/no_obj_here make > > Here is a Makefile that does not use obj/. The special targets can be > placed into a file to be included into all your Makefiles. It only > suffers from a failed build where it will not rename obj to tmpobj. > > ----------------------- > .BEGIN: > mv tmpobj obj || mkdir obj > > .INTERRUPT: > mv obj tmpobj > My goal was to write a generic makefile that would work on almost any mostly POSIX compliant OS. I wanted something I could just walk up to and say "make" without having to remember that the makefile is special and has to be invoked in a special way. If I could just add some trivial magic to the makefile that suppresses the special "obj" feature on systems that have it but has no effect on other systems, I would do that. It seems that there is no such magic. Thank you all for your suggestions. I wish to give a special award for extra creativity to Sean Farley for his makefile enhancements that work around the problem by temporarily renaming the "obj" subdirectory while the makefile is not active (i.e. when you would most care what the subdirectory was called). I think I will work around the problem by calling the directory "objs" instead of "obj". This does not mean that I forgive whoever it was that invented the feature I don't like. He should have checked with an adult first. (Ooh, it feels good to say that! :-) I repeat the observation that this feature could have been implemented in a way that would have made it unlikely to be invoked accidentally. It seems that the feature is now so widely spread throughout the BSD community that is way too late to get the blemish fixed now. I will have to settle for finding some comfort in the realization that I have far bigger problems than the inability to use the directory name "obj" in some circumstances. Dan Strick strick@covad.net From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 30 02:45:58 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D3F3A16A4CE for ; Sat, 30 Oct 2004 02:45:58 +0000 (GMT) Received: from web51805.mail.yahoo.com (web51805.mail.yahoo.com [206.190.38.236]) by mx1.FreeBSD.org (Postfix) with SMTP id 2CEEE43D39 for ; Sat, 30 Oct 2004 02:45:58 +0000 (GMT) (envelope-from patrick_dkt@yahoo.com.hk) Message-ID: <20041030024557.53081.qmail@web51805.mail.yahoo.com> Received: from [210.0.177.65] by web51805.mail.yahoo.com via HTTP; Sat, 30 Oct 2004 10:45:57 CST Date: Sat, 30 Oct 2004 10:45:57 +0800 (CST) From: Patrick Dung To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=big5 Content-Transfer-Encoding: 8bit Subject: Feature request (pam/nss ldap, nsswitch ldap integration) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Oct 2004 02:45:58 -0000 Hi First of all, I know that most committers or contributors contribute their work in their free time. I am not asking for any promise but I just want to discuss a possible improvement for FreeBSD. So my suggestion is: integrate pam_ldap, nss_ldap, nsswitch support with ldap and lookupd (ie LDAP client support) into the OS. Perhaps by default, the ldap support is off. It can be enabled by a switch in /etc/make.conf (like KERBEROS) FreeBSD has the above support in the ports. But I think it would be great if FreeBSD support LDAP out of the box. Just like Solaris and most Linux distro. The integration with LDAP is like the integration of OpenPAM, OpenSSH, AMD automounter and BIND in FreeBSD. Please express your view. Ignore me if my suggestion has no practical use or only beneficial to a small amount of people. Regards Patrick _________________________________________________________ ¥²±þ§Þ¡B¶¼ºq¡B¤p¬P¬P... ®öº©¹aÁn ±¡¤ß³sô http://us.rd.yahoo.com/evt=22281/*http://ringtone.yahoo.com.hk/ From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 30 09:42:43 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 15CD016A4CE for ; Sat, 30 Oct 2004 09:42:43 +0000 (GMT) Received: from smtp.des.no (flood.des.no [217.116.83.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id CF12B43D1D for ; Sat, 30 Oct 2004 09:42:42 +0000 (GMT) (envelope-from des@des.no) Received: by smtp.des.no (Pony Express, from userid 666) id E73755312; Sat, 30 Oct 2004 11:42:41 +0200 (CEST) Received: from dwp.des.no (des.no [80.203.228.37]) by smtp.des.no (Pony Express) with ESMTP id 09DF3530A; Sat, 30 Oct 2004 11:42:34 +0200 (CEST) Received: by dwp.des.no (Postfix, from userid 2602) id C6D5BB85E; Sat, 30 Oct 2004 11:42:34 +0200 (CEST) To: Patrick Dung References: <20041030024557.53081.qmail@web51805.mail.yahoo.com> From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) Date: Sat, 30 Oct 2004 11:42:34 +0200 In-Reply-To: <20041030024557.53081.qmail@web51805.mail.yahoo.com> (Patrick Dung's message of "Sat, 30 Oct 2004 10:45:57 +0800 (CST)") Message-ID: User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on flood.des.no X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.64 cc: freebsd-hackers@freebsd.org Subject: Re: Feature request (pam/nss ldap, nsswitch ldap integration) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Oct 2004 09:42:43 -0000 Patrick Dung writes: > So my suggestion is: integrate pam_ldap, nss_ldap, nsswitch support > with ldap and lookupd (ie LDAP client support) into the OS. I'm already thinking about that, and about Kerberos autoconfiguration (aka KDC discovery, very useful for FreeBSD clients in Windows networks). I guess you were at the keynote too, huh? :) DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 30 09:49:28 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 347B316A4CE for ; Sat, 30 Oct 2004 09:49:28 +0000 (GMT) Received: from mallaury.noc.nerim.net (smtp-106-saturday.noc.nerim.net [62.4.17.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 54A3543D2F for ; Sat, 30 Oct 2004 09:49:27 +0000 (GMT) (envelope-from e-masson@kisoft-services.com) Received: from srvbsdnanssv.interne.kisoft-services.com (kisoftacces2.net1.nerim.net [62.212.107.52]) by mallaury.noc.nerim.net (Postfix) with ESMTP id 4812062F33; Sat, 30 Oct 2004 11:49:25 +0200 (CEST) Received: from localhost (localhost [127.0.0.1])5C462D1E9; Sat, 30 Oct 2004 11:49:25 +0200 (CEST) Received: from srvbsdnanssv.interne.kisoft-services.com ([127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 49346-03; Sat, 30 Oct 2004 11:49:15 +0200 (CEST) Received: by srvbsdnanssv.interne.kisoft-services.com (Postfix, from userid 1001) id E7154D1E8; Sat, 30 Oct 2004 11:49:14 +0200 (CEST) To: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) From: Eric Masson In-Reply-To: (Dag-Erling =?iso-8859-1?q?Sm=F8rgrav's?= message of "Sat, 30 Oct 2004 11:42:34 +0200") References: <20041030024557.53081.qmail@web51805.mail.yahoo.com> X-Operating-System: FreeBSD 5.3-STABLE i386 Date: Sat, 30 Oct 2004 11:49:14 +0200 Message-ID: <86acu4wn6t.fsf@srvbsdnanssv.interne.kisoft-services.com> User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at interne.kisoft-services.com cc: Patrick Dung cc: freebsd-hackers@freebsd.org Subject: Re: Feature request (pam/nss ldap, nsswitch ldap integration) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Oct 2004 09:49:28 -0000 >>>>> "DES" == Dag-Erling Smørgrav writes: DES> I'm already thinking about that, and about Kerberos DES> autoconfiguration (aka KDC discovery, very useful for FreeBSD DES> clients in Windows networks). Doesn't Heimdal partly solve this issue (lookup of SRV records in the dns zone corresponding to the realm) ? Eric Masson -- VR> y'en a vraiment qui manquent pas d'air. Alors là, je m'insurge ! Il ne manque certainement pas d'air, comme toutes les baudruches. -+- RG in -+- Il est pas beau druche ? -+- From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 30 09:56:57 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6108016A4CE for ; Sat, 30 Oct 2004 09:56:57 +0000 (GMT) Received: from smtp.des.no (flood.des.no [217.116.83.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2357A43D3F for ; Sat, 30 Oct 2004 09:56:57 +0000 (GMT) (envelope-from des@des.no) Received: by smtp.des.no (Pony Express, from userid 666) id 17A815313; Sat, 30 Oct 2004 11:56:55 +0200 (CEST) Received: from dwp.des.no (des.no [80.203.228.37]) by smtp.des.no (Pony Express) with ESMTP id 3E2C0530A; Sat, 30 Oct 2004 11:56:49 +0200 (CEST) Received: by dwp.des.no (Postfix, from userid 2602) id 07E5DB85E; Sat, 30 Oct 2004 11:56:49 +0200 (CEST) To: Eric Masson References: <20041030024557.53081.qmail@web51805.mail.yahoo.com> <86acu4wn6t.fsf@srvbsdnanssv.interne.kisoft-services.com> From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) Date: Sat, 30 Oct 2004 11:56:48 +0200 In-Reply-To: <86acu4wn6t.fsf@srvbsdnanssv.interne.kisoft-services.com> (Eric Masson's message of "Sat, 30 Oct 2004 11:49:14 +0200") Message-ID: User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on flood.des.no X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.64 cc: Patrick Dung cc: freebsd-hackers@freebsd.org Subject: Re: Feature request (pam/nss ldap, nsswitch ldap integration) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Oct 2004 09:56:57 -0000 Eric Masson writes: > Doesn't Heimdal partly solve this issue (lookup of SRV records in the > dns zone corresponding to the realm) ? Sure, provided you know which realm you're in... Ideally, I'd like to be able to install FreeBSD on a desktop box in a Windows shop and have it Just Work[tm] with Active Directory and Kerberos authentication. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 30 10:24:39 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8951916A4CE for ; Sat, 30 Oct 2004 10:24:39 +0000 (GMT) Received: from web51804.mail.yahoo.com (web51804.mail.yahoo.com [206.190.38.235]) by mx1.FreeBSD.org (Postfix) with SMTP id 1773443D2F for ; Sat, 30 Oct 2004 10:24:39 +0000 (GMT) (envelope-from patrick_dkt@yahoo.com.hk) Message-ID: <20041030102438.79892.qmail@web51804.mail.yahoo.com> Received: from [158.132.12.72] by web51804.mail.yahoo.com via HTTP; Sat, 30 Oct 2004 18:24:38 CST Date: Sat, 30 Oct 2004 18:24:38 +0800 (CST) From: Patrick Dung To: Dag-Erling "Smørgrav" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=big5 Content-Transfer-Encoding: 8bit cc: freebsd-hackers@freebsd.org Subject: Re: Feature request (pam/nss ldap, nsswitch ldap integration) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Oct 2004 10:24:39 -0000 --- Dag-Erling Smørgrav wrotes¡G > Patrick Dung writes: > > So my suggestion is: integrate pam_ldap, nss_ldap, nsswitch support > > with ldap and lookupd (ie LDAP client support) into the OS. > > I'm already thinking about that, and about Kerberos autoconfiguration > (aka KDC discovery, very useful for FreeBSD clients in Windows > networks). I guess you were at the keynote too, huh? :) > You mean the eurobsdcon 2004 keynote? No, I am not in there. I have this idea just one or two days ago. I have posted a similair article in -current and -questions but did not get any comments. Regards Patrick _________________________________________________________ ¥²±þ§Þ¡B¶¼ºq¡B¤p¬P¬P... ®öº©¹aÁn ±¡¤ß³sô http://us.rd.yahoo.com/evt=22281/*http://ringtone.yahoo.com.hk/ From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 30 11:13:15 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BCFCC16A4CE for ; Sat, 30 Oct 2004 11:13:15 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6D9E343D31 for ; Sat, 30 Oct 2004 11:13:15 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.13.1/8.13.1) with ESMTP id i9UBCZi4032123; Sat, 30 Oct 2004 07:12:35 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i9UBCZtP032120; Sat, 30 Oct 2004 12:12:35 +0100 (BST) (envelope-from robert@fledge.watson.org) Date: Sat, 30 Oct 2004 12:12:34 +0100 (BST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Patrick Dung In-Reply-To: <20041030024557.53081.qmail@web51805.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-hackers@freebsd.org Subject: Re: Feature request (pam/nss ldap, nsswitch ldap integration) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Oct 2004 11:13:15 -0000 On Sat, 30 Oct 2004, Patrick Dung wrote: > First of all, I know that most committers or contributors contribute > their work in their free time. I am not asking for any promise but I > just want to discuss a possible improvement for FreeBSD. > > So my suggestion is: integrate pam_ldap, nss_ldap, nsswitch support with > ldap and lookupd (ie LDAP client support) into the OS. Perhaps by > default, the ldap support is off. It can be enabled by a switch in > /etc/make.conf (like KERBEROS) > > FreeBSD has the above support in the ports. But I think it would be > great if FreeBSD support LDAP out of the box. Just like Solaris and > most Linux distro. The integration with LDAP is like the integration of > OpenPAM, OpenSSH, AMD automounter and BIND in FreeBSD. This is something I'd very much like to see happen -- while we don't have an Active Directory infrastructure at work, our goal in finding funding for the NSS work was specifically to facilitate this happening. While some will undoubtably complain, supporting immediate and tight integration with active directory would be quite useful. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 30 11:21:01 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9797E16A4CE for ; Sat, 30 Oct 2004 11:21:01 +0000 (GMT) Received: from 9.hellooperator.net (cpc3-cdif2-3-0-cust202.cdif.cable.ntl.com [81.103.32.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id 50CDB43D31 for ; Sat, 30 Oct 2004 11:21:01 +0000 (GMT) (envelope-from rasputnik@hellooperator.net) Received: from [10.4.0.1] (helo=bingo.tenfour) by 9.hellooperator.net with esmtp (Exim 4.43) id 1CNrGv-00066g-Q3 for freebsd-hackers@freebsd.org; Sat, 30 Oct 2004 12:19:51 +0100 Received: from rasputnik by bingo.tenfour with local (Exim 4.43 (FreeBSD)) id 1CNrI2-0003Nr-8U for freebsd-hackers@freebsd.org; Sat, 30 Oct 2004 12:20:58 +0100 Date: Sat, 30 Oct 2004 12:20:58 +0100 From: Dick Davies To: FreeBSD Hackers Message-ID: <20041030112057.GD7262@bingo.tenfour> References: <20041030024557.53081.qmail@web51805.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041030024557.53081.qmail@web51805.mail.yahoo.com> User-Agent: Mutt/1.4.2.1i X-Spam-Score: -1.2 (-) Subject: Re: Feature request (pam/nss ldap, nsswitch ldap integration) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Oct 2004 11:21:01 -0000 * Patrick Dung [1045 03:45]: > So my suggestion is: integrate pam_ldap, nss_ldap, nsswitch support > with ldap and lookupd (ie LDAP client support) into the OS. Trouble is openldap is one of those things everyone wants to configure themselves - do you enable SASL support or not, what backends do you use etc? Granted most of this is on the server, but there's also the extra work involved in updating it all the time - openldap in particular seems to be a fairly fast moving target. I'm not sure importing all that code would win you much over a pkg_add anyway. And it raises other questions, for example how do you handle mergemaster when half your accounts are in LDAP and not the system databases? Though I would really like to see nss_ldap extended to gather more information over LDAP - incidentally, does anyone know why that isn't enabled? Is there a technical reason or is it just caution? > The integration with LDAP is like the integration of OpenPAM, > OpenSSH, AMD automounter and BIND in FreeBSD. Trouble is it might be like the integration of Perl :) -- The pie is ready. You guys like swarms of things, right? - Bender Rasputin :: Jack of All Trades - Master of Nuns From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 30 11:35:27 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9F1BC16A4CE for ; Sat, 30 Oct 2004 11:35:27 +0000 (GMT) Received: from kraid.nerim.net (smtp-106-saturday.nerim.net [62.4.16.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id E655543D1D for ; Sat, 30 Oct 2004 11:35:26 +0000 (GMT) (envelope-from e-masson@kisoft-services.com) Received: from srvbsdnanssv.interne.kisoft-services.com (kisoftacces2.net1.nerim.net [62.212.107.52]) by kraid.nerim.net (Postfix) with ESMTP id 98DA74171A; Sat, 30 Oct 2004 13:35:24 +0200 (CEST) Received: from localhost (localhost [127.0.0.1])8EA40D1E9; Sat, 30 Oct 2004 13:35:24 +0200 (CEST) Received: from srvbsdnanssv.interne.kisoft-services.com ([127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 49725-08; Sat, 30 Oct 2004 13:35:13 +0200 (CEST) Received: by srvbsdnanssv.interne.kisoft-services.com (Postfix, from userid 1001) id EB12DD1B6; Sat, 30 Oct 2004 13:35:12 +0200 (CEST) To: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) From: Eric Masson In-Reply-To: (Dag-Erling =?iso-8859-1?q?Sm=F8rgrav's?= message of "Sat, 30 Oct 2004 11:56:48 +0200") References: <20041030024557.53081.qmail@web51805.mail.yahoo.com> <86acu4wn6t.fsf@srvbsdnanssv.interne.kisoft-services.com> X-Operating-System: FreeBSD 5.3-STABLE i386 Date: Sat, 30 Oct 2004 13:35:12 +0200 Message-ID: <861xfgwia7.fsf@srvbsdnanssv.interne.kisoft-services.com> User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at interne.kisoft-services.com cc: Patrick Dung cc: freebsd-hackers@freebsd.org Subject: Re: Feature request (pam/nss ldap, nsswitch ldap integration) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Oct 2004 11:35:27 -0000 >>>>> "DES" == Dag-Erling Smørgrav writes: DES> Sure, provided you know which realm you're in... Dhcp, maybe ? DES> Ideally, I'd like to be able to install FreeBSD on a desktop box DES> in a Windows shop and have it Just Work[tm] with Active Directory DES> and Kerberos authentication. Nice goal, It would be really handy. Eric Masson -- «Ca te derange ??? Je fait ce que je veut si ca te plait pas tu vas ailleurs gros c,, Mis a part ca si quelqun voulait bien me repondre ce serais sympa.» TOTO in Guide du linuxien pervers : "Bien préparer sa repartie" From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 30 11:39:39 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F21F916A4CE for ; Sat, 30 Oct 2004 11:39:39 +0000 (GMT) Received: from britannica.bec.de (eurobsdcon.punkt.de [217.29.47.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id A6F4F43D41 for ; Sat, 30 Oct 2004 11:39:39 +0000 (GMT) (envelope-from joerg@britannica.bec.de) Received: by britannica.bec.de (Postfix, from userid 1001) id 8F29F532F; Sat, 30 Oct 2004 13:37:46 +0200 (CEST) Date: Sat, 30 Oct 2004 13:37:46 +0200 From: Joerg Sonnenberger To: freebsd-hackers@freebsd.org Message-ID: <20041030113746.GA960@britannica.bec.de> Mail-Followup-To: freebsd-hackers@freebsd.org References: <20041030024557.53081.qmail@web51805.mail.yahoo.com> <86acu4wn6t.fsf@srvbsdnanssv.interne.kisoft-services.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Subject: Re: Feature request (pam/nss ldap, nsswitch ldap integration) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Oct 2004 11:39:40 -0000 On Sat, Oct 30, 2004 at 11:56:48AM +0200, Dag-Erling Sm?rgrav wrote: > Eric Masson writes: > > Doesn't Heimdal partly solve this issue (lookup of SRV records in the > > dns zone corresponding to the realm) ? > > Sure, provided you know which realm you're in... It tries the hostname first and starts digging up from that, e.g. for britannica.bec.de it tries britannica.bec.de, bec.de and de. Joerg From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 30 11:44:33 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E70C116A4CE for ; Sat, 30 Oct 2004 11:44:33 +0000 (GMT) Received: from britannica.bec.de (eurobsdcon.punkt.de [217.29.47.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9AF4F43D1D for ; Sat, 30 Oct 2004 11:44:33 +0000 (GMT) (envelope-from joerg@britannica.bec.de) Received: by britannica.bec.de (Postfix, from userid 1001) id E00EE532F; Sat, 30 Oct 2004 13:43:01 +0200 (CEST) Date: Sat, 30 Oct 2004 13:43:01 +0200 From: Joerg Sonnenberger To: FreeBSD Hackers Message-ID: <20041030114301.GB960@britannica.bec.de> Mail-Followup-To: FreeBSD Hackers References: <20041030024557.53081.qmail@web51805.mail.yahoo.com> <20041030112057.GD7262@bingo.tenfour> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041030112057.GD7262@bingo.tenfour> User-Agent: Mutt/1.4.2.1i Subject: Re: Feature request (pam/nss ldap, nsswitch ldap integration) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Oct 2004 11:44:34 -0000 On Sat, Oct 30, 2004 at 12:20:58PM +0100, Dick Davies wrote: > Trouble is openldap is one of those things everyone wants to configure > themselves - do you enable SASL support or not, what backends do you use > etc? IIRC SASL is pretty mandatory to correctly implement LDAP v3. Bigger question is GSSAPI (Kerberos 5!) and the backend. [..] > And it raises other questions, for example how do you handle mergemaster > when half your accounts are in LDAP and not the system databases? You should _not_ put system accounts into LDAP, that's that just wrong. So having them in the local database (whatever type that is) should work fine with mergemaster. Joerg From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 30 02:06:05 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 53B5016A4CE for ; Sat, 30 Oct 2004 02:06:05 +0000 (GMT) Received: from simmts12-srv.bellnexxia.net (simmts12.bellnexxia.net [206.47.199.141]) by mx1.FreeBSD.org (Postfix) with ESMTP id B12D843D1D for ; Sat, 30 Oct 2004 02:06:04 +0000 (GMT) (envelope-from allan@skene.net) Received: from kipper ([142.177.39.115]) by simmts12-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with SMTP id <20041030020603.FQKP1580.simmts12-srv.bellnexxia.net@kipper>; Fri, 29 Oct 2004 22:06:03 -0400 Message-ID: <035c01c4be25$0e05e030$6600a8c0@kipper> From: "Allan Marshall" To: "Joseph Koshy" References: <028f01c4bd4e$88167b50$6600a8c0@kipper> <84dead72041029071432cb3195@mail.gmail.com> <02b201c4bdeb$9b666600$6600a8c0@kipper> <84dead7204102918472654f3ec@mail.gmail.com> Date: Fri, 29 Oct 2004 23:06:22 -0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailman-Approved-At: Sat, 30 Oct 2004 12:27:17 +0000 cc: hackers@freebsd.org Subject: Re: 4.8-STABLE kernel crash X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Oct 2004 02:06:05 -0000 Ive been through the tuning man pages a few times, everything seems to be ok However i could be missing something Im am not tracking the 4.8-STABLE, this is just from some point here is the full backtrace, any more help is greatly appreciated bt full (kgdb) bt full #0 dumpsys () at ../../kern/kern_shutdown.c:487 error = 0 #1 0xc017c3af in boot (howto=256) at ../../kern/kern_shutdown.c:316 howto = 256 #2 0xc017c7d4 in poweroff_wait (junk=0xc02b182c, howto=-1070918865) at ../../kern/kern_shutdown.c:595 fmt = 0xc02b182c "%s" bootopt = 256 buf = "page fault", '\000' #3 0xc0261e1a in trap_fatal (frame=0xf79ace3c, eva=983060) at ../../i386/i386/trap.c:974 frame = (struct trapframe *) 0x100 code = -1070917588 type = 12 ss = -1070917588 esp = 0 softseg = {ssd_base = 0, ssd_limit = 1048575, ssd_type = 27, ssd_dpl = 0, ssd_p = 1, ssd_xx = 10, ssd_xx1 = 1, ssd_def32 = 1, ssd_gran = 1} #4 0xc0261aed in trap_pfault (frame=0xf79ace3c, usermode=0, eva=983060) at ../../i386/i386/trap.c:867 va = 983040 vm = (struct vmspace *) 0x0 ---Type to continue, or q to quit--- map = 0xf79bc640 rv = 0 ftype = 1 '\001' p = (struct proc *) 0xf7a96780 #5 0xc02616d7 in trap (frame={tf_fs = -1070923760, tf_es = -147914736, tf_ds = 16973840, tf_edi = 672440320, tf_esi = 227, tf_ebp = -140849532, tf_isp = -140849560, tf_ebx = -148367476, tf_edx = 983040, tf_ecx = 250428367, tf_eax = 524281, tf_trapno = 12, tf_err = 0, tf_eip = -1071494896, tf_cs = 8, tf_eflags = 66054, tf_esp = 0, tf_ss = -140786112}) at ../../i386/i386/trap.c:466 p = (struct proc *) 0xf7a96780 sticks = 17841799634098427673 i = 0 ucode = 0 type = 12 code = 0 eva = 983060 #6 0xc0224910 in vm_page_lookup (object=0xf728178c, pindex=227) at ../../vm/vm_page.c:515 object = 0x0 pindex = 227 m = 0x0 generation = 0 ---Type to continue, or q to quit--- #7 0xc021cc70 in vm_fault (map=0xf79bc640, vaddr=672440320, fault_type=1 '\001', fault_flags=0) at ../../vm/vm_fault.c:292 fault_type = 1 '\001' prot = 5 '\005' result = 0 wired = 0 map_generation = 89 next_object = 0x0 marray = {0x0, 0xf7a96780, 0xf7a96780, 0xf79bc640, 0x2814a000, 0x0, 0x7, 0x1, 0x0, 0x0, 0x1, 0xf79bc640, 0xf79bc640, 0xf7c28c60, 0xf79acf3c, 0xc0266426} hardfault = 0 faultcount = 0 fs = {m = 0x1000000, object = 0xf728178c, pindex = 227, first_m = 0x0, first_object = 0xf728178c, first_pindex = 227, map = 0xf79bc640, entry = 0xf7c28c60, lookup_still_valid = 1, vp = 0xf72ff800} #8 0xc0261a82 in trap_pfault (frame=0xf79acfa8, usermode=1, eva=672441792) at ../../i386/i386/trap.c:847 va = 672440320 vm = (struct vmspace *) 0x0 map = 0xf79bc640 rv = 0 ftype = 1 '\001' ---Type to continue, or q to quit--- p = (struct proc *) 0xf7a96780 #9 0xc02615ab in trap (frame={tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 672514096, tf_esi = 0, tf_ebp = -1077937344, tf_isp = -140849196, tf_ebx = 672505356, tf_edx = 0, tf_ecx = 134533128, tf_eax = 1008, tf_trapno = 12, tf_err = 4, tf_eip = 672010244, tf_cs = 31, tf_eflags = 66054, tf_esp = -1077937368, tf_ss = 47}) at ../../i386/i386/trap.c:377 p = (struct proc *) 0xf7a96780 sticks = 1 i = 0 ucode = 0 type = 12 code = 0 eva = 672441792 #10 0x280e1004 in ?? () No symbol table info available. #11 0x280e10bd in ?? () No symbol table info available. #12 0x280e70e5 in ?? () No symbol table info available. #13 0x28085174 in ?? () No symbol table info available. #14 0x8048f66 in ?? () ---Type to continue, or q to quit--- No symbol table info available. #15 0x8048e4a in ?? () No symbol table info available. ----- Original Message ----- From: "Joseph Koshy" To: "Allan Marshall" Sent: Friday, October 29, 2004 10:47 PM Subject: Re: 4.8-STABLE kernel crash >> The instablity has been for a few months, but prior to that, the box was >> up >> over 140 days without a single problem, no hardware changes >> since. I think i recompiled allowing ipfw after that, but nothing else >> major. > > In the absence of a full backtrace here are some guesses at possible > problems: > > 1) You seem to have 1G of RAM. Please check that you've set the memory > related loader tunables accordingly. You may want to set the value > of the kern.maxusers sysctl to below 256. See man tuning(7). > > 2) Are you tracking the 4.8 RELEASE branch, or is this kernel from > some point on 4-STABLE? > > Notes: If you are using loadable kernel modules, please ensure > that the kernel and modules are compiled from the same source > revisions. > > It may be helpful to get a full kernel backtrace from a dump. The > steps to do obtain this is present in the Handbook. > >> dmesg >> Copyright (c) 1992-2003 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 4.8-STABLE #1: Sun Sep 19 21:04:55 GMT 2004 >> *********************************** >> Timecounter "i8254" frequency 1193182 Hz >> CPU: Intel(R) Pentium(R) 4 CPU 2.40GHz (2411.61-MHz 686-class CPU) >> Origin = "GenuineIntel" Id = 0xf27 Stepping = 7 >> >> Features=0xbfebfbff >> real memory = 1072627712 (1047488K bytes) >> avail memory = 1040183296 (1015804K bytes) >> Preloaded elf kernel "kernel" at 0xc0362000. >> Pentium Pro MTRR support enabled >> md0: Malloc disk >> Using $PIR table, 7 entries at 0xc00fc8f0 >> npx0: on motherboard >> npx0: INT 16 interface >> pcib0: on motherboard >> pci0: on pcib0 >> agp0: mem >> 0xe8100000-0xe817ffff,0xe0000000-0xe7ffffff irq 10 at device 2.0 on pci0 >> agp0: detected 892k stolen memory >> agp0: aperture size is 128M >> pcib1: at device 30.0 on >> pci0 >> pci1: on pcib1 >> rl0: port 0xc000-0xc0ff mem >> 0xe8000000-0xe80000ff irq 11 at device 5.0 on pci1 >> rl0: Ethernet address: 00:20:ed:7e:8d:58 >> miibus0: on rl0 >> rlphy0: on miibus0 >> rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto >> isab0: at device 31.0 on >> pci0 >> isa0: on isab0 >> atapci0: port >> 0xf000-0xf00f,0-0x3,0-0x7,0-0x3,0-0x7 irq 0 at device 31.1 on pci0 >> ata0: at 0x1f0 irq 14 on atapci0 >> ata1: at 0x170 irq 15 on atapci0 >> pci0: (vendor=0x8086, dev=0x24c3) at 31.3 irq 3 >> fdc0: ready for input in output >> fdc0: cmd 3 failed at out byte 1 of 3 >> atkbdc0: at port 0x60,0x64 on isa0 >> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 >> 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 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 >> sio0: type 8250 >> sio1: configured irq 3 not in bitmap of probed irqs 0 >> DUMMYNET initialized (011031) >> IP packet filtering initialized, divert disabled, rule-based forwarding >> enabled, default to accept, logging limited to 10 packets/entry by >> default >> ad0: 76319MB [155061/16/63] at ata0-master UDMA100 >> Mounting root from ufs:/dev/ad0s1a >> WARNING: / was not properly dismounted >> >> >> >> ----- Original Message ----- >> From: "Joseph Koshy" >> To: "Allan Marshall" >> Cc: >> Sent: Friday, October 29, 2004 11:14 AM >> Subject: Re: 4.8-STABLE kernel crash >> >> > On Thu, 28 Oct 2004 21:30:45 -0300, Allan Marshall >> > wrote: >> >> The box has been quite unstable, with restarts every few days >> >> this is the first dump ive got with DDB >> >> I realize this likely isnt enough information, but if you could point >> >> me >> >> in the right direction >> >> I can provide anymore information required. >> > >> > 1) dmesg output please >> > 2) Is this a new problem? Did the box run FreeBSD stably earlier? >> >> From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 30 12:49:31 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 50CAD16A4CE for ; Sat, 30 Oct 2004 12:49:31 +0000 (GMT) Received: from 9.hellooperator.net (cpc3-cdif2-3-0-cust202.cdif.cable.ntl.com [81.103.32.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id C4A0E43D45 for ; Sat, 30 Oct 2004 12:49:30 +0000 (GMT) (envelope-from rasputnik@hellooperator.net) Received: from [10.4.0.1] (helo=bingo.tenfour) by 9.hellooperator.net with esmtp (Exim 4.43) id 1CNsea-0005QK-AD for freebsd-hackers@freebsd.org; Sat, 30 Oct 2004 13:48:20 +0100 Received: from rasputnik by bingo.tenfour with local (Exim 4.43 (FreeBSD)) id 1CNsfg-000610-Ub for freebsd-hackers@freebsd.org; Sat, 30 Oct 2004 13:49:28 +0100 Date: Sat, 30 Oct 2004 13:49:28 +0100 From: Dick Davies To: FreeBSD Hackers Message-ID: <20041030124928.GE7262@bingo.tenfour> References: <20041030024557.53081.qmail@web51805.mail.yahoo.com> <20041030112057.GD7262@bingo.tenfour> <20041030114301.GB960@britannica.bec.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041030114301.GB960@britannica.bec.de> User-Agent: Mutt/1.4.2.1i X-Spam-Score: -1.2 (-) Subject: Re: Feature request (pam/nss ldap, nsswitch ldap integration) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Oct 2004 12:49:31 -0000 * Joerg Sonnenberger [1043 12:43]: > On Sat, Oct 30, 2004 at 12:20:58PM +0100, Dick Davies wrote: > > Trouble is openldap is one of those things everyone wants to configure > > themselves - do you enable SASL support or not, what backends do you use > > etc? > > IIRC SASL is pretty mandatory to correctly implement LDAP v3. Bigger > question is GSSAPI (Kerberos 5!) and the backend. > > [..] > > And it raises other questions, for example how do you handle mergemaster > > when half your accounts are in LDAP and not the system databases? > > You should _not_ put system accounts into LDAP, that's that just wrong. > So having them in the local database (whatever type that is) should work > fine with mergemaster. I can see why you say that, but there are times when it's useful (rsyncing between different OSes for starters where you want to preserve permissions, for example - you don't have to ensure that all /etc/passwd, /etc/shadow, whatever happen to have the same uid listed in this case). -- The pie is ready. You guys like swarms of things, right? - Bender Rasputin :: Jack of All Trades - Master of Nuns From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 30 14:58:20 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A039916A4CE for ; Sat, 30 Oct 2004 14:58:20 +0000 (GMT) Received: from asmtp-a063f33.pas.sa.earthlink.net (asmtp-a063f33.pas.sa.earthlink.net [207.217.120.149]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6562A43D2F for ; Sat, 30 Oct 2004 14:58:20 +0000 (GMT) (envelope-from martes.wigglesworth@earthlink.net) Received: from [83.170.20.46] (helo=[192.168.2.50]) (TLSv1:AES256-SHA:256) (Exim 4.34) id 1CNugH-0002ip-Jm for freebsd-hackers@freebsd.org; Sat, 30 Oct 2004 07:58:20 -0700 From: Martes Wigglesworth To: freebsd-hackers@freebsd.org In-Reply-To: <20041030120101.CB1E616A4D5@hub.freebsd.org> References: <20041030120101.CB1E616A4D5@hub.freebsd.org> Content-Type: text/plain Organization: Wiggtekmicro Corporation Message-Id: <1099148287.1232.3.camel@Mobile1.276NET> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Sat, 30 Oct 2004 17:58:07 +0300 Content-Transfer-Encoding: 7bit X-ELNK-Trace: 532caf459ba90ce6996df0496707a79d9bea09fe345ed53d9ef193a6bfc3dd483e68da46da14356fced87c2a7a3b37ee19c9e15d1c7c699c350badd9bab72f9c X-Originating-IP: 83.170.20.46 Subject: EHCI Kernel Panic w/ 5.2.1-RELEASE Kernel X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: martes.wigglesworth@earthlink.net List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Oct 2004 14:58:20 -0000 Greetings. Does anyone know why the ehci kernel option, which is supposed to at least work for testing, gives me a kernel panic, whenever I use it, on the below-listed system specs? ps: If this is not the correct option, then I would appreciate your help in finding the right forum/IRC channel is possible. -- Respectfully, M.G.W. System: Asus M6N Intel Dothan 1.7 512MB RAM 40GB HD 10/100/1000 NIC Wireless b/g (not working yet) BSD-5.2.1 GCC-3.3.5/3.3.3(until I replace indigenous gcc) IFORT-for linux(Intell Fortran) gfortran python-2.3 Perl-5.6.1/5.8.5 Java-sdk-1.4.2_5 KDE-3.1.4