From lhmwzy at gmail.com Wed Oct 1 00:25:44 2008 From: lhmwzy at gmail.com (lhmwzy) Date: Wed Oct 1 00:25:51 2008 Subject: Would anybody port DragonFlyBSD's HAMMER fs to FreeBSD? In-Reply-To: <78fb9d960809291927n60358006w7ef845e7cb40ed93@mail.gmail.com> References: <78fb9d960809291927n60358006w7ef845e7cb40ed93@mail.gmail.com> Message-ID: <78fb9d960809301653o5cb09cefpf05eba0a9926b9fc@mail.gmail.com> I think port HAMMER fs to FreeBSD is easier than any other fs like ZFS. Would anybody do this? I do not have the skill or I will do this.:) links: http://www.dragonflybsd.org/hammer/index.shtml http://www.dragonflybsd.org/hammer/hammer.pdf From unixmania at gmail.com Wed Oct 1 00:57:08 2008 From: unixmania at gmail.com (Carlos A. M. dos Santos) Date: Wed Oct 1 00:57:15 2008 Subject: Would anybody port DragonFlyBSD's HAMMER fs to FreeBSD? In-Reply-To: <78fb9d960809301653o5cb09cefpf05eba0a9926b9fc@mail.gmail.com> References: <78fb9d960809291927n60358006w7ef845e7cb40ed93@mail.gmail.com> <78fb9d960809301653o5cb09cefpf05eba0a9926b9fc@mail.gmail.com> Message-ID: On Tue, Sep 30, 2008 at 8:53 PM, lhmwzy wrote: > I think port HAMMER fs to FreeBSD is easier than any other fs like ZFS. > Would anybody do this? > I do not have the skill or I will do this.:) > links: http://www.dragonflybsd.org/hammer/index.shtml > http://www.dragonflybsd.org/hammer/hammer.pdf > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > Do you subscribe freebsd-stable? This has bee discussed recently in this list: http://lists.freebsd.org/pipermail/freebsd-stable/2008-September/045506.html -- cd /usr/ports/sysutils/life make clean From gnemmi at gmail.com Wed Oct 1 01:30:01 2008 From: gnemmi at gmail.com (Gonzalo Nemmi) Date: Wed Oct 1 01:30:08 2008 Subject: Would anybody port DragonFlyBSD's HAMMER fs to FreeBSD? In-Reply-To: <78fb9d960809301653o5cb09cefpf05eba0a9926b9fc@mail.gmail.com> References: <78fb9d960809291927n60358006w7ef845e7cb40ed93@mail.gmail.com> <78fb9d960809301653o5cb09cefpf05eba0a9926b9fc@mail.gmail.com> Message-ID: <19e9a5dc0809301805s5a83b594q19eceac5ac79906d@mail.gmail.com> On Wed, Oct 1, 2008 at 1:53 AM, lhmwzy wrote: > I think port HAMMER fs to FreeBSD is easier than any other fs like ZFS. > Would anybody do this? > I do not have the skill or I will do this.:) > links: http://www.dragonflybsd.org/hammer/index.shtml > http://www.dragonflybsd.org/hammer/hammer.pdf > I've been wanting to ask the same question since July 6, 2008 ... http://leaf.dragonflybsd.org/mailarchive/kernel/2008-07/msg00015.html ... specially in the light of the all the effort that went (and goes on) on ZFS ... I, for once, don't care at all about ZFS, but would really like to see HAMMER ported over to FreeBSD (just as much as I'd like to see sysctl hw.sensors framework or so called framework... whereas it comes from Murenin's code or from code with a more "FreeBSD feel to it" .. or from a better implementation or solution or unameit). But I'm still too new to FreeBSD ... Would really like to see some resources redirected in HAMMER fs direction though ... -- Blessings Gonzalo Nemmi From dillon at apollo.backplane.com Wed Oct 1 01:44:00 2008 From: dillon at apollo.backplane.com (Matthew Dillon) Date: Wed Oct 1 01:44:07 2008 Subject: Would anybody port DragonFlyBSD's HAMMER fs to FreeBSD? References: <78fb9d960809291927n60358006w7ef845e7cb40ed93@mail.gmail.com> <78fb9d960809301653o5cb09cefpf05eba0a9926b9fc@mail.gmail.com> <19e9a5dc0809301805s5a83b594q19eceac5ac79906d@mail.gmail.com> Message-ID: <200810010144.m911i0Nw051464@apollo.backplane.com> Guys, please don't start a flamewar. And lhmwzy we discussed this on the DFly lists. It's really up to them... that is, a programmer who has an interest, inclination, and time. It isn't really fair to try to push it. I personally believe that the FreeBSD community as a whole should focus on ZFS for now. It has the momentum and the most interest on their lists. -Matt From lehmann at ans-netz.de Wed Oct 1 04:53:14 2008 From: lehmann at ans-netz.de (Oliver Lehmann) Date: Wed Oct 1 04:53:21 2008 Subject: system hangup - I'm lost In-Reply-To: <20080930214321.GA57024@icarus.home.lan> References: <20080929221408.54e6a03a.lehmann@ans-netz.de> <48E201DF.5090001@kkip.pl> <20080930104827.GB44675@icarus.home.lan> <20080930165534.f49f9f17.lehmann@ans-netz.de> <20080930214321.GA57024@icarus.home.lan> Message-ID: <20081001065309.3e7e108e.lehmann@ans-netz.de> Jeremy Chadwick wrote: > I can't find anything on Intel's site that clues me in; all the PDFs > are vague as far as what chips are on the board. Have you tried the Product specifications? http://download.intel.com/support/motherboards/server/l440gx/254151-003.pdf Beginning on page 33 (43 of the pdf) It has 3 different Server Management busses. the temperature part is handled within a Baseboard Management Controller. This BMC is implemented using a DS82CL10. Because it is a Server Board it offers a lot of managing features and other nice things like serial console at bootup and system monitoring features... but all unsupported withn FreeBSDs software ;) > P.S. -- You're the 2nd person I've encountered in under a week who's > using 440BX/GX-based hardware in present day. I would not be > surprised if the board is simply going bad/failing due to age. :-) Hm - I'd wonder if this would be the case. I mean I'm using older hardware (Tyan Tsunami S1830S, PII300, DAC960P, RAID-1 2*IBM DFHS S2W) without any problems as router ;) -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ From koitsu at FreeBSD.org Wed Oct 1 05:10:35 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Wed Oct 1 05:10:42 2008 Subject: system hangup - I'm lost In-Reply-To: <20081001065309.3e7e108e.lehmann@ans-netz.de> References: <20080929221408.54e6a03a.lehmann@ans-netz.de> <48E201DF.5090001@kkip.pl> <20080930104827.GB44675@icarus.home.lan> <20080930165534.f49f9f17.lehmann@ans-netz.de> <20080930214321.GA57024@icarus.home.lan> <20081001065309.3e7e108e.lehmann@ans-netz.de> Message-ID: <20081001051008.GA65754@icarus.home.lan> On Wed, Oct 01, 2008 at 06:53:09AM +0200, Oliver Lehmann wrote: > Jeremy Chadwick wrote: > > > I can't find anything on Intel's site that clues me in; all the PDFs > > are vague as far as what chips are on the board. > > Have you tried the Product specifications? No need -- Charles Sprickman sent me high-resolution pictures of all the ICs on the 440GX board, and I was able to identify all of them except a few (and those are obviously bit-latches or gates of some kind, so not important). Here's the list: - National Semiconductor Super I/O chip [1] - Cirrus Logic GD5480 video/VGA chip - Samsung SGRAM module for VGA chip; 16MBytes, 70ns - Intel 82371EB (PIIX4E) chip [2] - Dallas Semiconductor DS80CH11 power management chip - EtronTech SRAM; 256kbit, 15ns - Unknown, looks like flash or DRAM - Intel S82093AA I/O APIC - Octal bit-latch IC - Intel SB21150BC PCI bridge; 66MHz - Intel chip of some kind, can't make it out due to dust - Texas Instrument UCC5638 SCSI terminator - Texas Instrument UCC5638 SCSI terminator - Cypress Semiconductor W48C101 clock chip - Numerous other bit-latching ICs - Cypress Semiconductor 3.3V SDRAM buffering chip; probably used to drive SDRAM DIMMs (system memory) - ??? Model 684702-003; not sure what this does, but is of no interest - Some TI chip, doesn't interest me - 2x California Micro Devices ECP/EPP (parallel port) terminator - Maxim MAX211ECA1, no idea but doesn't interest me [1]: I'll have to look up datasheets on this chip to see if it supports H/W monitoring. [2]: This chip does a **lot**, the most important piece being it drives the entire PCI bus. It *does* support SMBus, but not I2C. Linux lmsensors supports this chip, but I don't know ""how"" it supports it. I will need to look up the specs/datasheets on it http://www.lm-sensors.org/browser/lm-sensors/trunk/doc/busses/i2c-piix4 > http://download.intel.com/support/motherboards/server/l440gx/254151-003.pdf > > Beginning on page 33 (43 of the pdf) > > It has 3 different Server Management busses. the temperature part is > handled within a Baseboard Management Controller. This BMC is implemented > using a DS82CL10. This tells me very little. :-) > Because it is a Server Board it offers a lot of managing features and > other nice things like serial console at bootup and system monitoring > features... but all unsupported withn FreeBSDs software ;) Really? That's interesting, because Charles Sprickman told me that there is no hardware monitoring information in the BIOS if you go in there. Most motherboards provide that in the BIOS as a centralised place above all else. Either way, I'm going to look into the details. Examining what exactly Linux lm-sensors means by "support" will be the first step. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From takeda at takeda.tk Wed Oct 1 05:36:56 2008 From: takeda at takeda.tk (=?utf-8?Q?Derek_Kuli=C5=84ski?=) Date: Wed Oct 1 05:37:05 2008 Subject: Would anybody port DragonFlyBSD's HAMMER fs to FreeBSD? In-Reply-To: References: <78fb9d960809291927n60358006w7ef845e7cb40ed93@mail.gmail.com> <78fb9d960809301653o5cb09cefpf05eba0a9926b9fc@mail.gmail.com> Message-ID: <274267384.20080930223647@takeda.tk> Hello Carlos, Tuesday, September 30, 2008, 5:57:06 PM, you wrote: > Do you subscribe freebsd-stable? This has bee discussed recently in this list: > http://lists.freebsd.org/pipermail/freebsd-stable/2008-September/045506.html I wouldn't call it "discussion". It was mentioned and then quickly it was forgotten. BTW: Matt Dillon, is the founder of DragonflyBSD, which apparently already supports HAMMER. As far as I know, no actual FreeBSD developer commented in that thread yet. -- Best regards, Derek mailto:takeda@takeda.tk How many of you believe in telekinesis? Raise MY hand! From lhmwzy at gmail.com Wed Oct 1 06:10:26 2008 From: lhmwzy at gmail.com (lhmwzy) Date: Wed Oct 1 06:10:33 2008 Subject: Would anybody port DragonFlyBSD's HAMMER fs to FreeBSD? In-Reply-To: <274267384.20080930223647@takeda.tk> References: <78fb9d960809291927n60358006w7ef845e7cb40ed93@mail.gmail.com> <78fb9d960809301653o5cb09cefpf05eba0a9926b9fc@mail.gmail.com> <274267384.20080930223647@takeda.tk> Message-ID: <78fb9d960809302310s3f817505j6605420e451268e4@mail.gmail.com> WWVzLgpJdCBzZWVtcyB0aGF0IG5vYm9keSBpcyBpbnRlcmVzdGVkIGluIHRoaXMuCi1NYXR0IHdv dWxkIG5vdCBwb3J0IGlzIHRvIEZyZWVCU0Qsd2hpY2ggaXMgYSBiaWcgcmVncmV0ZnVsLgoKMjAw OC8xMC8xIERlcmVrIEt1bGmovXNraSA8dGFrZWRhQHRha2VkYS50az46Cj4gSGVsbG8gQ2FybG9z LAo+Cj4gVHVlc2RheSwgU2VwdGVtYmVyIDMwLCAyMDA4LCA1OjU3OjA2IFBNLCB5b3Ugd3JvdGU6 Cj4KPj4gRG8geW91IHN1YnNjcmliZSBmcmVlYnNkLXN0YWJsZT8gVGhpcyBoYXMgYmVlIGRpc2N1 c3NlZCByZWNlbnRseSBpbiB0aGlzIGxpc3Q6Cj4+IGh0dHA6Ly9saXN0cy5mcmVlYnNkLm9yZy9w aXBlcm1haWwvZnJlZWJzZC1zdGFibGUvMjAwOC1TZXB0ZW1iZXIvMDQ1NTA2Lmh0bWwKPgo+IEkg d291bGRuJ3QgY2FsbCBpdCAiZGlzY3Vzc2lvbiIuIEl0IHdhcyBtZW50aW9uZWQgYW5kIHRoZW4g cXVpY2tseSBpdAo+IHdhcyBmb3Jnb3R0ZW4uCj4KPiBCVFc6IE1hdHQgRGlsbG9uLCBpcyB0aGUg Zm91bmRlciBvZiBEcmFnb25mbHlCU0QsIHdoaWNoIGFwcGFyZW50bHkKPiBhbHJlYWR5IHN1cHBv cnRzIEhBTU1FUi4KPgo+IEFzIGZhciBhcyBJIGtub3csIG5vIGFjdHVhbCBGcmVlQlNEIGRldmVs b3BlciBjb21tZW50ZWQgaW4gdGhhdAo+IHRocmVhZCB5ZXQuCj4KPiAtLQo+IEJlc3QgcmVnYXJk cywKPiAgRGVyZWsgICAgICAgICAgICAgICAgICAgICAgICAgICAgbWFpbHRvOnRha2VkYUB0YWtl ZGEudGsKPgo+IEhvdyBtYW55IG9mIHlvdSBiZWxpZXZlIGluIHRlbGVraW5lc2lzPyBSYWlzZSBN WSBoYW5kIQo+Cj4KPgo= From takeda at takeda.tk Wed Oct 1 06:20:47 2008 From: takeda at takeda.tk (=?utf-8?Q?Derek_Kuli=C5=84ski?=) Date: Wed Oct 1 06:20:53 2008 Subject: Would anybody port DragonFlyBSD's HAMMER fs to FreeBSD? In-Reply-To: <78fb9d960809302310s3f817505j6605420e451268e4@mail.gmail.com> References: <78fb9d960809291927n60358006w7ef845e7cb40ed93@mail.gmail.com> <78fb9d960809301653o5cb09cefpf05eba0a9926b9fc@mail.gmail.com> <274267384.20080930223647@takeda.tk> <78fb9d960809302310s3f817505j6605420e451268e4@mail.gmail.com> Message-ID: <1031817271.20080930231836@takeda.tk> Hello lhmwzy, Tuesday, September 30, 2008, 11:10:24 PM, you wrote: > Yes. > It seems that nobody is interested in this. > -Matt would not port is to FreeBSD,which is a big regretful. I'm pretty sure there are people who are interested, it looks more like there are no people who're capable of doing this and have time. -- Best regards, Derek mailto:takeda@takeda.tk An unemployed court jester is no one's fool. From lhmwzy at gmail.com Wed Oct 1 06:22:03 2008 From: lhmwzy at gmail.com (lhmwzy) Date: Wed Oct 1 06:22:11 2008 Subject: Would anybody port DragonFlyBSD's HAMMER fs to FreeBSD? Message-ID: <78fb9d960809302322m40026ee0wbba3f8af199697d4@mail.gmail.com> >Guys, please don't start a flamewar. And lhmwzy we discussed this >on the DFly lists. It's really up to them... that is, a programmer >who has an interest, inclination, and time. It isn't really fair to >try to push it. You're right. >I personally believe that the FreeBSD community as a whole should >focus on ZFS for now. It has the momentum and the most interest >on their lists. > -Matt That's OK. The olny thing we can do is waiting. From lhmwzy at gmail.com Wed Oct 1 06:29:15 2008 From: lhmwzy at gmail.com (lhmwzy) Date: Wed Oct 1 06:29:22 2008 Subject: Would anybody port DragonFlyBSD's HAMMER fs to FreeBSD? In-Reply-To: <1031817271.20080930231836@takeda.tk> References: <78fb9d960809291927n60358006w7ef845e7cb40ed93@mail.gmail.com> <78fb9d960809301653o5cb09cefpf05eba0a9926b9fc@mail.gmail.com> <274267384.20080930223647@takeda.tk> <78fb9d960809302310s3f817505j6605420e451268e4@mail.gmail.com> <1031817271.20080930231836@takeda.tk> Message-ID: <78fb9d960809302329i5958966bh988c2531741e5c1@mail.gmail.com> VGhhdCdzIGl0LgpTaW5jZSB3ZSBkb24ndCBoYXZlIHRoZSBza2lsbCx3aGF0IHdlIGNhbiBkbyBp cyB3YWl0LgoKV2FpdGluZyBpcyBzdWNoIGEgYmFkIHRoaW5nLi4uLi4uLgoKMjAwOC8xMC8xIERl cmVrIEt1bGmovXNraSA8dGFrZWRhQHRha2VkYS50az46Cj4gSGVsbG8gbGhtd3p5LAo+Cj4gVHVl c2RheSwgU2VwdGVtYmVyIDMwLCAyMDA4LCAxMToxMDoyNCBQTSwgeW91IHdyb3RlOgo+Cj4+IFll cy4KPj4gSXQgc2VlbXMgdGhhdCBub2JvZHkgaXMgaW50ZXJlc3RlZCBpbiB0aGlzLgo+PiAtTWF0 dCB3b3VsZCBub3QgcG9ydCBpcyB0byBGcmVlQlNELHdoaWNoIGlzIGEgYmlnIHJlZ3JldGZ1bC4K Pgo+IEknbSBwcmV0dHkgc3VyZSB0aGVyZSBhcmUgcGVvcGxlIHdobyBhcmUgaW50ZXJlc3RlZCwg aXQgbG9va3MgbW9yZQo+IGxpa2UgdGhlcmUgYXJlIG5vIHBlb3BsZSB3aG8ncmUgY2FwYWJsZSBv ZiBkb2luZyB0aGlzIGFuZCBoYXZlIHRpbWUuCj4KPiAtLQo+IEJlc3QgcmVnYXJkcywKPiAgRGVy ZWsgICAgICAgICAgICAgICAgICAgICAgICAgICAgbWFpbHRvOnRha2VkYUB0YWtlZGEudGsKPgo+ IEFuIHVuZW1wbG95ZWQgY291cnQgamVzdGVyIGlzIG5vIG9uZSdzIGZvb2wuCj4KPgo+Cg== From takeda at takeda.tk Wed Oct 1 06:57:35 2008 From: takeda at takeda.tk (=?utf-8?Q?Derek_Kuli=C5=84ski?=) Date: Wed Oct 1 06:57:42 2008 Subject: Would anybody port DragonFlyBSD's HAMMER fs to FreeBSD? In-Reply-To: <78fb9d960809302329i5958966bh988c2531741e5c1@mail.gmail.com> References: <78fb9d960809291927n60358006w7ef845e7cb40ed93@mail.gmail.com> <78fb9d960809301653o5cb09cefpf05eba0a9926b9fc@mail.gmail.com> <274267384.20080930223647@takeda.tk> <78fb9d960809302310s3f817505j6605420e451268e4@mail.gmail.com> <1031817271.20080930231836@takeda.tk> <78fb9d960809302329i5958966bh988c2531741e5c1@mail.gmail.com> Message-ID: <853814696.20080930235724@takeda.tk> Hello lhmwzy, Tuesday, September 30, 2008, 11:29:12 PM, you wrote: > That's it. > Since we don't have the skill,what we can do is wait. > Waiting is such a bad thing....... Though I don't have too much experience about filesystems, I personally would be interested in this since it would be a pretty good way to learn it. The biggest problem for me right now is the lack of time. I'm a full-time student right now :( If you have some experience in C and time, you can try to do some work, then announce to others. Maybe a developer will volunteer and act as a mentor. As far as I know many FreeBSD developers started that way. I remember PJD 7 years ago telling me that he's learning how to use FBSD, and look at him now :) I don't think "I don't know how to" is a good excuse. -- Best regards, Derek mailto:takeda@takeda.tk -- Will the information superhighway have any rest stops? From koitsu at FreeBSD.org Wed Oct 1 07:13:12 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Wed Oct 1 07:13:19 2008 Subject: Would anybody port DragonFlyBSD's HAMMER fs to FreeBSD? In-Reply-To: <78fb9d960809302329i5958966bh988c2531741e5c1@mail.gmail.com> References: <78fb9d960809291927n60358006w7ef845e7cb40ed93@mail.gmail.com> <78fb9d960809301653o5cb09cefpf05eba0a9926b9fc@mail.gmail.com> <274267384.20080930223647@takeda.tk> <78fb9d960809302310s3f817505j6605420e451268e4@mail.gmail.com> <1031817271.20080930231836@takeda.tk> <78fb9d960809302329i5958966bh988c2531741e5c1@mail.gmail.com> Message-ID: <20081001071309.GA13616@icarus.home.lan> On Wed, Oct 01, 2008 at 02:29:12PM +0800, lhmwzy wrote: > That's it. > Since we don't have the skill,what we can do is wait. > > Waiting is such a bad thing....... If this functionality is really something you want/need, you should consider finding a kernel programmer who would be willing to port it, for financial exchange (in English: you will be paying them $XX/hour to port it to FreeBSD). This has happened in the past for some key features. Like I said, it all depends on how much it matters to you. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From lhmwzy at gmail.com Wed Oct 1 07:15:41 2008 From: lhmwzy at gmail.com (lhmwzy) Date: Wed Oct 1 07:15:48 2008 Subject: Would anybody port DragonFlyBSD's HAMMER fs to FreeBSD? In-Reply-To: <20081001071309.GA13616@icarus.home.lan> References: <78fb9d960809291927n60358006w7ef845e7cb40ed93@mail.gmail.com> <78fb9d960809301653o5cb09cefpf05eba0a9926b9fc@mail.gmail.com> <274267384.20080930223647@takeda.tk> <78fb9d960809302310s3f817505j6605420e451268e4@mail.gmail.com> <1031817271.20080930231836@takeda.tk> <78fb9d960809302329i5958966bh988c2531741e5c1@mail.gmail.com> <20081001071309.GA13616@icarus.home.lan> Message-ID: <78fb9d960810010015l14a98f56re49c9eb386305118@mail.gmail.com> Yes,this is a way. I would do as you said if I need to do so. 2008/10/1 Jeremy Chadwick : > On Wed, Oct 01, 2008 at 02:29:12PM +0800, lhmwzy wrote: >> That's it. >> Since we don't have the skill,what we can do is wait. >> >> Waiting is such a bad thing....... > > If this functionality is really something you want/need, you should > consider finding a kernel programmer who would be willing to port it, > for financial exchange (in English: you will be paying them $XX/hour > to port it to FreeBSD). > > This has happened in the past for some key features. Like I said, it > all depends on how much it matters to you. > > -- > | Jeremy Chadwick jdc at parodius.com | > | Parodius Networking http://www.parodius.com/ | > | UNIX Systems Administrator Mountain View, CA, USA | > | Making life hard for others since 1977. PGP: 4BD6C0CB | > > From mamalos at eng.auth.gr Wed Oct 1 08:54:56 2008 From: mamalos at eng.auth.gr (George Mamalakis) Date: Wed Oct 1 08:55:04 2008 Subject: jails and mac_seeotheruids problems in 6-STABLE In-Reply-To: References: <48E1EBE1.50206@eng.auth.gr> <48E21BD9.1080101@eng.auth.gr> Message-ID: <48E33AD7.20707@eng.auth.gr> Robert Watson wrote: > > On Tue, 30 Sep 2008, George Mamalakis wrote: > >> It works like a charm! Thank you very much for your time and help, > > No problem -- I've gone ahead and committed that change to stable/6. > If you're able to test 6.4RC1 when it comes out to confirm that the > fix works there as desired, that would be most helpful. > I will csup to 6.4RC1 when available, and will inform you of the outcome. Thanks again. > Thanks, > > Robert N M Watson > Computer Laboratory > University of Cambridge > >> >> regards, >> >> >> Robert Watson wrote: >>> >>> On Tue, 30 Sep 2008, George Mamalakis wrote: >>> >>>> I have 3 servers in my lab. 2 of them are running 6-STABLE and one >>>> of them is running 7-STABLE. All three have services running in >>>> jails. I noticed a very peculiar behavior in 6-STABLE when I set >>>> the sysctl security.mac.seeotheruids.enabled=1. The root user in my >>>> jails was not able to see processes and sockets owned by other >>>> users of the same jail, whereas the root user of the host system >>>> could see every process (thank the Almighty). The same behavior >>>> does not apply on the server running 7-STABLE. >>>> >>>> In one sense it is more secure, since the root user in a jail is >>>> not as "strong" as the root user should be in a UNIX system. On the >>>> other hand, the root user looses its purpose of existence, which I >>>> suppose is a bug. >>>> >>>> Below are the security.mac sysctl settings of both 6 and 7-STABLE: >>> >>> Could you try modifying >>> src/sys/security/mac_seeotheruids/mac_seeotheruids.c in a 6.x tree >>> so that the call to suser_cred() in mac_seeotheruids_check() passes >>> the SUSER_ALLOWJAIL flag rather than 0? This may correct the >>> problem you're experiencing. Let me know and I can merge that >>> change to 6.x. >>> >>> Robert N M Watson >>> Computer Laboratory >>> University of Cambridge >>> >>>> >>>> 6-STABLE: >>>> >>>> security.mac.max_slots: 4 >>>> security.mac.enforce_network: 1 >>>> security.mac.enforce_pipe: 1 >>>> security.mac.enforce_posix_sem: 1 >>>> security.mac.enforce_suid: 1 >>>> security.mac.mmap_revocation_via_cow: 0 >>>> security.mac.mmap_revocation: 1 >>>> security.mac.enforce_vm: 1 >>>> security.mac.enforce_process: 1 >>>> security.mac.enforce_socket: 1 >>>> security.mac.enforce_system: 1 >>>> security.mac.enforce_kld: 1 >>>> security.mac.enforce_sysv_msg: 1 >>>> security.mac.enforce_sysv_sem: 1 >>>> security.mac.enforce_sysv_shm: 1 >>>> security.mac.enforce_fs: 1 >>>> security.mac.seeotheruids.specificgid: 0 >>>> security.mac.seeotheruids.specificgid_enabled: 0 >>>> security.mac.seeotheruids.primarygroup_enabled: 0 >>>> security.mac.seeotheruids.enabled: 1 >>>> security.mac.portacl.rules: uid:80:tcp:80,uid:80:tcp:443 >>>> security.mac.portacl.port_high: 1023 >>>> security.mac.portacl.autoport_exempt: 1 >>>> security.mac.portacl.suser_exempt: 1 >>>> security.mac.portacl.enabled: 1 >>>> >>>> >>>> 7-STABLE: >>>> >>>> security.mac.max_slots: 4 >>>> security.mac.version: 3 >>>> security.mac.mmap_revocation_via_cow: 0 >>>> security.mac.mmap_revocation: 1 >>>> security.mac.seeotheruids.specificgid: 0 >>>> security.mac.seeotheruids.specificgid_enabled: 0 >>>> security.mac.seeotheruids.suser_privileged: 1 >>>> security.mac.seeotheruids.primarygroup_enabled: 0 >>>> security.mac.seeotheruids.enabled: 1 >>>> >>>> I would be very glad if someone could inform me whether I am doing >>>> something wrong; if not I think I should inform FreeBSD about this >>>> bug. >>>> >>>> Thank you guys in advance, >>>> >>>> -- >>>> George Mamalakis >>>> >>>> IT Officer >>>> Electrical and Computer Engineer (Aristotle Un. of Thessaloniki), >>>> MSc (Imperial College of London) >>>> >>>> Department of Electrical and Computer Engineering >>>> Faculty of Engineering >>>> Aristotle University of Thessaloniki >>>> >>>> phone number : +30 (2310) 994379 >>>> >>>> _______________________________________________ >>>> freebsd-stable@freebsd.org mailing list >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >>>> To unsubscribe, send any mail to >>>> "freebsd-stable-unsubscribe@freebsd.org" >>>> >> >> -- >> George Mamalakis >> >> IT Officer >> Electrical and Computer Engineer (Aristotle Un. of Thessaloniki), >> MSc (Imperial College of London) >> >> Department of Electrical and Computer Engineering >> Faculty of Engineering >> Aristotle University of Thessaloniki >> >> phone number : +30 (2310) 994379 >> >> > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" -- George Mamalakis IT Officer Electrical and Computer Engineer (Aristotle Un. of Thessaloniki), MSc (Imperial College of London) Department of Electrical and Computer Engineering Faculty of Engineering Aristotle University of Thessaloniki phone number : +30 (2310) 994379 From ben at altesco.nl Wed Oct 1 09:24:01 2008 From: ben at altesco.nl (Ben Stuyts) Date: Wed Oct 1 09:24:09 2008 Subject: recommended setup for amd64 7-STABLE with ZFS, Samba 3.2 and possibly ACLs? In-Reply-To: <20080930104605.GA44675@icarus.home.lan> References: <20080930100848.GA9193@intserv.int1.b.intern> <20080930104605.GA44675@icarus.home.lan> Message-ID: <01EBDE48-7CEE-4A50-B4F9-C4D5BCFA18BD@altesco.nl> On 30 sep 2008, at 12:46, Jeremy Chadwick wrote: > On Tue, Sep 30, 2008 at 12:08:48PM +0200, Holger Kipp wrote: >> - email (imap) > > I've had good experience with dovecot; I tend to stay away from Cyrus > products (disgusting code with a history of security issues), and > Courier (no interest). I had to disable mmap access in dovecot, or it would coredump periodically. (mmap_disable = yes in dovecot.conf) I found that to be a problem only on ZFS. I don't know if that's been fixed yet. Apart from that it works great. Ben From philip at FreeBSD.org Wed Oct 1 09:39:11 2008 From: philip at FreeBSD.org (Philip Paeps) Date: Wed Oct 1 09:39:19 2008 Subject: Request for testing - top 3.8b1 in the base system In-Reply-To: <20080928142409.19f94e5b@anthesphoria.net> References: <20080928054620.GA80250@k7.mavetju> <20080928142409.19f94e5b@anthesphoria.net> Message-ID: <20081001093906.GI6749@carrot.paeps.cx> On 2008-09-28 14:24:09 (+0200), Nikola Le?i? wrote: > On Sun, 28 Sep 2008 15:46:20 +1000 Edwin Groothuis wrote: > > Please report any issues with it (compile time, run time) and a way to > > reproduce it (if possible). Thanks for your help! > > last pid: 70762; load avg: 1.22, 0.54, 0.33; up 0+16:48:11 14:08:01 > 177 threads: 11 running, 147 sleeping, 19 waiting > CPU: 27.6% user, 0.0% nice, 3.3% system, 0.7% interrupt, 68.4% idle > Kernel: 246626 ctxsw, 5063 trap, 362 intr, 354 soft, 5 fork, 4591 flt, 728 fr > Mem: 891M Active, 774M Inact, 233M Wired, 89M Cache, 112M Buf, 3668K Free > Swap: 4096M Total, 4096M Free > > [...] > > Btw, an aesthetic observation, in H mode the USERNAME column shrinks > and expands if username has less or more than 9 characters. :-) Another aesthetic observation is the alignment of the CPU: line - it would be nice if the data all lined up nicely with Kernel/Mem/Swap below. Very minor point though. Thanks for making this work! - Philip -- Philip Paeps Please don't Cc me, I am philip@freebsd.org subscribed to the list. Greebo's technique was unscientific and wouldn't have stood a chance against any decent swordmanship, but on his side was the fact that it is almost impossible to develop decent swordmanship when you seem to have run into a food mixer that is biting your ear off. -- (Terry Pratchett, Witches Abroad) From koitsu at FreeBSD.org Wed Oct 1 10:12:29 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Wed Oct 1 10:12:36 2008 Subject: recommended setup for amd64 7-STABLE with ZFS, Samba 3.2 and possibly ACLs? In-Reply-To: <01EBDE48-7CEE-4A50-B4F9-C4D5BCFA18BD@altesco.nl> References: <20080930100848.GA9193@intserv.int1.b.intern> <20080930104605.GA44675@icarus.home.lan> <01EBDE48-7CEE-4A50-B4F9-C4D5BCFA18BD@altesco.nl> Message-ID: <20081001101227.GA17912@icarus.home.lan> On Wed, Oct 01, 2008 at 10:42:32AM +0200, Ben Stuyts wrote: > I had to disable mmap access in dovecot, or it would coredump > periodically. (mmap_disable = yes in dovecot.conf) I found that to be a > problem only on ZFS. I don't know if that's been fixed yet. Apart from > that it works great. This seems relevant to your problem: http://www.dovecot.org/list/dovecot/2008-March/029565.html HEAD had this problem fixed in rev 1.28, dated 2008/03/15. RELENG_7 had this problem fixed in rev 1.31.2.2, dated 2008/04/26. Here's the proper file in cvsweb so you can see it yourself: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c Have you tried re-enabling mmap in dovecot on a system with a kernel build after those dates? If so, does it still randomly segfault? If so, have you reported this to pjd@? :-) -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From mirya at zoc.com.ua Wed Oct 1 11:24:51 2008 From: mirya at zoc.com.ua (Kyryll A Mirnenko aka Mirya) Date: Wed Oct 1 11:24:59 2008 Subject: GELI partition mount on boot fails after 7.0 -> 7.1-PRERELEASE upgrade In-Reply-To: <20080930173202.GA16426@slackbox.xs4all.nl> References: <200809301454.47473.mirya@zoc.com.ua> <20080930173202.GA16426@slackbox.xs4all.nl> Message-ID: <200810011424.02903.mirya@zoc.com.ua> On Tuesday 30 September 2008 20:32, Roland Smith wrote: > My GELI encrypted home partition works fine on amd64 7.1-PRERELEASE > (updated september 25th). I've been tracking stable since 7.0-RELEASE > without problems. > > My custom kernel includes GEOM_ELI, GEOM_LABEL, GEOM_MIRROR and > GEOM_PART_GPT and uses SCHED_ULE. Filesystem options are FFS, > SOFTUPDATES, UFS_ACL and UFS_DIRHASH. The ADAPTIVE_GIANT and VFS_AIO > options are also part of the kernel. > First, I get to the following: if you have GEOM_PART_BSD in the kernel alone, attaching GELI at the boot time works as expected. If you add GEOM_PART_MBR (so both GEOM_PART_BSD and GEOM_PART_MBR are in), you face the problem i've described. Second, i've tried to get kern.geom.confxml sysctl as Pawel suggested, but with no lack. First, the whole XML dump doesn't feet the console buffer, so i can't later extract it from dmesg; i've tried to dump it to some file, but due to the fact everything is mounted -ro at the point /etc/rc.d/geli is executed, i placed "mount -u -rw /" in the beginning of it. While that made a trick and i got the dump (see below), the GELI partition attached successfully (while instantly failed with "Cannot access ad0s1f (error=1)" without remounting / -rw), so I guess remounting / read-write changed something and such dump will be of no use: ACD acd0 1 r0w0e0 acd0 8796093020160 2048 MD ELI JOURNAL VOL_FFS VFS ffs.ad0s1a 4 r1w1e1 MBR msdosfs/WD Passport 4 r0w0e0 r0w0e0 msdosfs/WD Passports4 10924544 512 3 10924544 21337 714049363456 1394627663 73 da0s1 3 r0w0e0 r0w0e0 da0s1s4 10924544 512 3 10924544 21337 714049363456 1394627663 73 da0 2 r0w0e0 r0w0e0 da0s1 120031478784 512 0 120031478784 234436482 32256 63 12 ad0 2 r1w1e3 r1w1e2 ad0s1 40007729664 512 0 40007729664 78140097 32256 63 165 MBREXT BDE PART da0 2 MBR 4 63 234441647 63 255 r0w0e0 r0w0e0 da0s1 120031478784 512 1 !12 32256 120031478784 12 ad0s1 3 BSD 8 0 78140096 63 16 r1w1e2 r0w0e0 ad0s1f 5368709120 512 6 freebsd-ufs 1048576000 5368709120 7 r0w0e0 ad0s1e 734003200 512 5 freebsd-ufs 314572800 734003200 7 r0w0e0 ad0s1d 314572800 512 4 freebsd-ufs 0 314572800 7 r0w0e0 ad0s1b 402653184 512 2 freebsd-swap 6417285120 402653184 1 r1w1e1 ad0s1a 33187791360 512 1 freebsd-ufs 6819938304 33187791360 7 DISK cd0 1 r0w0e0 cd0 0 2048 0 0 da0 1 r0w0e0 da0 120034123776 512 255 63 ad0 1 r1w1e3 ad0 40007761920 512 16 63 LABEL da0s1 3 r0w0e0 r0w0e0 msdosfs/WD Passport 120031478784 512 0 120031478784 234436482 0 0 SWAP DEV msdosfs/WD Passports4 5 r0w0e0 da0s1s4 4 r0w0e0 msdosfs/WD Passport 4 r0w0e0 cd0 2 r0w0e0 da0s1 3 r0w0e0 da0s1 3 r0w0e0 da0 2 r0w0e0 ad0s1df 5 r0w0e0 ad0s1de 5 r0w0e0 ad0s1dd 5 r0w0e0 ad0s1dc 5 r0w0e0 ad0s1db 5 r0w0e0 ad0s1da 5 r0w0e0 ad0s1f 4 r0w0e0 ad0s1e 4 r0w0e0 ad0s1d 4 r0w0e0 ad0s1b 4 r0w0e0 ad0s1a 4 r0w0e0 acd0 2 r0w0e0 ad0s1 3 r0w0e0 ad0 2 r0w0e0 BSD ad0s1d 4 512 32256 32256 r0w0e0 r0w0e0 ad0s1df 5368709120 512 5 5368709120 10485760 1048576000 2048000 7 r0w0e0 ad0s1de 734003200 512 4 734003200 1433600 314572800 614400 7 r0w0e0 ad0s1dd 314572800 512 3 314572800 614400 0 0 7 r0w0e0 ad0s1dc 40007729664 512 2 40007729664 78140097 0 0 0 r0w0e0 ad0s1db 402653184 512 1 402653184 786432 6417285120 12533760 1 r0w0e0 ad0s1da 33187791360 512 0 33187791360 64819905 6819938304 13320192 7 Hope the above will help solving it, though as far as it's specific to my weird kernel configuration and the bad options combination is known it's low priority. Also, if someone can offer a simple way to get kern.geom.confxml at the time the problem occurs, i can experiment more. -- Regards, Mirya ICQ #313898202 From sclark46 at earthlink.net Wed Oct 1 11:41:58 2008 From: sclark46 at earthlink.net (Stephen Clark) Date: Wed Oct 1 11:42:07 2008 Subject: resource leak Message-ID: <48E36204.5090108@earthlink.net> Hello List, I am running into a strange problem that points to a resource leak. The problem manifests itself after one of our remote systems has been up around 100 days. The symptom is that it appears no new processes can be spawned. If I try to ssh to the unit, I can see the 3-way tcp handshake and then no more traffic. Examining log files, like cron, etc show that when this happens no more entries are written into the cron log. The unit is acting as a firewall, router and vpn appliance these functions continue to work. We have a C application that is periodically started out of a shell script that reports various information about the system, it stops reporting, while vpns, ospf routing, and ipfilter firewalling continue to work and write into their logfiles. My question is how do I monitor the various resources in the system that could prevent the spawning of a new process? This is on FreeBSD 6.1, ipsec-tools-6.6, quagga-0.99.3 Any ideas or directions would be greatly appreciated. Thanks, Steve From koitsu at FreeBSD.org Wed Oct 1 11:50:48 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Wed Oct 1 11:50:55 2008 Subject: resource leak In-Reply-To: <48E36204.5090108@earthlink.net> References: <48E36204.5090108@earthlink.net> Message-ID: <20081001115046.GA20384@icarus.home.lan> On Wed, Oct 01, 2008 at 07:41:56AM -0400, Stephen Clark wrote: > Hello List, > > I am running into a strange problem that points to a resource leak. The > problem manifests itself after one of our remote systems has been up > around 100 days. > The symptom is that it appears no new processes can be spawned. If I try to > ssh to the unit, I can see the 3-way tcp handshake and then no more traffic. > Examining log files, like cron, etc show that when this happens no more entries > are written into the cron log. The unit is acting as a firewall, router > and vpn appliance these functions continue to work. We have a C > application that is periodically started out of a shell script that > reports various information about the system, it stops reporting, while > vpns, ospf routing, and ipfilter firewalling continue to work and write > into their logfiles. > > My question is how do I monitor the various resources in the system that could > prevent the spawning of a new process? Periodically logging "ps -auxw" output to a file would be useful, as ideally you'd gradually see the list get longer and longer over time; it's possible you have many zombie processes as a result of a parent which is not reaping its children (calling waitpid(2) or its friends). Other things that might come in useful are "fstat" and "vmstat -s". It sounds like your C program relies heavily on system() or execl() and fork(), which is why it's affected -- while the other programs are likely kernel-level. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From sclark46 at earthlink.net Wed Oct 1 12:30:29 2008 From: sclark46 at earthlink.net (Stephen Clark) Date: Wed Oct 1 12:30:35 2008 Subject: resource leak In-Reply-To: <20081001115046.GA20384@icarus.home.lan> References: <48E36204.5090108@earthlink.net> <20081001115046.GA20384@icarus.home.lan> Message-ID: <48E36D62.6090001@earthlink.net> Jeremy Chadwick wrote: > On Wed, Oct 01, 2008 at 07:41:56AM -0400, Stephen Clark wrote: >> Hello List, >> >> I am running into a strange problem that points to a resource leak. The >> problem manifests itself after one of our remote systems has been up >> around 100 days. >> The symptom is that it appears no new processes can be spawned. If I try to >> ssh to the unit, I can see the 3-way tcp handshake and then no more traffic. >> Examining log files, like cron, etc show that when this happens no more entries >> are written into the cron log. The unit is acting as a firewall, router >> and vpn appliance these functions continue to work. We have a C >> application that is periodically started out of a shell script that >> reports various information about the system, it stops reporting, while >> vpns, ospf routing, and ipfilter firewalling continue to work and write >> into their logfiles. >> >> My question is how do I monitor the various resources in the system that could >> prevent the spawning of a new process? > > Periodically logging "ps -auxw" output to a file would be useful, as > ideally you'd gradually see the list get longer and longer over time; > it's possible you have many zombie processes as a result of a parent > which is not reaping its children (calling waitpid(2) or its friends). > > Other things that might come in useful are "fstat" and "vmstat -s". > > It sounds like your C program relies heavily on system() or execl() and > fork(), which is why it's affected -- while the other programs are > likely kernel-level. > Thanks Jeremy, I have added those commands to a periodic daily script. Another thing I have noticed is that quite often the problem seems to start at 2am in the morning, right when the periodic daily script runs. But I think it is coincidence and that we have reached the edge of the resource limit and all the jobs that get spawned by the periodic daily scripts pushes us over the limit. The other thing is that having logged into some of the systems that have been up in the 80 day range, I don't see a lot/any zombies. I just wonder if it is and fd leak, the fstat should point that out. Steve -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) From koitsu at FreeBSD.org Wed Oct 1 12:49:57 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Wed Oct 1 12:50:04 2008 Subject: resource leak In-Reply-To: <48E36D62.6090001@earthlink.net> References: <48E36204.5090108@earthlink.net> <20081001115046.GA20384@icarus.home.lan> <48E36D62.6090001@earthlink.net> Message-ID: <20081001124955.GA21577@icarus.home.lan> On Wed, Oct 01, 2008 at 08:30:26AM -0400, Stephen Clark wrote: > Jeremy Chadwick wrote: >> On Wed, Oct 01, 2008 at 07:41:56AM -0400, Stephen Clark wrote: >>> Hello List, >>> >>> I am running into a strange problem that points to a resource leak. >>> The problem manifests itself after one of our remote systems has been >>> up around 100 days. >>> The symptom is that it appears no new processes can be spawned. If I try to >>> ssh to the unit, I can see the 3-way tcp handshake and then no more traffic. >>> Examining log files, like cron, etc show that when this happens no more entries >>> are written into the cron log. The unit is acting as a firewall, >>> router and vpn appliance these functions continue to work. We have a >>> C application that is periodically started out of a shell script that >>> reports various information about the system, it stops reporting, >>> while vpns, ospf routing, and ipfilter firewalling continue to work >>> and write into their logfiles. >>> >>> My question is how do I monitor the various resources in the system that could >>> prevent the spawning of a new process? >> >> Periodically logging "ps -auxw" output to a file would be useful, as >> ideally you'd gradually see the list get longer and longer over time; >> it's possible you have many zombie processes as a result of a parent >> which is not reaping its children (calling waitpid(2) or its friends). >> >> Other things that might come in useful are "fstat" and "vmstat -s". >> >> It sounds like your C program relies heavily on system() or execl() and >> fork(), which is why it's affected -- while the other programs are >> likely kernel-level. >> > Thanks Jeremy, > > I have added those commands to a periodic daily script. > > Another thing I have noticed is that quite often the problem seems to > start at 2am in the morning, right when the periodic daily script runs. > > But I think it is coincidence and that we have reached the edge of the > resource limit and all the jobs that get spawned by the periodic daily > scripts pushes us over the limit. > > The other thing is that having logged into some of the systems that have > been up in the 80 day range, I don't see a lot/any zombies. I just wonder > if it is and fd leak, the fstat should point that out. You might find the below thread beneficial -- an individual came to the lists stating that they were running out of fds as a result of some Java software running amok on their systems. http://lists.freebsd.org/pipermail/freebsd-stable/2008-September/thread.html#45383 http://lists.freebsd.org/pipermail/freebsd-stable/2008-September/045383.html -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From sclark46 at earthlink.net Wed Oct 1 13:35:06 2008 From: sclark46 at earthlink.net (Stephen Clark) Date: Wed Oct 1 13:35:15 2008 Subject: resource leak In-Reply-To: <20081001124955.GA21577@icarus.home.lan> References: <48E36204.5090108@earthlink.net> <20081001115046.GA20384@icarus.home.lan> <48E36D62.6090001@earthlink.net> <20081001124955.GA21577@icarus.home.lan> Message-ID: <48E37C88.50805@earthlink.net> Jeremy Chadwick wrote: > On Wed, Oct 01, 2008 at 08:30:26AM -0400, Stephen Clark wrote: >> Jeremy Chadwick wrote: >>> On Wed, Oct 01, 2008 at 07:41:56AM -0400, Stephen Clark wrote: >>>> Hello List, >>>> >>>> I am running into a strange problem that points to a resource leak. >>>> The problem manifests itself after one of our remote systems has been >>>> up around 100 days. >>>> The symptom is that it appears no new processes can be spawned. If I try to >>>> ssh to the unit, I can see the 3-way tcp handshake and then no more traffic. >>>> Examining log files, like cron, etc show that when this happens no more entries >>>> are written into the cron log. The unit is acting as a firewall, >>>> router and vpn appliance these functions continue to work. We have a >>>> C application that is periodically started out of a shell script that >>>> reports various information about the system, it stops reporting, >>>> while vpns, ospf routing, and ipfilter firewalling continue to work >>>> and write into their logfiles. >>>> >>>> My question is how do I monitor the various resources in the system that could >>>> prevent the spawning of a new process? >>> Periodically logging "ps -auxw" output to a file would be useful, as >>> ideally you'd gradually see the list get longer and longer over time; >>> it's possible you have many zombie processes as a result of a parent >>> which is not reaping its children (calling waitpid(2) or its friends). >>> >>> Other things that might come in useful are "fstat" and "vmstat -s". >>> >>> It sounds like your C program relies heavily on system() or execl() and >>> fork(), which is why it's affected -- while the other programs are >>> likely kernel-level. >>> >> Thanks Jeremy, >> >> I have added those commands to a periodic daily script. >> >> Another thing I have noticed is that quite often the problem seems to >> start at 2am in the morning, right when the periodic daily script runs. >> >> But I think it is coincidence and that we have reached the edge of the >> resource limit and all the jobs that get spawned by the periodic daily >> scripts pushes us over the limit. >> >> The other thing is that having logged into some of the systems that have >> been up in the 80 day range, I don't see a lot/any zombies. I just wonder >> if it is and fd leak, the fstat should point that out. > > You might find the below thread beneficial -- an individual came to the > lists stating that they were running out of fds as a result of some > Java software running amok on their systems. > > http://lists.freebsd.org/pipermail/freebsd-stable/2008-September/thread.html#45383 > http://lists.freebsd.org/pipermail/freebsd-stable/2008-September/045383.html > Thanks, but after reading the thread is there a single place in the kernel that reports the how many fds are currently in use? Does the "no more fds" message get logged in /var/log/messages or only in the kernel log buffer, since I haven't seen that message in the messages file, and since we force to have a remote user reboot the box the kernel buffer is gone. Steve -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) From josh.carroll at gmail.com Wed Oct 1 13:56:54 2008 From: josh.carroll at gmail.com (Josh Carroll) Date: Wed Oct 1 13:57:02 2008 Subject: resource leak In-Reply-To: <48E37C88.50805@earthlink.net> References: <48E36204.5090108@earthlink.net> <20081001115046.GA20384@icarus.home.lan> <48E36D62.6090001@earthlink.net> <20081001124955.GA21577@icarus.home.lan> <48E37C88.50805@earthlink.net> Message-ID: <8cb6106e0810010656y7e2ac830je8465fe344824302@mail.gmail.com> > Thanks, but after reading the thread is there a single place in the kernel > that reports the how many fds are currently in use? Does the "no more fds" > message get logged in /var/log/messages or only in the kernel log buffer, > since I haven't seen that message in the messages file, and since we force > to have a remote user reboot the box the kernel buffer is gone. Just a guess, but perhaps: vmstat -m | grep -E 'filedesc|Type' Regards, Josh From ben at altesco.nl Wed Oct 1 13:59:22 2008 From: ben at altesco.nl (Ben Stuyts) Date: Wed Oct 1 13:59:30 2008 Subject: recommended setup for amd64 7-STABLE with ZFS, Samba 3.2 and possibly ACLs? In-Reply-To: <20081001101227.GA17912@icarus.home.lan> References: <20080930100848.GA9193@intserv.int1.b.intern> <20080930104605.GA44675@icarus.home.lan> <01EBDE48-7CEE-4A50-B4F9-C4D5BCFA18BD@altesco.nl> <20081001101227.GA17912@icarus.home.lan> Message-ID: On 1 okt 2008, at 12:12, Jeremy Chadwick wrote: > On Wed, Oct 01, 2008 at 10:42:32AM +0200, Ben Stuyts wrote: >> I had to disable mmap access in dovecot, or it would coredump >> periodically. (mmap_disable = yes in dovecot.conf) I found that to >> be a >> problem only on ZFS. I don't know if that's been fixed yet. Apart >> from >> that it works great. > > RELENG_7 had this problem fixed in rev 1.31.2.2, dated 2008/04/26. > > Here's the proper file in cvsweb so you can see it yourself: > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c > > Have you tried re-enabling mmap in dovecot on a system with a kernel > build after those dates? No, thanks for pointing that out. I have missed that. My 7-stable kernel is from July 16, so I will re-enable it and report back. Ben From lists at pingle.org Wed Oct 1 14:24:41 2008 From: lists at pingle.org (Jim Pingle) Date: Wed Oct 1 14:24:48 2008 Subject: system hangup - I'm lost In-Reply-To: <20080930214321.GA57024@icarus.home.lan> References: <20080929221408.54e6a03a.lehmann@ans-netz.de> <48E201DF.5090001@kkip.pl> <20080930104827.GB44675@icarus.home.lan> <20080930165534.f49f9f17.lehmann@ans-netz.de> <20080930214321.GA57024@icarus.home.lan> Message-ID: <48E38821.6090606@pingle.org> Jeremy Chadwick wrote: > P.S. -- You're the 2nd person I've encountered in under a week who's > using 440BX/GX-based hardware in present day. I would not be > surprised if the board is simply going bad/failing due to age. :-) I still have quite a few of these in active use. They are good workhorses. Sure, they don't have the raw computing power of newer servers, but for most of our tasks they get the job done. I also have a couple stacks of these in 2U cases sitting unused for spare parts and testing. They make great FreeBSD boxes, and handle low-moderate loads pretty well. We use them for all kinds of things: firewalls, personal/testing servers, SVN repos, monitoring and traffic graphing, name servers, you name it. To bring this back on topic, they might be old, but I have yet to encounter one single motherboard from that series that has failed on me in any way. (*knock on wood*) However, mine are all Intel L440GX boards with dual PIII CPUs in the 600-800MHz range. We try to squeeze every last bit of value out of the hardware we have. :-) Jim From johnny64 at swissjabber.org Wed Oct 1 14:44:37 2008 From: johnny64 at swissjabber.org ((-K JohnNy) Date: Wed Oct 1 14:46:16 2008 Subject: Request for testing - top 3.8b1 in the base system In-Reply-To: <20080928054620.GA80250@k7.mavetju> References: <20080928054620.GA80250@k7.mavetju> Message-ID: <20081001142450.GA58407@georg.localdomain> On Sun, Sep 28, 2008 at 03:46:20PM +1000, Edwin Groothuis wrote: > I have made an update for the top(1) utility in the FreeBSD base > system to get it from the 3.5b12 version to the 3.8b1 version. > > I have tried them on the amd64 architecture on FreeBSD -current and > FreeBSD 7.0 and on the i386 architecture on FreeBSD 7.0. > > The big new features are a line upper part with kernel statistics > (context-switches, traps, interrupts, faults etc) and the FLG table > (if you window is big enough) > > Some features specific to FreeBSD (dual display (press m)), threaded > processes, and jails have been ported to 3.8b1. > > The biggest fix (AFAICT) is the TIME and CPU table for threaded > processes, which are now calculated properly. > > The new code can be found on > http://www.mavetju.org/~edwin/freebsd-top-3.8b1-A.tar.gz > Go to 3.8b1/usr.sbin/top and run "make" there to produce the binary, > then run it via "./top". > > Please report any issues with it (compile time, run time) and a way > to reproduce it (if possible). Thanks for your help! > > Edwin I found another bug. The new top doesn't handle newlines in full commandlines correctly -- if there is a command whose commandline contains a newline, which is quite common while some compilation is in progress, it is just printed out as it is, breaking the one-process-per-line layout. -- (-K JohnNy alias Partial Derivative ? [home] http://johnny64.fixinko.sk/ [icq] 338328204 [abandoned] [jabber] JohnNy64@swissjabber.org [skype] JohnNy64-konik [abandoned] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20081001/541806bf/attachment.pgp From lehmann at ans-netz.de Wed Oct 1 15:29:49 2008 From: lehmann at ans-netz.de (Oliver Lehmann) Date: Wed Oct 1 15:30:01 2008 Subject: system hangup - I'm lost In-Reply-To: <20080929221408.54e6a03a.lehmann@ans-netz.de> References: <20080929221408.54e6a03a.lehmann@ans-netz.de> Message-ID: <20081001172943.99e9d494.lehmann@ans-netz.de> Hi, today I'd a crash again - I was not able to get a crash dump (thought a "panic" at the end of the kdb would do it but didn't - should have called dumpon before ;)) - so here now the information I was able to retrieve: Ok, what I've got so far is wrinting stuff out to the console when the system hangs up: swap_pager: indefinite wait buffer: bufobj: 0, blkno: 2, size: 4096 swap_pager: indefinite wait buffer: bufobj: 0, blkno: 2, size: 4096 swap_pager: indefinite wait buffer: bufobj: 0, blkno: 2, size: 4096 swap_pager: indefinite wait buffer: bufobj: 0, blkno: 2, size: 4096 ... and now the debugger stuff: KDB: enter: manual escape to debugger [thread pid 40 tid 100048 ] Stopped at kdb_enter+0x30: leave db> sh locks exclusive sleep mutex Giant r = 0 (0xc07c73c0) locked @ /usr/src/sys/kern/kern_intr.c:681 db> sh alllocks Process 40 (irq1: atkbd0) thread 0xc4503a80 (100048) exclusive sleep mutex Giant r = 0 (0xc07c73c0) locked @ /usr/src/sys/kern/kern_intr.c:681 db> so there are no locks except the one I caused but anyhow: db> bt 100048 Tracing pid 40 tid 100048 td 0xc4503a80 kdb_enter(c077aee6,4,1,0,1,...) at kdb_enter+0x30 scgetc(c0842b60,2,de391c88,c05ad0b7,c4609340,...) at scgetc+0x575 sckbdevent(c0823740,0,c0842b60,c07c73c0,8,...) at sckbdevent+0x210 atkbd_intr(c0823740,0,de391cd8,c05695b8,c0823740,...) at atkbd_intr+0xa1 atkbdintr(c0823740,0,c076448a,2a9,8,...) at atkbdintr+0x21 ithread_execute_handlers(c460cc90,c4449680,c076448a,30e,c4503a80,...) at ithread_execute_handlers+0x108 ithread_loop (c45f66c0,de391d38,c07642ea,30c,0,...) at ithread_loop+0x64 fork_exit (c05696b0,c45f66c0,de391d38) at fork_exit+0x78 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xde391d6c, ebp = 0 --- db> sh pcpu cpuid = 0 curthread = 0xc4503a80: pid 40 "irq1: atkbd0" curpcb = 0xde391d90 fpcurthread = none idlethread = 0xc444c780: pid 11 "idle: cpu0" APIC ID = 1 currentldt = 0x50 spin locks held: and now the output of ps (beware, it is long, no idea why there are so many cron - maybe the crond still schedules but they don't get processed?) show lockedvnods follows afterwards db> ps pid ppid pgrp uid state wmesg wchan cmd 57919 57918 692 0 SV ufs 0xc47857c8 cron 57918 692 692 0 S ppwait 0xc6e63a78 cron 57917 57916 692 0 SV ufs 0xc47857c8 cron 57916 692 692 0 S ppwait 0xc6e63c90 cron 57915 57914 692 0 SV ufs 0xc47857c8 cron 57914 692 692 0 S ppwait 0xc6eb3000 cron 57913 57912 692 0 SV ufs 0xc47857c8 cron 57912 692 692 0 S ppwait 0xc70a9430 cron 57911 57908 692 0 SV ufs 0xc47857c8 cron 57910 57907 692 0 SV ufs 0xc47857c8 cron 57909 57906 692 0 SV ufs 0xc47857c8 cron 57908 692 692 0 S ppwait 0xc6eb3648 cron 57907 692 692 0 S ppwait 0xc6eb3860 cron 57906 692 692 0 S ppwait 0xc6eb3a78 cron 57905 686 686 25 S ufs 0xc4953388 sendmail 57904 57902 692 0 SV ufs 0xc47857c8 cron 57903 57901 692 0 SV ufs 0xc47857c8 cron 57902 692 692 0 S ppwait 0xc49a4430 cron 57901 692 692 0 S ppwait 0xc49a4648 cron 57900 57899 692 0 SV ufs 0xc47857c8 cron 57899 692 692 0 S ppwait 0xc49a4860 cron 57898 57897 692 0 SV ufs 0xc47857c8 cron 57897 692 692 0 S ppwait 0xc49a4a78 cron 57896 57895 692 0 SV ufs 0xc47857c8 cron 57895 692 692 0 S ppwait 0xc49a4c90 cron 57894 57893 692 0 SV ufs 0xc47857c8 cron 57893 692 692 0 S ppwait 0xc6b7c648 cron 57892 57891 692 0 SV ufs 0xc47857c8 cron 57891 692 692 0 S ppwait 0xc66bc430 cron 57890 57889 692 0 SV ufs 0xc47857c8 cron 57889 692 692 0 S ppwait 0xc6b7c860 cron 57888 57887 692 0 SV ufs 0xc47857c8 cron 57887 692 692 0 S ppwait 0xc66bc860 cron 57886 686 686 25 S ufs 0xc4953388 sendmail 57885 57884 692 0 SV ufs 0xc47857c8 cron 57884 692 692 0 S ppwait 0xc66bca78 cron 57883 57882 692 0 SV ufs 0xc47857c8 cron 57882 692 692 0 S ppwait 0xc66bcc90 cron 57881 57880 692 0 SV ufs 0xc47857c8 cron 57880 692 692 0 S ppwait 0xc6a65000 cron 57879 57878 692 0 SV ufs 0xc47857c8 cron 57878 692 692 0 S ppwait 0xc6a65218 cron 57877 57876 692 0 SV ufs 0xc47857c8 cron 57876 692 692 0 S ppwait 0xc6a65430 cron 57875 57874 692 0 SV ufs 0xc47857c8 cron 57874 692 692 0 S ppwait 0xc6a65648 cron 57873 57872 692 0 SV ufs 0xc47857c8 cron 57872 692 692 0 S ppwait 0xc48ed000 cron 57871 57867 692 0 SV ufs 0xc47857c8 cron 57870 57868 692 0 SV ufs 0xc47857c8 cron 57869 57866 692 0 SV ufs 0xc47857c8 cron 57868 692 692 0 S ppwait 0xc48ed430 cron 57867 692 692 0 S ppwait 0xc48ed648 cron 57866 692 692 0 S ppwait 0xc48ed860 cron 57865 686 686 25 S ufs 0xc4953388 sendmail 57864 57862 692 0 SV ufs 0xc47857c8 cron 57862 692 692 0 S ppwait 0xc4910000 cron 57861 692 692 0 S ppwait 0xc4910218 cron 57860 57859 692 0 SV ufs 0xc47857c8 cron 57859 692 692 0 S ppwait 0xc4910430 cron 57858 57857 692 0 SV ufs 0xc47857c8 cron 57857 692 692 0 S ppwait 0xc4910648 cron 57856 57855 692 0 SV ufs 0xc47857c8 cron 57855 692 692 0 S ppwait 0xc4910860 cron 57854 57853 692 0 SV ufs 0xc47857c8 cron 57853 692 692 0 S ppwait 0xc4910a78 cron 57852 57851 692 0 SV ufs 0xc47857c8 cron 57851 692 692 0 S ppwait 0xc4910c90 cron 57850 57849 692 0 SV ufs 0xc47857c8 cron 57849 692 692 0 S ppwait 0xc49a4000 cron 57848 57847 692 0 SV ufs 0xc47857c8 cron 57847 692 692 0 S ppwait 0xc49a4218 cron 57846 686 686 25 S ufs 0xc4953388 sendmail 57845 57844 692 0 SV ufs 0xc47857c8 cron 57844 692 692 0 S ppwait 0xc4e47860 cron 57843 57842 692 0 SV ufs 0xc47857c8 cron 57842 692 692 0 S ppwait 0xc66cd430 cron 57841 57840 692 0 SV ufs 0xc47857c8 cron 57840 692 692 0 S ppwait 0xc66cd648 cron 57839 57838 692 0 SV ufs 0xc47857c8 cron 57838 692 692 0 S ppwait 0xc4e59218 cron 57837 57836 692 0 SV ufs 0xc47857c8 cron 57836 692 692 0 S ppwait 0xc5cd6860 cron 57835 57834 692 0 SV ufs 0xc47857c8 cron 57834 692 692 0 S ppwait 0xc5cd5430 cron 57833 57832 692 0 SV ufs 0xc47857c8 cron 57832 692 692 0 S ppwait 0xc66c8c90 cron 57831 57828 692 0 SV ufs 0xc47857c8 cron 57830 57827 692 0 SV ufs 0xc47857c8 cron 57829 57826 692 0 SV ufs 0xc47857c8 cron 57828 692 692 0 S ppwait 0xc691e218 cron 57827 692 692 0 S ppwait 0xc4bd3218 cron 57826 692 692 0 S ppwait 0xc66c8430 cron 57825 686 686 25 S ufs 0xc4953388 sendmail 57824 57822 692 0 SV ufs 0xc47857c8 cron 57823 57821 692 0 SV ufs 0xc47857c8 cron 57822 692 692 0 S ppwait 0xc66cd860 cron 57821 692 692 0 S ppwait 0xc474ac90 cron 57820 57819 692 0 SV ufs 0xc47857c8 cron 57819 692 692 0 S ppwait 0xc4cdf860 cron 57818 57817 692 0 SV ufs 0xc47857c8 cron 57817 692 692 0 S ppwait 0xc4e5f430 cron 57816 57815 692 0 SV ufs 0xc47857c8 cron 57815 692 692 0 S ppwait 0xc5cd5000 cron 57814 57813 692 0 SV ufs 0xc47857c8 cron 57813 692 692 0 S ppwait 0xc4e47430 cron 57812 57811 692 0 SV ufs 0xc47857c8 cron 57811 692 692 0 S ppwait 0xc4bcd648 cron 57810 57809 692 0 SV ufs 0xc47857c8 cron 57809 692 692 0 S ppwait 0xc4cdfa78 cron 57808 57807 692 0 SV ufs 0xc47857c8 cron 57807 692 692 0 S ppwait 0xc4a34a78 cron 57806 686 686 25 S ufs 0xc4953388 sendmail 57805 57804 692 0 SV ufs 0xc47857c8 cron 57804 692 692 0 S ppwait 0xc6923648 cron 57803 57802 692 0 SV ufs 0xc47857c8 cron 57802 692 692 0 S ppwait 0xc4cdf430 cron 57801 57800 692 0 SV ufs 0xc47857c8 cron 57800 692 692 0 S ppwait 0xc691e430 cron 57799 57798 692 0 SV ufs 0xc47857c8 cron 57798 692 692 0 S ppwait 0xc4e59860 cron 57797 57796 692 0 SV ufs 0xc47857c8 cron 57796 692 692 0 S ppwait 0xc4e5fa78 cron 57795 57794 692 0 SV ufs 0xc47857c8 cron 57794 692 692 0 S ppwait 0xc4e4cc90 cron 57793 1035 1035 0 SLJ vmpfw 0xc1639568 httpd 57792 1035 1035 0 SLJ vmpfw 0xc1639568 httpd 57791 57790 692 0 SV ufs 0xc47857c8 cron 57790 692 692 0 S ppwait 0xc4e59000 cron 57789 1035 1035 0 SLJ vmpfw 0xc1639568 httpd 57788 57785 57788 0 SVs ufs 0xc47857c8 cron 57787 57784 57787 2 SVs ufs 0xc47857c8 cron 57786 57783 57786 0 SVs ufs 0xc47d9168 cron 57785 692 692 0 S ppwait 0xc66cda78 cron 57784 692 692 0 S ppwait 0xc66c8000 cron 57783 692 692 0 S ppwait 0xc66cd000 cron 57782 686 686 25 S biord 0xd3e374b8 sendmail 57780 57778 57778 2 S ufs 0xc6ebd9e8 sh 57778 57776 57778 2 Ss wait 0xc4a33000 sh 57776 692 692 0 S piperd 0xc719e660 cron 57772 1035 1035 0 SLJ vmpfw 0xc1639568 httpd 57771 1035 1035 0 SLJ swread 0xc1639568 httpd 57770 57769 57770 0 SVsJ ufs 0xc5502058 cron 57769 1048 1048 0 SJ ppwait 0xc4e5c000 cron 57765 57764 57765 0 SVsJ getblk 0xd3eba538 cron 57764 1048 1048 0 SJ ppwait 0xc5cd6000 cron 57762 57761 57761 2 S biord 0xd3e875f8 sh 57761 57760 57761 2 Ss wait 0xc4bd3a78 sh 57760 692 692 0 S piperd 0xc68137f8 cron 57759 936 936 0 SJ biowr 0xd3eba4d8 rateup 57732 51526 46607 0 S+ biowr 0xd3e5b170 sh 51526 51268 46607 0 S+ wait 0xc4cdf000 sh 51268 51267 46607 0 S+ wait 0xc66cd218 sh 51267 51264 46607 0 S+ wait 0xc5cd5c90 sh 51264 49494 46607 0 S+ select 0xc0815024 make 49494 46607 46607 0 S+ wait 0xc4bcd000 sh 78290 1035 1035 80 SJ ufs 0xc47668d8 httpd 78289 1035 1035 80 SJ ufs 0xc4ad87c8 httpd 78282 1035 1035 80 SJ ufs 0xc47d1168 httpd 75486 1035 1035 80 SJ ufs 0xc47d1168 httpd 72716 1035 1035 80 SJ ufs 0xc47d1168 httpd 72715 1035 1035 80 SJ ufs 0xc4ac5168 httpd 72603 1035 1035 80 SJ ufs 0xc4ac5388 httpd 70352 1035 1035 80 SJ ufs 0xc47d1168 httpd 53179 53008 53179 0 S+ ufs 0xc47857c8 csh 53008 49451 53008 1000 S+ wait 0xc4bcda78 su 49451 49449 49451 1000 Ss+ pause 0xc4e5c67c tcsh 49449 49270 49270 1000 S select 0xc0815024 sshd 49270 678 49270 0 Ss sbwait 0xc508179c sshd 46607 1208 46607 0 S+ wait 0xc66c8860 sh 1208 1206 1208 0 Ss+ pause 0xc4bd3cc4 csh 1206 1 1206 0 Ss select 0xc0815024 screen 1151 1117 1151 0 S+ ttyin 0xc4616010 csh 1132 928 928 89 SJ select 0xc0815024 perl5.8.8 1131 928 928 89 SJ select 0xc0815024 perl5.8.8 1118 1 1 0 S ttydcd 0xc4614000 getty 1117 1 1117 0 Ss+ wait 0xc4bcdc90 login 1116 1 1116 0 Ss+ ttyin 0xc4613010 getty 1115 1 1115 0 Ss+ ttyin 0xc461f410 getty 1114 1 1114 0 Ss+ ttyin 0xc45fc810 getty 1113 1 1113 0 Ss+ ttyin 0xc4615010 getty 1112 1 1112 0 Ss+ ttyin 0xc461ec10 getty 1111 1 1111 0 Ss+ ttyin 0xc461e810 getty 1110 1 1110 0 Ss+ ttyin 0xc461d810 getty 1109 1 1109 0 Ss+ ttyin 0xc461d410 getty 1093 1 1093 0 Ss select 0xc0815024 inetd 1092 1 1092 1000 SsJ ufs 0xc47d1168 fetchmail 1048 1 1048 0 SsJ ufs 0xc498a9e8 cron 1043 1 1043 0 SsJ select 0xc0815024 sshd 1035 1 1035 0 SsJ nanslp 0xc07c7cac httpd 1019 1 1019 0 SsJ (threaded) bacula-fd 100137 S kserel 0xc475fc94 bacula-fd 100158 S kserel 0xc475fc94 bacula-fd 100164 S select 0xc0815024 bacula-fd 100162 S ksesigwa 0xc49b1350 bacula-fd 1001 1000 1001 0 S+J select 0xc0815024 couriertcpd 1000 1 1000 0 S+J piperd 0xc48e5660 courierlogger 988 987 988 0 S+J select 0xc0815024 couriertcpd 987 1 987 0 S+J piperd 0xc4819cc0 courierlogger 976 975 976 0 S+J select 0xc0815024 couriertcpd 975 1 975 0 S+J piperd 0xc4a72198 courierlogger 971 946 945 0 S+J select 0xc0815024 authdaemond 970 946 945 0 S+J select 0xc0815024 authdaemond 969 946 945 0 S+J select 0xc0815024 authdaemond 968 946 945 0 S+J select 0xc0815024 authdaemond 967 946 945 0 S+J select 0xc0815024 authdaemond 946 945 945 0 S+J select 0xc0815024 authdaemond 945 1 945 0 S+J piperd 0xc48197f8 courierlogger 936 1 936 0 SsJ piperd 0xc6813cc0 perl 928 1 928 0 SsJ select 0xc0815024 perl5.8.8 926 1 907 0 S+J select 0xc0815024 sqwebmaild 924 1 907 0 S+J select 0xc0815024 sqwebmaild 922 1 907 0 S+J select 0xc0815024 sqwebmaild 920 1 907 0 S+J select 0xc0815024 sqwebmaild 918 1 907 0 S+J select 0xc0815024 sqwebmaild 908 907 907 0 S+J select 0xc0815024 sqwebmaild 907 1 907 0 S+J piperd 0xc48e5000 courierlogger 904 897 877 85 SJ piperd 0xc476fcc0 qmail-clean 903 897 877 86 SJ select 0xc0815024 qmail-rspawn 902 897 877 0 SJ select 0xc0815024 qmail-lspawn 901 897 877 83 SJ piperd 0xc4763330 multilog 897 887 877 87 SJ biord 0xd3e299a0 qmail-send 896 886 877 83 SJ piperd 0xc48e5198 multilog 895 885 877 89 SJ accept 0xc4a22302 tcpserver 894 883 877 0 SJ accept 0xc4a2772e tcpserver 893 888 877 83 SJ piperd 0xc47627f8 multilog 892 884 877 83 SJ piperd 0xc48e5330 multilog 888 879 877 0 SJ select 0xc0815024 supervise 887 879 877 0 SJ select 0xc0815024 supervise 886 879 877 0 SJ select 0xc0815024 supervise 885 879 877 0 SJ select 0xc0815024 supervise 884 879 877 0 SJ select 0xc0815024 supervise 883 879 877 0 SJ select 0xc0815024 supervise 880 1 877 0 SJ piperd 0xc476f330 readproctitle 879 1 877 0 SJ ufs 0xc47d1168 svscan 837 1 837 0 SsJ select 0xc0815024 syslogd 692 1 692 0 Ss nanslp 0xc07c7cac cron 686 1 686 25 Ss pause 0xc47f267c sendmail 683 1 683 0 Ss select 0xc0815024 sendmail 678 1 678 0 Ss select 0xc0815024 sshd 663 1 663 910 Ss (threaded) bacula-dir 100118 S kserel 0xc45d4754 bacula-dir 100121 S kserel 0xc45d4754 bacula-dir 100160 S select 0xc0815024 bacula-dir 100127 S ksesigwa 0xc47f4bb0 bacula-dir 657 1 657 0 Ss (threaded) bacula-fd 100123 S kserel 0xc45d4b14 bacula-fd 100114 S kserel 0xc45d4b14 bacula-fd 100163 S select 0xc0815024 bacula-fd 100115 S ksesigwa 0xc47f2568 bacula-fd 650 1 650 910 Ss (threaded) bacula-sd 100143 S kserel 0xc4450874 bacula-sd 100281 S kserel 0xc4450874 bacula-sd 100116 S select 0xc0815024 bacula-sd 100112 S ksesigwa 0xc474abb0 bacula-sd 649 623 620 88 S+ (threaded) mysqld 100119 S kserel 0xc45d4814 mysqld 100165 S select 0xc0815024 mysqld 100089 S kserel 0xc45d4814 mysqld 100125 S kserel 0xc44506f4 mysqld 100124 S sigwait 0xe4239c0c mysqld 100122 S ksesigwa 0xc47f4780 mysqld 623 1 620 88 S+ wait 0xc4760218 sh 610 1 610 0 Ss select 0xc0815024 usbd 588 1 588 0 Ss biord 0xd3d73060 ntpd 578 1 578 0 Ss select 0xc0815024 lpd 570 1 51 0 S+ select 0xc0815024 3dm2 569 555 555 0 S pause 0xc474a894 smbd 555 1 555 0 Ss select 0xc0815024 smbd 551 1 551 0 Ss select 0xc0815024 nmbd 532 1 531 0 S select 0xc0815024 snmpd 519 513 513 0 S rpcsvc 0xc4722a6c rpc.lockd 518 513 513 0 S nfslockd 0xc081d3c8 rpc.lockd 513 1 513 0 Ss select 0xc0815024 rpc.lockd 506 1 506 0 Ss select 0xc0815024 rpc.statd 500 496 496 0 S - 0xc4560c00 nfsd 499 496 496 0 S - 0xc46e6200 nfsd 498 496 496 0 S - 0xc46cec00 nfsd 497 496 496 0 S - 0xc4551a00 nfsd 496 1 496 0 Ss accept 0xc4802b5a nfsd 488 1 488 0 Ss ufs 0xc47857c8 mountd 452 1 452 0 Ss select 0xc0815024 rpcbind 435 1 435 0 Ss biord 0xd3ea6488 syslogd 377 1 377 0 Ss select 0xc0815024 devd 139 1 139 0 Ss pause 0xc474a034 adjkerntz 50 0 0 0 SL - 0xe2618cf8 [schedcpu] 49 0 0 0 SL sdflush 0xc0822714 [softdepflush] 48 0 0 0 SL vlruwt 0xc45d2a78 [vnlru] 47 0 0 0 SL getblk 0xd3e47410 [syncer] 46 0 0 0 SL psleep 0xc08155a0 [bufdaemon] 45 0 0 0 SL pgzero 0xc0823724 [pagezero] 44 0 0 0 SL psleep 0xc082322c [vmdaemon] 43 0 0 0 SL psleep 0xc08231e8 [pagedaemon] 42 0 0 0 WL [swi0: sio] 41 0 0 0 SL - 0xc45f283c [fdc0] 40 0 0 0 RL CPU 0 [irq1: atkbd0] 39 0 0 0 SL usbevt 0xc45e6210 [usb4] 38 0 0 0 WL [irq15: ata1] 37 0 0 0 WL [irq14: ata0] 36 0 0 0 SL usbevt 0xc44f1210 [usb3] 35 0 0 0 WL [irq16: ehci0] 34 0 0 0 SL usbevt 0xc45da210 [usb2] 33 0 0 0 WL [irq23: ohci2] 32 0 0 0 SL usbevt 0xc45d8210 [usb1] 31 0 0 0 WL [irq22: ohci1] 30 0 0 0 SL usbtsk 0xc07c4364 [usbtask] 29 0 0 0 SL usbevt 0xc4577210 [usb0] 28 0 0 0 WL [irq21: fxp0 ohci0+] 27 0 0 0 SL idle 0xc4560600 [aic_recovery1] 26 0 0 0 SL idle 0xc4560600 [aic_recovery1] 25 0 0 0 SL idle 0xc4560400 [aic_recovery0] 24 0 0 0 WL [irq19: ahc0 ahc1] 23 0 0 0 SL idle 0xc4560400 [aic_recovery0] 22 0 0 0 WL [irq18: twa0] 21 0 0 0 WL [irq9: acpi0] 20 0 0 0 WL [swi6: Giant taskq] 19 0 0 0 WL [swi6: task queue] 18 0 0 0 WL [swi2: cambio] 17 0 0 0 SL ccb_scan 0xc07c0d04 [xpt_thrd] 9 0 0 0 SL - 0xc44a5700 [kqueue taskq] 8 0 0 0 SL - 0xc44a5800 [acpi_task_2] 7 0 0 0 SL - 0xc44a5800 [acpi_task_1] 6 0 0 0 SL - 0xc44a5800 [acpi_task_0] 16 0 0 0 WL [swi5: +] 5 0 0 0 SL - 0xc44a5980 [thread taskq] 15 0 0 0 SL - 0xc07c3c40 [yarrow] 4 0 0 0 SL - 0xc07c4c68 [g_down] 3 0 0 0 SL - 0xc07c4c64 [g_up] 2 0 0 0 SL - 0xc07c4c5c [g_event] 14 0 0 0 WL [swi3: vm] 13 0 0 0 WL [swi4: clock sio] 12 0 0 0 WL [swi1: net] 11 0 0 0 RL [idle: cpu0] 10 0 0 0 RL CPU 1 [idle: cpu1] 1 0 1 0 SLs wait 0xc4451000 [init] 0 0 0 0 WLs [swapper] db> show lockedvnods Locked vnodes 0xc4785770: tag ufs, type VDIR usecount 1, writecount 0, refcount 67 mountedhere 0 flags (VV_ROOT) v_object 0xc6401000 ref 0 pages 0 lock type ufs: EXCL (count 1) by thread 0xc4bd0180 (pid 57786) with 65 pending ino 2, on dev da0s1d 0xc47da660: tag ufs, type VDIR usecount 1, writecount 0, refcount 2 mountedhere 0 flags () v_object 0xc5f8239c ref 0 pages 0 lock type ufs: EXCL (count 1) by thread 0xc4e48c00 (pid 57780) ino 32899, on dev da0s1d 0xc47d9110: tag ufs, type VDIR usecount 5, writecount 0, refcount 9 mountedhere 0 flags () v_object 0xc6f788c4 ref 0 pages 1 lock type ufs: EXCL (count 1) by thread 0xc47f6900 (pid 588) with 1 pending ino 49347, on dev da0s1d 0xc4827110: tag ufs, type VREG usecount 1, writecount 1, refcount 3 mountedhere 0 flags () v_object 0xc481d948 ref 0 pages 3 lock type ufs: EXCL (count 1) by thread 0xc4611600 (pid 435) ino 49480, on dev da0s1d 0xc4953330: tag ufs, type VDIR usecount 15, writecount 0, refcount 18 mountedhere 0 flags () v_object 0xc4960318 ref 0 pages 1 lock type ufs: EXCL (count 1) by thread 0xc5cdac00 (pid 57782) with 6 pending ino 49359, on dev da0s1d 0xc6ebd990: tag ufs, type VDIR usecount 1, writecount 0, refcount 3 mountedhere 0 flags () lock type ufs: EXCL (count 1) by thread 0xc4e4a480 (pid 57762) with 1 pending ino 32900, on dev da0s1d 0xc47b6aa0: tag syncer, type VNON usecount 1, writecount 0, refcount 2 mountedhere 0 flags () lock type syncer: EXCL (count 1) by thread 0xc45d3600 (pid 47) 0xc5540330: tag ufs, type VDIR usecount 1, writecount 0, refcount 4 mountedhere 0 flags () v_object 0xc6cca840 ref 0 pages 1 lock type ufs: EXCL (count 1) by thread 0xc4f19000 (pid 57732) ino 1013632, on dev da0s1f 0xc78e6dd0: tag ufs, type VREG usecount 1, writecount 0, refcount 1 mountedhere 0 flags () lock type ufs: EXCL (count 1) by thread 0xc4f19000 (pid 57732) ino 1016580, on dev da0s1f 0xc47d1110: tag ufs, type VDIR usecount 165, writecount 0, refcount 168 mountedhere 0 flags () v_object 0xc4a2fdec ref 0 pages 2 lock type ufs: EXCL (count 1) by thread 0xc4951480 (pid 1048) with 6 pending ino 9212984, on dev da0s1g 0xc47d2000: tag ufs, type VDIR usecount 1, writecount 0, refcount 4 mountedhere 0 flags () v_object 0xc51f5d68 ref 0 pages 2 lock type ufs: EXCL (count 1) by thread 0xc5cd8d80 (pid 72603) ino 9213777, on dev da0s1g 0xc498a990: tag ufs, type VDIR usecount 1, writecount 0, refcount 4 mountedhere 0 flags () v_object 0xc5c4839c ref 0 pages 2 lock type ufs: EXCL (count 1) by thread 0xc4e5e000 (pid 57770) with 1 pending ino 9213027, on dev da0s1g 0xc4ac5330: tag ufs, type VDIR usecount 1, writecount 0, refcount 5 mountedhere 0 flags () v_object 0xc51f5dec ref 0 pages 2 lock type ufs: EXCL (count 1) by thread 0xc4e4a000 (pid 72715) with 1 pending ino 9213787, on dev da0s1g 0xc4ac5110: tag ufs, type VDIR usecount 1, writecount 0, refcount 5 mountedhere 0 flags () v_object 0xc51f6000 ref 0 pages 2 lock type ufs: EXCL (count 1) by thread 0xc4a35300 (pid 78289) with 1 pending ino 9214698, on dev da0s1g 0xc4ad8770: tag ufs, type VDIR usecount 1, writecount 0, refcount 5 mountedhere 0 flags () v_object 0xc51f6084 ref 0 pages 2 lock type ufs: EXCL (count 1) by thread 0xc4a35600 (pid 78290) with 1 pending ino 9214827, on dev da0s1g 0xc4766880: tag ufs, type VDIR usecount 1, writecount 0, refcount 5 mountedhere 0 flags () v_object 0xc5976108 ref 0 pages 2 lock type ufs: EXCL (count 1) by thread 0xc4a36a80 (pid 57759) with 1 pending ino 9214859, on dev da0s1g 0xc5502000: tag ufs, type VREG usecount 0, writecount 0, refcount 4 mountedhere 0 flags () v_object 0xc6979528 ref 0 pages 10 lock type ufs: EXCL (count 1) by thread 0xc6cd9900 (pid 57765) with 1 pending ino 9213198, on dev da0s1g 0xc7327cc0: tag ufs, type VDIR usecount 1, writecount 0, refcount 3 mountedhere 0 flags () v_object 0xc73d439c ref 0 pages 2 lock type ufs: EXCL (count 1) by thread 0xc47f7780 (pid 897) ino 19661150, on dev da0s1g 0xc6447770: tag ufs, type VREG usecount 1, writecount 0, refcount 1 mountedhere 0 flags () lock type ufs: EXCL (count 1) by thread 0xc4a36a80 (pid 57759) ino 9213267, on dev da0s1g 0xc47d1dd0: tag null, type VDIR usecount 2, writecount 0, refcount 2 mountedhere 0 flags (VV_ROOT) v_object 0xc51f5d68 ref 0 pages 2 lock type ufs: EXCL (count 1) by thread 0xc5cd8d80 (pid 72603) vp=0xc47d1dd0, lowervp=0xc47d2000 0xc594f110: tag null, type VDIR usecount 2, writecount 0, refcount 2 mountedhere 0 flags () lock type ufs: EXCL (count 1) by thread 0xc4a36a80 (pid 57759) with 1 pending vp=0xc594f110, lowervp=0xc4766880 0xc7096660: tag null, type VDIR usecount 1, writecount 0, refcount 1 mountedhere 0 flags () lock type ufs: EXCL (count 1) by thread 0xc4a35600 (pid 78290) with 1 pending vp=0xc7096660, lowervp=0xc4ad8770 0xc6183660: tag null, type VDIR usecount 1, writecount 0, refcount 1 mountedhere 0 flags () lock type ufs: EXCL (count 1) by thread 0xc4a35300 (pid 78289) with 1 pending vp=0xc6183660, lowervp=0xc4ac5110 0xc6f2e220: tag null, type VDIR usecount 1, writecount 0, refcount 1 mountedhere 0 flags () lock type ufs: EXCL (count 1) by thread 0xc4e4a000 (pid 72715) with 1 pending vp=0xc6f2e220, lowervp=0xc4ac5330 -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ From lehmann at ans-netz.de Wed Oct 1 15:32:03 2008 From: lehmann at ans-netz.de (Oliver Lehmann) Date: Wed Oct 1 15:32:10 2008 Subject: system hangup - I'm lost In-Reply-To: <20081001051008.GA65754@icarus.home.lan> References: <20080929221408.54e6a03a.lehmann@ans-netz.de> <48E201DF.5090001@kkip.pl> <20080930104827.GB44675@icarus.home.lan> <20080930165534.f49f9f17.lehmann@ans-netz.de> <20080930214321.GA57024@icarus.home.lan> <20081001065309.3e7e108e.lehmann@ans-netz.de> <20081001051008.GA65754@icarus.home.lan> Message-ID: <20081001173159.c97d792d.lehmann@ans-netz.de> Jeremy Chadwick wrote: > On Wed, Oct 01, 2008 at 06:53:09AM +0200, Oliver Lehmann wrote: > > Because it is a Server Board it offers a lot of managing features and > > other nice things like serial console at bootup and system monitoring > > features... but all unsupported withn FreeBSDs software ;) > > Really? That's interesting, because Charles Sprickman told me that > there is no hardware monitoring information in the BIOS if you go in > there. Most motherboards provide that in the BIOS as a centralised > place above all else. You are right - I could have sworn that there was such an screen in the BIOS but all I can see is for setting up stuff like enabling eventlog and posting it through a modem connection and so on - server specific stuff - but no display screen for "health information"... So you where right ;) -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ From dev at null.cz Wed Oct 1 15:45:54 2008 From: dev at null.cz (Marek 'Buki' =?iso-8859-2?Q?Kozlovsk=FD?=) Date: Wed Oct 1 15:46:02 2008 Subject: Request for testing - top 3.8b1 in the base system In-Reply-To: <20080928115401.GU3210@k7.mavetju> References: <20080928054620.GA80250@k7.mavetju> <48DF4FCA.4070403@sh.cvut.cz> <20080928115401.GU3210@k7.mavetju> Message-ID: <20081001151716.GW2707@dev.null.cz> On Sun, Sep 28, 2008 at 09:54:01PM +1000, Edwin Groothuis wrote: > On Sun, Sep 28, 2008 at 11:35:06AM +0200, V??clav Haisman wrote: > > > to reproduce it (if possible). Thanks for your help! > > Is this 7.0+ only? I run 6.3 and I see the following when I start it: > > > > last pid: -1077944144; loa 0.52, 0.28, 0.26; > > up 11+15:31:33 11:33:05 > > 0 processes: > > CPU: 0.1% user, 0.6% nice, -0.7% system, -0.6% interrupt, -0.4% idle > > Kernel: 1 intr > > Mem: 235M Active, 458M Inact, 219M Wired, 42M Cache, 111M Buf, 39M Free > > Swap: 3000M Total, 181M Used, 2819M Free, 6% Inuse > > sysctlnametomib: No such file or directory > > > > And no processes. > > I didn't expect it not to work on 6.x, I will play around with it > tomorrow to see if it makes sense. Actually, I'm seeing the same behaviour on 7.0: last pid: 0943900; loa 0.98, 0.94, 0.57; up 7+23:09:54 17:13:22 0 processes: CPU: 19.7% user, 0.0% nice, 40.0% system, 0.0% interrupt, 40.3% idle Kernel: 1687 ctxsw, 14864 trap, 6 intr, 204 soft, 235 fork, 14526 flt, 11718 fr Mem: 78M Active, 690M Inact, 184M Wired, 29M Cache, 111M Buf, 11M Free Swap: 2048M Total, 136K Used, 2048M Free sysctl: Invalid argument PID USERNAME THR PRI NICE SIZE RES STATE FLG C TIME CPU COMMAND [no processes] |17:15:30|buki@hal9000:/home/buki/temp/3.8b1/usr.bin/top>uname -srmi FreeBSD 7.0-RELEASE-p2 i386 GENERIC > Edwin > > -- > Edwin Groothuis | Personal website: http://www.mavetju.org > edwin@mavetju.org | Weblog: http://www.mavetju.org/weblog/ Buki -- PGP public key: http://dev.null.cz/buki.asc /"\ \ / ASCII Ribbon Campaign X Against HTML & Outlook Mail / \ http://www.thebackrow.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20081001/99ed18f8/attachment.pgp From gpalmer at freebsd.org Wed Oct 1 16:48:57 2008 From: gpalmer at freebsd.org (Gary Palmer) Date: Wed Oct 1 16:49:04 2008 Subject: resource leak In-Reply-To: <20081001115046.GA20384@icarus.home.lan> References: <48E36204.5090108@earthlink.net> <20081001115046.GA20384@icarus.home.lan> Message-ID: <20081001164856.GA6478@in-addr.com> On Wed, Oct 01, 2008 at 04:50:46AM -0700, Jeremy Chadwick wrote: > On Wed, Oct 01, 2008 at 07:41:56AM -0400, Stephen Clark wrote: > > Hello List, > > > > I am running into a strange problem that points to a resource leak. The > > problem manifests itself after one of our remote systems has been up > > around 100 days. > > The symptom is that it appears no new processes can be spawned. If I try to > > ssh to the unit, I can see the 3-way tcp handshake and then no more traffic. > > Examining log files, like cron, etc show that when this happens no more entries > > are written into the cron log. The unit is acting as a firewall, router > > and vpn appliance these functions continue to work. We have a C > > application that is periodically started out of a shell script that > > reports various information about the system, it stops reporting, while > > vpns, ospf routing, and ipfilter firewalling continue to work and write > > into their logfiles. > > > > My question is how do I monitor the various resources in the system that could > > prevent the spawning of a new process? > > Periodically logging "ps -auxw" output to a file would be useful, as > ideally you'd gradually see the list get longer and longer over time; > it's possible you have many zombie processes as a result of a parent > which is not reaping its children (calling waitpid(2) or its friends). "ps alxw" may be of interest in addition to "ps auxw" as it displays what the processes are waiting on. It could conceivably be a problem of some kind at the filesystem level. I've seen situations before where a problem escalates to the point where "ls /" hangs, and at that point you're stuck with an unresponsive box. Regards, Gary From rwatson at FreeBSD.org Wed Oct 1 17:56:30 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Wed Oct 1 17:56:38 2008 Subject: resource leak In-Reply-To: <20081001164856.GA6478@in-addr.com> References: <48E36204.5090108@earthlink.net> <20081001115046.GA20384@icarus.home.lan> <20081001164856.GA6478@in-addr.com> Message-ID: On Wed, 1 Oct 2008, Gary Palmer wrote: >> Periodically logging "ps -auxw" output to a file would be useful, as >> ideally you'd gradually see the list get longer and longer over time; it's >> possible you have many zombie processes as a result of a parent which is >> not reaping its children (calling waitpid(2) or its friends). > > "ps alxw" may be of interest in addition to "ps auxw" as it displays what > the processes are waiting on. It could conceivably be a problem of some > kind at the filesystem level. I've seen situations before where a problem > escalates to the point where "ls /" hangs, and at that point you're stuck > with an unresponsive box. If you want an even greater level of detail than ps -l, you can use procstat -k to generate kernel stack traces for all user/kernel threads. Wait channels are very useful, but they only tell you what the code that invoked the wait thinks it is for, not how that code was reached. A classic example is waiting on an exhausted UMA zone -- you get a uma wait channel, but no indication of what subsystem performed the memory allocation... This required FreeBSD 7.1 and higher, however. (Obviously, the same can be done easily using DDB, but that's hard on a box without a serial console, and requires interrupting the flow of the operating system, compiling with DDB, etc). Robert N M Watson Computer Laboratory University of Cambridge From mike at sentex.net Wed Oct 1 18:06:38 2008 From: mike at sentex.net (Mike Tancsa) Date: Wed Oct 1 18:06:46 2008 Subject: [FreeBSD] Fix for ServerWorks HT1000 in upcoming 7.1? In-Reply-To: <20081001164001.GA81847@iib.unsam.edu.ar> References: <520894aa0809301434h68b94628x54ec08fd48785feb@mail.gmail.com> <200809302351.m8UNpjs7024916@lava.sentex.ca> <20081001164001.GA81847@iib.unsam.edu.ar> Message-ID: <200810011806.m91I6a4Z029695@lava.sentex.ca> At 12:40 PM 10/1/2008, Fernan Aguero wrote: >Thanks for the tip. > >Unfortunately, the PowerEdge SC1435 BIOS does not allow much >options here ... I can set the embedded SATA to 'ATA mode' >(corruption hell, tested with 7.1 BETA) or just turn it >'OFF' in which case the FreeBSD installer sees no disk >present. >This is on BIOS v1.1.2. A newer v1.4.4 is available and I'm >now researching how to update the BIOS to see if that helps. Wow, thats too bad. Hopefully a newer BIOS will let you put the controller in SATA mode. > > > > Start with > > > ftp://ftp.freebsd.org//pub/FreeBSD/releases/i386/ISO-IMAGES/7.1/7.1-BETA-i386-disc1.iso > >I've used the amd64 version ... don't know if that makes any >difference, though. It wont make a difference in terms of the SATA/PATA issue. However, once you get that fixes, you should be able to install the AMD64 image just fine. I would check the USB settings as well to make sure the "hand off mode" is disabled. ---Mike From fernan at iib.unsam.edu.ar Wed Oct 1 18:43:17 2008 From: fernan at iib.unsam.edu.ar (Fernan Aguero) Date: Wed Oct 1 18:43:26 2008 Subject: [FreeBSD] Fix for ServerWorks HT1000 in upcoming 7.1? In-Reply-To: <200809302351.m8UNpjs7024916@lava.sentex.ca> References: <520894aa0809301434h68b94628x54ec08fd48785feb@mail.gmail.com> <200809302351.m8UNpjs7024916@lava.sentex.ca> Message-ID: <20081001164001.GA81847@iib.unsam.edu.ar> > At 05:34 PM 9/30/2008, Fernan Aguero wrote: > >> I've been following the "HT1000 chipset errata saga" thread, and the >> commits by sos@ to CVS (around Jan 2008), but have not seen other more >> recent posts about this issue ... is it because it's already fixed and >> working fine for everyone? >> >> http://lists.freebsd.org/pipermail/freebsd-current/2008-March/084272.html > > Yes, we ran into this yesterday on a fresh install using the 7.1 beta CD as > it was set to PATA mode by accident. Also, on some earlier BIOS revs, we > had to turn off "enable USB legacy mode" as well as "EHCI handoff". By > default we set those to disabled as it seems to sometimes create a high > interrupt load on the USB bus if its enabled. Thanks for the tip. Unfortunately, the PowerEdge SC1435 BIOS does not allow much options here ... I can set the embedded SATA to 'ATA mode' (corruption hell, tested with 7.1 BETA) or just turn it 'OFF' in which case the FreeBSD installer sees no disk present. This is on BIOS v1.1.2. A newer v1.4.4 is available and I'm now researching how to update the BIOS to see if that helps. > If you forget to set the mode to SATA, the dmesg will look like > > Sep 30 13:37:08 dev2 kernel: ad4: DMA limited to UDMA33, device found > non-ATA66 cable > Sep 30 13:37:08 dev2 kernel: ad4: 152627MB at > ata2-master UDMA33 > > and you will indeed get corruption > > Turning onto normal SATA mode in the BIOS, you should see > > Sep 30 16:14:15 dev2 kernel: ad4: 152627MB at > ata2-master SATA150 > > ... And everything works great. > > Start with > ftp://ftp.freebsd.org//pub/FreeBSD/releases/i386/ISO-IMAGES/7.1/7.1-BETA-i386-disc1.iso I've used the amd64 version ... don't know if that makes any difference, though. Fernan From jhb at freebsd.org Wed Oct 1 19:19:31 2008 From: jhb at freebsd.org (John Baldwin) Date: Wed Oct 1 19:19:38 2008 Subject: [FreeBSD] Fix for ServerWorks HT1000 in upcoming 7.1? In-Reply-To: <520894aa0809301434h68b94628x54ec08fd48785feb@mail.gmail.com> References: <520894aa0809301434h68b94628x54ec08fd48785feb@mail.gmail.com> Message-ID: <200810011134.49795.jhb@freebsd.org> On Tuesday 30 September 2008 05:34:04 pm Fernan Aguero wrote: > Hi, > > I have a server (Dell PowerEdge SC1435, ServerWorks HT1000) on which > I'd like to try installing FreeBSD. I've already failed to make 7.0 > work on this box and was wondering if you have information about the > behavior of the upcoming 7.1 on this hardware. > > I've been following the "HT1000 chipset errata saga" thread, and the > commits by sos@ to CVS (around Jan 2008), but have not seen other more > recent posts about this issue ... is it because it's already fixed and > working fine for everyone? > > http://lists.freebsd.org/pipermail/freebsd-current/2007-December/081429.html > http://lists.freebsd.org/pipermail/freebsd-current/2008-March/084272.html > > Thanks in advance for any update on this, Try http://www.freebsd.org/~jhb/patches/ata_ht1000.patch -- John Baldwin From jrhett at netconsonance.com Wed Oct 1 19:37:35 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Wed Oct 1 19:37:43 2008 Subject: proposed change to support policy for FreeBSD Releases In-Reply-To: <44abdw9oeq.fsf@be-well.ilk.org> References: <40C58F46-D705-4BE0-8AE5-17D901EE381A@netconsonance.com> <44abdw9oeq.fsf@be-well.ilk.org> Message-ID: On Sep 25, 2008, at 9:32 AM, Lowell Gilbert wrote: > I'm not clear on how this helps. We don't know if there will be a > need to produce a 6.5 release, so there's no way to judge whether 6.4 > should be designated "final" or not. The only logical answer is to do > so, which leaves a substantial chance that there will end up being > more than one "final" release on the 6.x line. That's not a > particularly desirable situation. > > In fact, it's worse, because if 6.5 happens, it will probably be > because there were problems with 6.4 serious enough that we'd rather > people move to 6.5 anyway (at least for critical systems). You are exactly right. I am proposing that we stop trying to guess whether or not it is a final release. A release will be supported until the next release + N months (N is currently being debated I guess) or 24 months if there is no followup release. This effectively solves both of the problems you've very accurately named above. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From peter at wemm.org Wed Oct 1 19:45:09 2008 From: peter at wemm.org (Peter Wemm) Date: Wed Oct 1 19:45:16 2008 Subject: Would anybody port DragonFlyBSD's HAMMER fs to FreeBSD? In-Reply-To: <20081001071309.GA13616@icarus.home.lan> References: <78fb9d960809291927n60358006w7ef845e7cb40ed93@mail.gmail.com> <78fb9d960809301653o5cb09cefpf05eba0a9926b9fc@mail.gmail.com> <274267384.20080930223647@takeda.tk> <78fb9d960809302310s3f817505j6605420e451268e4@mail.gmail.com> <1031817271.20080930231836@takeda.tk> <78fb9d960809302329i5958966bh988c2531741e5c1@mail.gmail.com> <20081001071309.GA13616@icarus.home.lan> Message-ID: On Wed, Oct 1, 2008 at 12:13 AM, Jeremy Chadwick wrote: > On Wed, Oct 01, 2008 at 02:29:12PM +0800, lhmwzy wrote: >> That's it. >> Since we don't have the skill,what we can do is wait. >> >> Waiting is such a bad thing....... > > If this functionality is really something you want/need, you should > consider finding a kernel programmer who would be willing to port it, > for financial exchange (in English: you will be paying them $XX/hour > to port it to FreeBSD). > > This has happened in the past for some key features. Like I said, it > all depends on how much it matters to you. Another big consideration, is is 'HAMMER' sufficiently 'finished' to be worth trying this yet? Anybody attempting a port is going to have enough to worry about with the VFS/VM semantics differences, locking differences etc between the two different kernels. Having to worry about following a moving target as well would add unneeded difficulty. To be honest, I've not looked at the state of HAMMER. Is it still under active development or is it in a state where you could easily work from a snapshot of the source for months and not have to worry about getting too far out of sync, or be in need of functionality or bug fixes? That was one of the things that made the ZFS port possible. It was possible to take a known-good, "complete", working snapshot as a base and focus on getting it working in the FreeBSD kernel. It wasn't necessary to wonder (that much) if the bug you're currently fighting is a porting bug or an underlying ZFS bug. Of course, there's a lot more to it than that, but having a solid starting point is very important. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV "All of this is for nothing if we don't go to the stars" - JMS/B5 "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell From sclark46 at earthlink.net Wed Oct 1 20:36:51 2008 From: sclark46 at earthlink.net (Stephen Clark) Date: Wed Oct 1 20:36:59 2008 Subject: resource leak In-Reply-To: References: <48E36204.5090108@earthlink.net> <20081001115046.GA20384@icarus.home.lan> <20081001164856.GA6478@in-addr.com> Message-ID: <48E3DF5E.6040607@earthlink.net> Robert Watson wrote: > On Wed, 1 Oct 2008, Gary Palmer wrote: > >>> Periodically logging "ps -auxw" output to a file would be useful, as >>> ideally you'd gradually see the list get longer and longer over time; >>> it's possible you have many zombie processes as a result of a parent >>> which is not reaping its children (calling waitpid(2) or its friends). >> >> "ps alxw" may be of interest in addition to "ps auxw" as it displays >> what the processes are waiting on. It could conceivably be a problem >> of some kind at the filesystem level. I've seen situations before >> where a problem escalates to the point where "ls /" hangs, and at that >> point you're stuck with an unresponsive box. > > If you want an even greater level of detail than ps -l, you can use > procstat -k to generate kernel stack traces for all user/kernel > threads. Wait channels are very useful, but they only tell you what the > code that invoked the wait thinks it is for, not how that code was > reached. A classic example is waiting on an exhausted UMA zone -- you > get a uma wait channel, but no indication of what subsystem performed > the memory allocation... This required FreeBSD 7.1 and higher, > however. (Obviously, the same can be done easily using DDB, but that's > hard on a box without a serial console, and requires interrupting the > flow of the operating system, compiling with DDB, etc). > > Robert N M Watson > Computer Laboratory > University of Cambridge > A big part of problem is this seems to take about 100 days of uptime to occur. We have some inhouse test boxes but have never seen the problem, probably because non of them have been up more than about 45 days. The units in the field, of which there is about 300, are headless and none are physically close. When the boxes are rebooted there are no error messages in any of the log files, only the absence of information that would normally be logged by new processes that would be spawned. We are getting ready to install a patch that will try to gather more information. I thought about writing an app the would try to fork a child periodically and record in a log file if there was an error. But EAGAIN is nonspecific as to the real reason the fork failed. I was looking for some way to periodically log the resources that would cause the fork failure. procstat -k looks like it would have been a good candidate but unfortunately we are running 6.1. Thanks for the response. Steve -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) From wtf.jlaine at gmail.com Wed Oct 1 21:04:59 2008 From: wtf.jlaine at gmail.com (Jeff Laine) Date: Wed Oct 1 21:05:05 2008 Subject: Request for testing - top 3.8b1 in the base system In-Reply-To: <20080928054620.GA80250@k7.mavetju> References: <20080928054620.GA80250@k7.mavetju> Message-ID: <2b98f2f70810011337u6498a619n9b524feb847b49d9@mail.gmail.com> 2008/9/28 Edwin Groothuis : > I have made an update for the top(1) utility in the FreeBSD base > system to get it from the 3.5b12 version to the 3.8b1 version. > > I have tried them on the amd64 architecture on FreeBSD -current and > FreeBSD 7.0 and on the i386 architecture on FreeBSD 7.0. > > The big new features are a line upper part with kernel statistics > (context-switches, traps, interrupts, faults etc) and the FLG table > (if you window is big enough) > > Some features specific to FreeBSD (dual display (press m)), threaded > processes, and jails have been ported to 3.8b1. > > The biggest fix (AFAICT) is the TIME and CPU table for threaded > processes, which are now calculated properly. > > The new code can be found on > http://www.mavetju.org/~edwin/freebsd-top-3.8b1-A.tar.gz > Go to 3.8b1/usr.sbin/top and run "make" there to produce the binary, > then run it via "./top". > > Please report any issues with it (compile time, run time) and a way > to reproduce it (if possible). Thanks for your help! > > Edwin > > -- > Edwin Groothuis > edwin@freebsd.org > http://www.mavetju.org Hello. I have one issue, maybe not so important though. I've compiled top 3.8b1 on my 7.1-PRERELEASE and it looks like "t" hotkey (toggle displaying "top" process) don't work at all. (Sorry if somebody has pointed out that one already. I haven't read all thread so thoroughly. ) -- Best regards, Jeff. From 000.fbsd at quip.cz Wed Oct 1 22:25:38 2008 From: 000.fbsd at quip.cz (Miroslav Lachman) Date: Wed Oct 1 22:25:46 2008 Subject: Would anybody port DragonFlyBSD's HAMMER fs to FreeBSD? In-Reply-To: <78fb9d960810010015l14a98f56re49c9eb386305118@mail.gmail.com> References: <78fb9d960809291927n60358006w7ef845e7cb40ed93@mail.gmail.com> <78fb9d960809301653o5cb09cefpf05eba0a9926b9fc@mail.gmail.com> <274267384.20080930223647@takeda.tk> <78fb9d960809302310s3f817505j6605420e451268e4@mail.gmail.com> <1031817271.20080930231836@takeda.tk> <78fb9d960809302329i5958966bh988c2531741e5c1@mail.gmail.com> <20081001071309.GA13616@icarus.home.lan> <78fb9d960810010015l14a98f56re49c9eb386305118@mail.gmail.com> Message-ID: <48E3F900.8020702@quip.cz> lhmwzy wrote: > Yes,this is a way. > I would do as you said if I need to do so. > > 2008/10/1 Jeremy Chadwick : > >>On Wed, Oct 01, 2008 at 02:29:12PM +0800, lhmwzy wrote: >> >>>That's it. >>>Since we don't have the skill,what we can do is wait. >>> >>>Waiting is such a bad thing....... >> >>If this functionality is really something you want/need, you should >>consider finding a kernel programmer who would be willing to port it, >>for financial exchange (in English: you will be paying them $XX/hour >>to port it to FreeBSD). >> >>This has happened in the past for some key features. Like I said, it >>all depends on how much it matters to you. HAMMER seems good, but at this time, it is more important to finish ZFS integration in to FreeBSD. Fixing all known issues, more testing, wider audience and make it production ready. Not because ZFS is better, may be is worse - it does not metter. I think it is important to have one successful port finished than two filesystems in non-production state. FreeBSD is currently lag behind other operating systems in supported filesystems. UFS2 is insufficient for todays storage requirements. Once we have ZFS production ready, we can talk about another filesystems. I can't do any programming to port whatever filesystem, nor write patches. All I can do is testing and reporting - and I am doing it. I have some stresstests of ZFS. Currently I have one ZFS mount with 56 snapshots taken during heavy tasks like coping or removing large number of small files (mainly cp -R /usr/ports /tank/test/$i in loops plus taring / untaring tasks), some large files creation with dd on background etc. All is running fine on FreeBSD 7.0 amd64 with 4GB RAM and some kernel tunning. vm.kmem_size="1024M" vm.kmem_size_max="1024M" kern.maxvnodes="400000" vfs.zfs.prefetch_disable="1" vfs.zfs.arc_min="16M" vfs.zfs.arc_max="64M" There are 53202511 inodes on ZFS partition. Zpool was created over two slices of two disks (mirror): capacity operations bandwidth pool used avail read write read write ---------- ----- ----- ----- ----- ----- ----- tank 434G 10.5G 75 1.24K 618K 5.76M mirror 434G 10.5G 75 1.24K 618K 5.76M ad4s2 - - 13 328 918K 5.76M ad6s2 - - 16 326 1.09M 5.76M ---------- ----- ----- ----- ----- ----- ----- I have no crash of ZFS, but as I read in mailing lists, there are still some problems, so let it be fixed and settle down before porting another good filesystem. Just my ?0.02 Miroslav Lachman From dmarini at MIT.EDU Wed Oct 1 23:12:50 2008 From: dmarini at MIT.EDU (Davide Marini) Date: Wed Oct 1 23:12:58 2008 Subject: Anti-MDR1 antibody Message-ID: <20081001230927.GE3819@davide-desktop.tch.harvard.edu> Dear All: Has anybody tried the anti-MDR1 from Millipore, by any chance? http://www.millipore.com/catalogue/item/mab4161# I am looking for a reliable mouse anti-human antibody, targeting the extracellular epitope of P-glycoprotein. Any suggestion is extremely appreciated! Thank you in advance. Davide From freebsd-stable at pp.dyndns.biz Thu Oct 2 00:05:07 2008 From: freebsd-stable at pp.dyndns.biz (=?ISO-8859-1?Q?Morgan_Wesstr=F6m?=) Date: Thu Oct 2 00:05:14 2008 Subject: Anti-MDR1 antibody In-Reply-To: <20081001230927.GE3819@davide-desktop.tch.harvard.edu> References: <20081001230927.GE3819@davide-desktop.tch.harvard.edu> Message-ID: <48E40B71.2010303@pp.dyndns.biz> I'm really not into that anti-human movement and I think it's a pity that poor mouse has to suffer. I suggest you take three Valiums instead and call me in the morning... Davide Marini wrote: > Dear All: > > Has anybody tried the anti-MDR1 from Millipore, by any chance? > > > I am looking for a reliable mouse anti-human antibody, targeting > the extracellular epitope of P-glycoprotein. > > Any suggestion is extremely appreciated! > > Thank you in advance. > > Davide > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From dmarini at MIT.EDU Thu Oct 2 02:34:18 2008 From: dmarini at MIT.EDU (Davide Marini) Date: Thu Oct 2 02:34:26 2008 Subject: Anti-MDR1: Apologies Message-ID: <20081002023412.GB904@davide-laptop.myhome.westell.com> Dear All: My apologies for sending this message to the wrong mailing list. I am indeed on the freebsd-stable list, as I use this OS, but the message was mistakenly sent to this forum. Sorry for disturbing your work. Let me take this opportunity to thank the developers for such a superb operating system. Best Regards, Davide -- Davide M. Marini, Ph.D. Research Fellow, Department of Cardiology Children's Hospital Boston | Harvard Medical School Enders 1306, 320 Longwood Avenue, Boston, MA 02115 Research Associate, Department of Materials Science Massachusetts Institute of Technology | Biomolecular Materials Group 77 Massachusetts Avenue, Room 16-244 Cambridge, MA 02139 From ws at au.dyndns.ws Thu Oct 2 07:40:55 2008 From: ws at au.dyndns.ws (Wayne Sierke) Date: Thu Oct 2 07:41:04 2008 Subject: resource leak In-Reply-To: <48E3DF5E.6040607@earthlink.net> References: <48E36204.5090108@earthlink.net> <20081001115046.GA20384@icarus.home.lan> <20081001164856.GA6478@in-addr.com> <48E3DF5E.6040607@earthlink.net> Message-ID: <1222932325.2581.277.camel@predator-ii.buffyverse> On Wed, 2008-10-01 at 16:36 -0400, Stephen Clark wrote: > Robert Watson wrote: > > On Wed, 1 Oct 2008, Gary Palmer wrote: > > > >> "ps alxw" may be of interest in addition to "ps auxw" as it displays > >> what the processes are waiting on. It could conceivably be a problem > >> of some kind at the filesystem level. I've seen situations before > >> where a problem escalates to the point where "ls /" hangs, and at that > >> point you're stuck with an unresponsive box. > > > > If you want an even greater level of detail than ps -l, you can use > > procstat -k to generate kernel stack traces for all user/kernel > > threads. Wait channels are very useful, but they only tell you what the > > code that invoked the wait thinks it is for, not how that code was > > reached. A classic example is waiting on an exhausted UMA zone -- you > > get a uma wait channel, but no indication of what subsystem performed > > the memory allocation... This required FreeBSD 7.1 and higher, > > however. (Obviously, the same can be done easily using DDB, but that's > > hard on a box without a serial console, and requires interrupting the > > flow of the operating system, compiling with DDB, etc). > > > > Robert N M Watson > > Computer Laboratory > > University of Cambridge > > > A big part of problem is this seems to take about 100 days of uptime to occur. > We have some inhouse test boxes but have never seen the problem, probably > because non of them have been up more than about 45 days. The units in the > field, of which there is about 300, are headless and none are physically close. > > When the boxes are rebooted there are no error messages in any of the log files, > only the absence of information that would normally be logged by new processes > that would be spawned. We are getting ready to install a patch that will try to > gather more information. > > I thought about writing an app the would try to fork a child periodically and > record in a log file if there was an error. But EAGAIN is nonspecific as to the > real reason the fork failed. I was looking for some way to periodically log the > resources that would cause the fork failure. > > procstat -k looks like it would have been a good candidate but unfortunately we > are running 6.1. > > Thanks for the response. > Steve I have a VIA EPIA-based system that was rebooting and not leaving behind any diagnosable evidence that I could find. Attaching a serial console revealed a kernel-trap which was double-faulting as it went to write the kernel dump. I've not yet had the opportunity to investigate further except that out of desperation I threw in an additional 64M of RAM - all I had to hand - adding to its 256M and I haven't seen it fault again in the 37 days since (it would often stay up for less than a day before that). I wonder whether it would be worth your while running a bench unit with limited RAM, either physically or via the hw.physmem tunable. I would probably try to identify the amount of RAM that just allows it to run "normally", ideally subjecting it to a typical workload if possible. If it bombs after running for a reasonable length of time, add back a fraction of the unused memory and see if it then stays up proportionally longer which could be indicative of a memory starvation issue. If you can get it to bomb in the above scenario then you can probably get some insight into where it's failing. Having said that, I should point out that I've not actually used the above technique so I may well be overlooking something which might prevent it from being useful or indeed from "working" at all. Wayne From sergey.dyatko at gmail.com Thu Oct 2 07:59:18 2008 From: sergey.dyatko at gmail.com (Sergey V. Dyatko) Date: Thu Oct 2 07:59:25 2008 Subject: if_re is broken on RELENG_7 ? Message-ID: <20081002102600.45f407d2@notebook> Hi list, I have ASUS a6m laptop with integrated RTL8168/8111 PCI-E Gigabit Ethernet NIC, long time ago (7.0-CURRENT - 7.0-prerelease) I used it. Than I started to enjoy BCM43XX wi-fi adapter and now I recently decided to revert to the use of realtek adapter. But it doesn't work. I'm just not running a network card or at all does not work? some additional information: ifconfig shows such information, regardless of whether the cable is connected: %ifconfig re0 re0: flags=8802 metric 0 mtu 1500 options=389b ether 00:1a:92:ca:b3:bc media: Ethernet autoselect (10baseT/UTP ) status: no carrier [tiger@notebook]~%pciconf -lv | grep re0 -A 4 re0@pci0:2:0:0: class=0x020000 card=0x11f51043 chip=0x816810ec rev=0x01 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC' class = network subclass = ethernet dmesg output: http://tiger.byfly.by/files/dmesg.boot kernel config: http://tiger.byfly.by/files/tiger-asus-a6m p.s.: Excuse me for my English :) -- wbr, tiger From koitsu at FreeBSD.org Thu Oct 2 08:08:30 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Thu Oct 2 08:08:37 2008 Subject: if_re is broken on RELENG_7 ? In-Reply-To: <20081002102600.45f407d2@notebook> References: <20081002102600.45f407d2@notebook> Message-ID: <20081002080827.GA42696@icarus.home.lan> On Thu, Oct 02, 2008 at 10:26:00AM +0300, Sergey V. Dyatko wrote: > Hi list, > I have ASUS a6m laptop with integrated RTL8168/8111 PCI-E Gigabit > Ethernet NIC, long time ago (7.0-CURRENT - 7.0-prerelease) I used it. > Than I started to enjoy BCM43XX wi-fi adapter and now I recently > decided to revert to the use of realtek adapter. But it doesn't work. > I'm just not running a network card or at all does not work? > > some additional information: > ifconfig shows such information, regardless of whether the cable is > connected: > > %ifconfig re0 > re0: flags=8802 metric 0 mtu 1500 > options=389b > ether 00:1a:92:ca:b3:bc > media: Ethernet autoselect (10baseT/UTP ) > status: no carrier > > [tiger@notebook]~%pciconf -lv | grep re0 -A 4 > re0@pci0:2:0:0: class=0x020000 card=0x11f51043 chip=0x816810ec rev=0x01 > hdr=0x00 vendor = 'Realtek Semiconductor' > device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC' > class = network > subclass = ethernet > dmesg output: http://tiger.byfly.by/files/dmesg.boot > kernel config: http://tiger.byfly.by/files/tiger-asus-a6m > > p.s.: Excuse me for my English :) Looks like link isn't being established, and autoselect is resorting to 10BT/half. Can you provide pciconf -lv output? CC'ing PYUN Yong-Hyeon (surname Pyun), who helps maintain this driver. He might have some patches for you. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From pyunyh at gmail.com Thu Oct 2 08:46:29 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Thu Oct 2 08:46:37 2008 Subject: if_re is broken on RELENG_7 ? In-Reply-To: <20081002102600.45f407d2@notebook> References: <20081002102600.45f407d2@notebook> Message-ID: <20081002084425.GD67204@cdnetworks.co.kr> On Thu, Oct 02, 2008 at 10:26:00AM +0300, Sergey V. Dyatko wrote: > Hi list, > I have ASUS a6m laptop with integrated RTL8168/8111 PCI-E Gigabit > Ethernet NIC, long time ago (7.0-CURRENT - 7.0-prerelease) I used it. > Than I started to enjoy BCM43XX wi-fi adapter and now I recently > decided to revert to the use of realtek adapter. But it doesn't work. > I'm just not running a network card or at all does not work? > > some additional information: > ifconfig shows such information, regardless of whether the cable is > connected: > > %ifconfig re0 > re0: flags=8802 metric 0 mtu 1500 > options=389b > ether 00:1a:92:ca:b3:bc > media: Ethernet autoselect (10baseT/UTP ) > status: no carrier I don't see what's wrong in the output above. Because there is no "RUNNING" in flags field I guess you didn't up the interface. (e.g. either assign an IP address to the interface or run 'dhclient re0' if you want to get an IP address over DHCP). > > [tiger@notebook]~%pciconf -lv | grep re0 -A 4 > re0@pci0:2:0:0: class=0x020000 card=0x11f51043 chip=0x816810ec rev=0x01 > hdr=0x00 vendor = 'Realtek Semiconductor' > device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC' > class = network > subclass = ethernet > dmesg output: http://tiger.byfly.by/files/dmesg.boot > kernel config: http://tiger.byfly.by/files/tiger-asus-a6m > -- Regards, Pyun YongHyeon From sergey.dyatko at gmail.com Thu Oct 2 08:55:22 2008 From: sergey.dyatko at gmail.com (Sergey V. Dyatko) Date: Thu Oct 2 08:55:29 2008 Subject: if_re is broken on RELENG_7 ? In-Reply-To: <20081002080827.GA42696@icarus.home.lan> References: <20081002102600.45f407d2@notebook> <20081002080827.GA42696@icarus.home.lan> Message-ID: <20081002115515.6f6bfec2@notebook> ? Thu, 2 Oct 2008 01:08:27 -0700 Jeremy Chadwick wrote: > On Thu, Oct 02, 2008 at 10:26:00AM +0300, Sergey V. Dyatko wrote: > > Hi list, > > I have ASUS a6m laptop with integrated RTL8168/8111 PCI-E Gigabit > > Ethernet NIC, long time ago (7.0-CURRENT - 7.0-prerelease) I used > > it. Than I started to enjoy BCM43XX wi-fi adapter and now I recently > > decided to revert to the use of realtek adapter. But it doesn't > > work. I'm just not running a network card or at all does not work? > > > > some additional information: > > ifconfig shows such information, regardless of whether the cable is > > connected: > > > > %ifconfig re0 > > re0: flags=8802 metric 0 mtu 1500 > > options=389b > > ether 00:1a:92:ca:b3:bc > > media: Ethernet autoselect (10baseT/UTP ) > > status: no carrier > > > > [tiger@notebook]~%pciconf -lv | grep re0 -A 4 > > re0@pci0:2:0:0: class=0x020000 card=0x11f51043 chip=0x816810ec > > rev=0x01 hdr=0x00 vendor = 'Realtek Semiconductor' > > device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC' > > class = network > > subclass = ethernet > > dmesg output: http://tiger.byfly.by/files/dmesg.boot > > kernel config: http://tiger.byfly.by/files/tiger-asus-a6m > > > > p.s.: Excuse me for my English :) > > Looks like link isn't being established, and autoselect is resorting > to 10BT/half. > > Can you provide pciconf -lv output? > sure, http://tiger.byfly.by/files/pciconf.txt > CC'ing PYUN Yong-Hyeon (surname Pyun), who helps maintain this driver. > He might have some patches for you. > -- wbr, tiger From sergey.dyatko at gmail.com Thu Oct 2 09:02:04 2008 From: sergey.dyatko at gmail.com (Sergey V. Dyatko) Date: Thu Oct 2 09:02:12 2008 Subject: if_re is broken on RELENG_7 ? In-Reply-To: <20081002084425.GD67204@cdnetworks.co.kr> References: <20081002102600.45f407d2@notebook> <20081002084425.GD67204@cdnetworks.co.kr> Message-ID: <20081002120157.4e72b2f0@notebook> ? Thu, 2 Oct 2008 17:44:25 +0900 Pyun YongHyeon ?????: > On Thu, Oct 02, 2008 at 10:26:00AM +0300, Sergey V. Dyatko wrote: > > Hi list, > > I have ASUS a6m laptop with integrated RTL8168/8111 PCI-E Gigabit > > Ethernet NIC, long time ago (7.0-CURRENT - 7.0-prerelease) I used > > it. Than I started to enjoy BCM43XX wi-fi adapter and now I > > recently decided to revert to the use of realtek adapter. But it > > doesn't work. I'm just not running a network card or at all does > > not work? > > > > some additional information: > > ifconfig shows such information, regardless of whether the cable is > > connected: > > > > %ifconfig re0 > > re0: flags=8802 metric 0 mtu 1500 > > options=389b > > ether 00:1a:92:ca:b3:bc > > media: Ethernet autoselect (10baseT/UTP ) > > status: no carrier > > I don't see what's wrong in the output above. Because there is no > "RUNNING" in flags field I guess you didn't up the interface. > (e.g. either assign an IP address to the interface or run > 'dhclient re0' if you want to get an IP address over DHCP). > Hmm, after command 'ifconfig re0 up' status changed to 'active', media to '100baseTX ' and everything work fine (dhclient re0). What time have I had to type "up" explicitly to make it work since? On my desktop with age(4): without cable: age0: flags=8802 metric 0 mtu 1500 options=319b ether 00:1b:fc:d4:7d:b3 media: Ethernet autoselect (none) status: no carrier Now I'll plug cable into NIC: age0: flags=8802 metric 0 mtu 1500 options=319b ether 00:1b:fc:d4:7d:b3 media: Ethernet autoselect (100baseTX ) status: active in that case I haven't "RUNNING" in flags field too, that flag and flag 'UP' appeared after I assing IP to age0 age0: flags=8843 metric 0 mtu1500 options=319b ether 00:1b:fc:d4:7d:b3 inet 192.168.9.240 netmask 0xffffff00 broadcast 192.168.9.255 > > > > [tiger@notebook]~%pciconf -lv | grep re0 -A 4 > > re0@pci0:2:0:0: class=0x020000 card=0x11f51043 chip=0x816810ec > > rev=0x01 hdr=0x00 vendor = 'Realtek Semiconductor' > > device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC' > > class = network > > subclass = ethernet > > dmesg output: http://tiger.byfly.by/files/dmesg.boot > > kernel config: http://tiger.byfly.by/files/tiger-asus-a6m > > > -- -- ? ?????????, ?????? ????? ????????? ????????????? ?????-????? tiger@agava.com From olli at lurza.secnetix.de Thu Oct 2 09:07:40 2008 From: olli at lurza.secnetix.de (Oliver Fromme) Date: Thu Oct 2 09:07:48 2008 Subject: system hangup - I'm lost In-Reply-To: <20081001051008.GA65754@icarus.home.lan> Message-ID: <200810020907.m9297c6A039815@lurza.secnetix.de> Jeremy Chadwick wrote: > - Maxim MAX211ECA1, no idea but doesn't interest me Just for completeness, this is a serial port driver IC. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Gesch?ftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n- chen, HRB 125758, Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "[...] one observation we can make here is that Python makes an excellent pseudocoding language, with the wonderful attribute that it can actually be executed." -- Bruce Eckel From pyunyh at gmail.com Thu Oct 2 10:13:36 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Thu Oct 2 10:13:43 2008 Subject: if_re is broken on RELENG_7 ? In-Reply-To: <20081002120157.4e72b2f0@notebook> References: <20081002102600.45f407d2@notebook> <20081002084425.GD67204@cdnetworks.co.kr> <20081002120157.4e72b2f0@notebook> Message-ID: <20081002101133.GE67204@cdnetworks.co.kr> On Thu, Oct 02, 2008 at 12:01:57PM +0300, Sergey V. Dyatko wrote: > ? Thu, 2 Oct 2008 17:44:25 +0900 > Pyun YongHyeon ?????: > > > On Thu, Oct 02, 2008 at 10:26:00AM +0300, Sergey V. Dyatko wrote: > > > Hi list, > > > I have ASUS a6m laptop with integrated RTL8168/8111 PCI-E Gigabit > > > Ethernet NIC, long time ago (7.0-CURRENT - 7.0-prerelease) I used > > > it. Than I started to enjoy BCM43XX wi-fi adapter and now I > > > recently decided to revert to the use of realtek adapter. But it > > > doesn't work. I'm just not running a network card or at all does > > > not work? > > > > > > some additional information: > > > ifconfig shows such information, regardless of whether the cable is > > > connected: > > > > > > %ifconfig re0 > > > re0: flags=8802 metric 0 mtu 1500 > > > options=389b > > > ether 00:1a:92:ca:b3:bc > > > media: Ethernet autoselect (10baseT/UTP ) > > > status: no carrier > > > > I don't see what's wrong in the output above. Because there is no > > "RUNNING" in flags field I guess you didn't up the interface. > > (e.g. either assign an IP address to the interface or run > > 'dhclient re0' if you want to get an IP address over DHCP). > > > Hmm, after command 'ifconfig re0 up' status changed to 'active', > media to '100baseTX ' and everything work fine (dhclient > re0). What time have I had to type "up" explicitly to make it work > since? You don't have to, just configure re0 interface(e.g. rc.conf) > > On my desktop with age(4): > without cable: > age0: flags=8802 metric 0 mtu 1500 > options=319b > ether 00:1b:fc:d4:7d:b3 > media: Ethernet autoselect (none) > status: no carrier > Now I'll plug cable into NIC: > > age0: flags=8802 metric 0 mtu 1500 > options=319b > ether 00:1b:fc:d4:7d:b3 > media: Ethernet autoselect (100baseTX ) > status: active > in that case I haven't "RUNNING" in flags field too, that flag and flag > 'UP' appeared after I assing IP to age0 > > age0: flags=8843 metric 0 > mtu1500 > options=319b > ether 00:1b:fc:d4:7d:b3 > inet 192.168.9.240 netmask 0xffffff00 broadcast 192.168.9.255 That depends on PHY driver, rgephy(4) for re(4). Some PHY hardware requires special mode/initialization to establish a valid link with link partner. It seems that atphy(4) doesn't require any special PHY hardware configuration to establish a link. Also you can say the link status is valid only after interface up. Normally PHY drivers will have to restart auto-negotiation to choose the highest common denominator ability in interface up time. The established link after auto-negotiation may/may not agree on the speed/duplex of the link you've seen before the initialization. -- Regards, Pyun YongHyeon From rwatson at FreeBSD.org Thu Oct 2 12:08:22 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Thu Oct 2 12:08:29 2008 Subject: resource leak In-Reply-To: <48E3DF5E.6040607@earthlink.net> References: <48E36204.5090108@earthlink.net> <20081001115046.GA20384@icarus.home.lan> <20081001164856.GA6478@in-addr.com> <48E3DF5E.6040607@earthlink.net> Message-ID: On Wed, 1 Oct 2008, Stephen Clark wrote: > A big part of problem is this seems to take about 100 days of uptime to > occur. We have some inhouse test boxes but have never seen the problem, > probably because non of them have been up more than about 45 days. The units > in the field, of which there is about 300, are headless and none are > physically close. > > When the boxes are rebooted there are no error messages in any of the log > files, only the absence of information that would normally be logged by new > processes that would be spawned. We are getting ready to install a patch > that will try to gather more information. > > I thought about writing an app the would try to fork a child periodically > and record in a log file if there was an error. But EAGAIN is nonspecific as > to the real reason the fork failed. I was looking for some way to > periodically log the resources that would cause the fork failure. The narrowness of the UNIX errno space is, at times, fairly unhelpful. As far as I'm aware, the two main causes of EAGAIN out of fork() are an exhaustion of maxprocs or an exhaustion of per-user process limits. This suggests one or more run-away applications or services, or a gradual leak of processes from a service (perhaps a failure to GC dead children, or a gradual increase but never decrease of worker processes?). Robert N M Watson Computer Laboratory University of Cambridge > > procstat -k looks like it would have been a good candidate but unfortunately > we > are running 6.1. > > Thanks for the response. > Steve > > -- > > "They that give up essential liberty to obtain temporary safety, > deserve neither liberty nor safety." (Ben Franklin) > > "The course of history shows that as a government grows, liberty > decreases." (Thomas Jefferson) > > > From ben at altesco.nl Thu Oct 2 13:30:52 2008 From: ben at altesco.nl (Ben Stuyts) Date: Thu Oct 2 13:30:59 2008 Subject: recommended setup for amd64 7-STABLE with ZFS, Samba 3.2 and possibly ACLs? In-Reply-To: <20081001101227.GA17912@icarus.home.lan> References: <20080930100848.GA9193@intserv.int1.b.intern> <20080930104605.GA44675@icarus.home.lan> <01EBDE48-7CEE-4A50-B4F9-C4D5BCFA18BD@altesco.nl> <20081001101227.GA17912@icarus.home.lan> Message-ID: <8C93174F-EC03-4775-A919-6CDE2AE80D9F@altesco.nl> On 1 okt 2008, at 12:12, Jeremy Chadwick wrote: > On Wed, Oct 01, 2008 at 10:42:32AM +0200, Ben Stuyts wrote: >> I had to disable mmap access in dovecot, or it would coredump >> periodically. (mmap_disable = yes in dovecot.conf) > > Have you tried re-enabling mmap in dovecot on a system with a kernel > build after those dates? It's been running for a day now wit mmap enabled, and it works fine now. Again thanks for pointing this out. Ben From joao at matik.com.br Thu Oct 2 14:16:32 2008 From: joao at matik.com.br (JoaoBR) Date: Thu Oct 2 14:16:40 2008 Subject: usb data xfer problem with to/from nokia smartphones Message-ID: <200810021052.17161.joao@matik.com.br> I have difficulties transferring data from or to nokia smartphones in mass storage mode, specially nokia N80 and N95. The files are coming with missing parts, accessing a photo which s stored ont the phone is beeing seen cut somewhere in half, mp3 files are transferred but there are missing parts within, same with other binaries from the same computer (dual boot) with windows xp and fedora 8 txferring the exact same file the thing runs fine happens on i386 and amd64 some idea what might be wrong? -- Jo?o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From lehmann at ans-netz.de Thu Oct 2 16:51:12 2008 From: lehmann at ans-netz.de (Oliver Lehmann) Date: Thu Oct 2 16:51:23 2008 Subject: system hangup - I'm lost In-Reply-To: <20081001172943.99e9d494.lehmann@ans-netz.de> References: <20080929221408.54e6a03a.lehmann@ans-netz.de> <20081001172943.99e9d494.lehmann@ans-netz.de> Message-ID: <20081002185106.a1183896.lehmann@ans-netz.de> Oliver Lehmann wrote: > Hi, > > today I'd a crash again - I was not able to get a crash dump (thought a > "panic" at the end of the kdb would do it but didn't - should have called > dumpon before ;)) - so here now the information I was able to retrieve: > > Ok, what I've got so far is wrinting stuff out to the console when the > system hangs up: > > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 2, size: 4096 > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 2, size: 4096 > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 2, size: 4096 > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 2, size: 4096 > ... > > and now the debugger stuff: > > [snipped] > So.. no idea? anyone? -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ From jonc at chen.org.nz Thu Oct 2 18:21:47 2008 From: jonc at chen.org.nz (Jonathan Chen) Date: Thu Oct 2 18:21:54 2008 Subject: ipfw: install_state: entry already present, done Message-ID: <20081002180432.GA34898@osiris.chen.org.nz> Hi, I've just updated my 7-STABLE box to 7.1-PRERELEASE, and I'm seeing a quite a few ipfw kernel messages: ipfw: install_state: entry already present, done What is this mean? Has some regression occurred with ipfw? Cheers. -- Jonathan Chen ---------------------------------------------------------------------- Do not take life too seriously. You will never get out of it alive. From jhb at freebsd.org Thu Oct 2 18:30:42 2008 From: jhb at freebsd.org (John Baldwin) Date: Thu Oct 2 18:30:51 2008 Subject: system hangup - I'm lost In-Reply-To: <20081001172943.99e9d494.lehmann@ans-netz.de> References: <20080929221408.54e6a03a.lehmann@ans-netz.de> <20081001172943.99e9d494.lehmann@ans-netz.de> Message-ID: <200810021311.48127.jhb@freebsd.org> On Wednesday 01 October 2008 11:29:43 am Oliver Lehmann wrote: > Hi, > > today I'd a crash again - I was not able to get a crash dump (thought a > "panic" at the end of the kdb would do it but didn't - should have called > dumpon before ;)) - so here now the information I was able to retrieve: > > Ok, what I've got so far is wrinting stuff out to the console when the > system hangs up: > > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 2, size: 4096 > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 2, size: 4096 > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 2, size: 4096 > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 2, size: 4096 Sounds like your disk has died, or perhaps the controller is hung and not completing disk I/O requests anymore. -- John Baldwin From lehmann at ans-netz.de Thu Oct 2 20:07:20 2008 From: lehmann at ans-netz.de (Oliver Lehmann) Date: Thu Oct 2 20:07:27 2008 Subject: system hangup - I'm lost In-Reply-To: <200810021311.48127.jhb@freebsd.org> References: <20080929221408.54e6a03a.lehmann@ans-netz.de> <20081001172943.99e9d494.lehmann@ans-netz.de> <200810021311.48127.jhb@freebsd.org> Message-ID: <20081002220714.2141f8f4.lehmann@ans-netz.de> John Baldwin wrote: > Sounds like your disk has died, or perhaps the controller is hung and not > completing disk I/O requests anymore. Hm - the 3ware eventlog does not shed any light on this - no events occured. So I can just guess that the controller and the disks are fine (I had once a hard failing disk and the controller detected it correctly) Do you have an idea how to debug this further? -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ From torfinn.ingolfsen at broadpark.no Thu Oct 2 20:25:45 2008 From: torfinn.ingolfsen at broadpark.no (Torfinn Ingolfsen) Date: Thu Oct 2 20:25:53 2008 Subject: FreeBSD 6.5-prerelease and if_re - patches needed? In-Reply-To: <20080922021022.GC26294@cdnetworks.co.kr> References: <20080921215704.eca7300b.torfinn.ingolfsen@broadpark.no> <20080922021022.GC26294@cdnetworks.co.kr> Message-ID: <20081002222542.849d5481.torfinn.ingolfsen@broadpark.no> On Mon, 22 Sep 2008 11:10:23 +0900 Pyun YongHyeon wrote: > Due to lack of time and energy the change made in HEAD wasn't MFCed > to RELENG_6 so you may still need some patch. stable/7 should have > no such problems though. Does anybody happen to know which patch? > Maybe the issue you're seeing comes from misuse of bus_dma(9) which > was corrected in stable/7. But not MFC'ed to RELENG_6 I guess? Is therer a patch for RELENG_6 somewhere? -- Regards, Torfinn Ingolfsen From bruce at cran.org.uk Thu Oct 2 20:58:46 2008 From: bruce at cran.org.uk (Bruce Cran) Date: Thu Oct 2 20:58:54 2008 Subject: pf rules not being loaded during boot on 7.1-PRERELEASE Message-ID: <48E535D3.8000805@cran.org.uk> I recently upgraded my i386 router from 7.0 to 7.1-PRERELEASE. I rebooted it today but despite pf_enable="YES" being in /etc/rc.conf no rules got loaded during boot, despite pf itself having been enabled: router# pfctl -s rules router# pfctl -e -f /etc/pf.conf pfctl: pf already enabled [connection is closed due to new rules being loaded] router# pfctl -s rules scrub in all fragment reassemble [... lots of rules listed] Has anyone else seen this problem, or have I just missed something that's changed between 7.0 and 7.1 in the way pf works? -- Bruce Cran From Ron.Wingfield at Archaxis.net Thu Oct 2 22:19:04 2008 From: Ron.Wingfield at Archaxis.net (Ron Wingfield) Date: Thu Oct 2 22:19:10 2008 Subject: What has happened to the FreeBSD Forums? Message-ID: <48E54264.9050203@Archaxis.net> My apologies in advance if this is an inappropriate "list question", but . . . What has happened to the FreeBSD Forum at [1]"http://www.freebsdforums.com/forums/". I am/was an infrequent user/contributor to the forum . . .haven't been there in months, but WOW! what has happened to the moderation. Why is there so much filth and pornography posted there now? The site server response is also abysmal. Thanks for any info., Ron W. [2]Ron.Wingfield@Archaxis.net 501-920-7860 cell (best way) 501-228-4798 home References 1. http://www.freebsdforums.com/forums/ 2. mailto:Ron.Wingfield@Archaxis.net From freebsd-stable at bengrimm.net Thu Oct 2 22:23:01 2008 From: freebsd-stable at bengrimm.net (Ben C. O. Grimm) Date: Thu Oct 2 22:23:08 2008 Subject: What has happened to the FreeBSD Forums? In-Reply-To: <48E54264.9050203@Archaxis.net> References: <48E54264.9050203@Archaxis.net> Message-ID: <48E549A5.7050305@bengrimm.net> Ron Wingfield wrote: > My apologies in advance if this is an inappropriate "list question", > but . . . > What has happened to the FreeBSD Forum at > [1]"http://www.freebsdforums.com/forums/". I am/was an infrequent > user/contributor to the forum . . .haven't been there in months, but > WOW! what has happened to the moderation. Why is there so much > filth and pornography posted there now? The forums were abandoned. Everyone moved to http://www.daemonforums.org/ From cpghost at cordula.ws Thu Oct 2 22:50:10 2008 From: cpghost at cordula.ws (cpghost) Date: Thu Oct 2 22:50:17 2008 Subject: system hangup - I'm lost In-Reply-To: <20081002185106.a1183896.lehmann@ans-netz.de> References: <20080929221408.54e6a03a.lehmann@ans-netz.de> <20081001172943.99e9d494.lehmann@ans-netz.de> <20081002185106.a1183896.lehmann@ans-netz.de> Message-ID: <20081002225036.GC2539@phenom.cordula.ws> On Thu, Oct 02, 2008 at 06:51:06PM +0200, Oliver Lehmann wrote: > > today I'd a crash again - I was not able to get a crash dump (thought a > > "panic" at the end of the kdb would do it but didn't - should have called > > dumpon before ;)) - so here now the information I was able to retrieve: > > > > Ok, what I've got so far is wrinting stuff out to the console when the > > system hangs up: > > > > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 2, size: 4096 > > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 2, size: 4096 > > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 2, size: 4096 > > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 2, size: 4096 > > ... > > > > and now the debugger stuff: > > > > [snipped] > > > > So.. no idea? anyone? If it's PATA, check the cabling, then check it again, and just to make sure, replace the cable even if the system used to work flawlessly in the past. I've had this on a few servers, but replacing the cables always fixed the problem for me. Oh, btw, you can reproduce this exact behavior on diskless workstations with an NFS-mounted swap. IIRC, it even happened on VERY slow hardware with GBDE or GELI-encrypted swap partitions; but I'm not 100% sure it was due to slowness (it could have been a bad cabling issue as well). > -- > Oliver Lehmann > http://www.pofo.de/ > http://wishlist.ans-netz.de/ -cpghost. -- Cordula's Web. http://www.cordula.ws/ From fjwcash at gmail.com Thu Oct 2 23:34:52 2008 From: fjwcash at gmail.com (Freddie Cash) Date: Thu Oct 2 23:34:58 2008 Subject: What has happened to the FreeBSD Forums? In-Reply-To: <48E54264.9050203@Archaxis.net> References: <48E54264.9050203@Archaxis.net> Message-ID: <200810021634.46398.fjwcash@gmail.com> On October 2, 2008 02:51 pm Ron Wingfield wrote: > My apologies in advance if this is an inappropriate "list question", > but . . . > What has happened to the FreeBSD Forum at > [1]"http://www.freebsdforums.com/forums/". I am/was an infrequent > user/contributor to the forum . . .haven't been there in months, but > WOW! what has happened to the moderation. Why is there so much > filth and pornography posted there now? > The site server response is also abysmal. > Thanks for any info., > Ron W. The forums admin disappeared. We lowly moderators (there were only two of us) had no ability to change anything in the forum setup. We did the best we could for as long as we could to delete the spam entries every day. Several of the users joined together to start a new forum, with multiple admins, and better anti-spam setup. freebsdforums/bsdforums is all but dead. http://www.daemonforums.org is where we all hang out now. -- Freddie Cash fjwcash@gmail.com From andrew at modulus.org Fri Oct 3 05:27:49 2008 From: andrew at modulus.org (Andrew Snow) Date: Fri Oct 3 05:27:56 2008 Subject: trying to track down UFS "dup alloc" message on iSCSI Message-ID: <48E5AD16.5000101@modulus.org> I am playing with an iSCSI device on FreeBSD client running UFS2 on the device over a LAN. Everything works well until I reboot the iSCSI server - the client pauses for a minute or so then continues working after iSCSI server comes back. No I/O errors are reported. Everything seems to work fine for a little while! But shortly afterwards, I get a panic with the message panic: ffs_valloc: dup alloc It seems related to the length of the delay the iSCSI device is paused - restarting the iSCSI target daemon process doesn't cause the problem but rebooting the whole target box does cause it. 1. Could this be related to the patch Matt Dillon created years ago which I found here? http://leaf.dragonflybsd.org/mailarchive/bugs/2005-01/msg00093.html 2. Can anyone think of any other reason this might happen? I know I am stretching UFS to the limits here, expecting it to pause and restart after more than a minute of locked disk :-) However, since all I/O eventually complete successfully and no errors are reported, I find it suspicious. Cheers - Andrew ps. running latest iSCSI code 2.1 on latest 7-STABLE box. From danny at cs.huji.ac.il Fri Oct 3 08:00:45 2008 From: danny at cs.huji.ac.il (Danny Braniss) Date: Fri Oct 3 08:01:03 2008 Subject: bad NFS/UDP performance In-Reply-To: References: <20080926081806.GA19055@icarus.home.lan> <20080926095230.GA20789@icarus.home.lan> Message-ID: > > it more difficult than I expected. > > for one, the kernel date was missleading, the actual source update is the key, so > > the window of changes is now 28/July to 19/August. I have the diffs, but nothing > > yet seems relevant. > > > > on the other hand, I tried NFS/TCP, and there things seem ok, ie the 'good' and the 'bad' > > give the same throughput, which seem to point to UDP changes ... > > Can you post the network-numbers? so I ran some more test, these are for writes IO: server is a NetApp: kernel from 18/08/08 00:00:0 : /----- UDP ----//---- TCP -------/ 1*512 38528 0.19s 83.50MB 0.20s 80.82MB/s 2*512 19264 0.21s 76.83MB 0.21s 77.57MB/s 4*512 9632 0.19s 85.51MB 0.22s 73.13MB/s 8*512 4816 0.19s 83.76MB 0.21s 75.84MB/s 16*512 2408 0.19s 83.99MB 0.21s 77.18MB/s 32*512 1204 0.19s 84.45MB 0.22s 71.79MB/s 64*512 602 0.20s 79.98MB 0.20s 78.44MB/s 128*512 301 0.18s 86.51MB 0.22s 71.53MB/s 256*512 150 0.19s 82.83MB 0.20s 78.86MB/s 512*512 75 0.19s 82.77MB 0.21s 76.39MB/s 1024*512 37 0.19s 85.62MB 0.21s 76.64MB/s 2048*512 18 0.21s 77.72MB 0.20s 80.30MB/s 4096*512 9 0.26s 61.06MB 0.30s 53.79MB/s 8192*512 4 0.83s 19.20MB 0.41s 39.12MB/s 16384*512 2 0.84s 19.01MB 0.41s 39.03MB/s 32768*512 1 0.82s 19.59MB 0.39s 40.89MB/s kernel from 19/08/08 00:00:00: 1*512 38528 0.45s 35.59MB 0.20s 81.43MB/s 2*512 19264 0.45s 35.56MB 0.20s 79.24MB/s 4*512 9632 0.49s 32.66MB 0.22s 73.72MB/s 8*512 4816 0.47s 34.06MB 0.21s 75.52MB/s 16*512 2408 0.53s 30.16MB 0.22s 72.58MB/s 32*512 1204 0.31s 51.68MB 0.40s 40.14MB/s 64*512 602 0.43s 37.23MB 0.25s 63.57MB/s 128*512 301 0.51s 31.39MB 0.26s 62.70MB/s 256*512 150 0.47s 34.02MB 0.23s 69.06MB/s 512*512 75 0.47s 34.01MB 0.23s 70.52MB/s 1024*512 37 0.53s 30.12MB 0.22s 73.01MB/s 2048*512 18 0.55s 29.07MB 0.23s 70.64MB/s 4096*512 9 0.46s 34.69MB 0.21s 75.92MB/s 8192*512 4 0.81s 19.66MB 0.43s 36.89MB/s 16384*512 2 0.80s 19.99MB 0.40s 40.29MB/s 32768*512 1 1.11s 14.41MB 0.38s 42.56MB/s From shoesoft at gmx.net Fri Oct 3 08:03:18 2008 From: shoesoft at gmx.net (Stefan Ehmann) Date: Fri Oct 3 08:03:26 2008 Subject: top/ps CPU percentage broken on 7.1-PRERELEASE? Message-ID: <200810031003.14400.shoesoft@gmx.net> The CPU % displayed by top/ps for single processes seem to be broken here. E.g. for a simple shell loop: top starts displaying around 20% for bash. Within some seconds it converges to 0%. ps values seem to be consistent with top. The value in the time column seems to be correct. On every refresh it increases by 2s. last pid: 19353; load averages: 0.99, 0.90, 0.76 up 0+00:37:29 09:07:00 119 processes: 2 running, 114 sleeping, 1 stopped, 2 zombie CPU: 98.5% user, 0.0% nice, 1.1% system, 0.4% interrupt, 0.0% idle Mem: 376M Active, 407M Inact, 144M Wired, 47M Cache, 110M Buf, 13M Free Swap: 1280M Total, 1280M Free PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND 19352 stefan 1 99 0 4432K 2080K RUN 0:03 15.48% bash All other process are using 0% CPU. I did a buildworld/kernel yesterday to be sure everything is in sync. I have CURRENT on a different hard disk. Haven't seen the problem there. Are there any relevant fixes that weren't MFCed? Does anyone else see this? This is a single CPU i386 machine. -- Stefan From rwatson at FreeBSD.org Fri Oct 3 08:15:02 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Fri Oct 3 08:15:08 2008 Subject: bad NFS/UDP performance In-Reply-To: References: <20080926081806.GA19055@icarus.home.lan> <20080926095230.GA20789@icarus.home.lan> Message-ID: On Fri, 3 Oct 2008, Danny Braniss wrote: >>> it more difficult than I expected. >>> for one, the kernel date was missleading, the actual source update is the key, so >>> the window of changes is now 28/July to 19/August. I have the diffs, but nothing >>> yet seems relevant. >>> >>> on the other hand, I tried NFS/TCP, and there things seem ok, ie the >>> 'good' and the 'bad' give the same throughput, which seem to point to UDP >>> changes ... >> >> Can you post the network-numbers? > so I ran some more test, these are for writes IO: OK, so it looks like this was almost certainly the rwlock change. What happens if you pretty much universally substitute the following in udp_usrreq.c: Currently Change to --------- --------- INP_RLOCK INP_WLOCK INP_RUNLOCK INP_WUNLOCK INP_RLOCK_ASSERT INP_WLOCK_ASSERT Robert N M Watson Computer Laboratory University of Cambridge > > server is a NetApp: > > kernel from 18/08/08 00:00:0 : > /----- UDP ----//---- TCP -------/ > 1*512 38528 0.19s 83.50MB 0.20s 80.82MB/s > 2*512 19264 0.21s 76.83MB 0.21s 77.57MB/s > 4*512 9632 0.19s 85.51MB 0.22s 73.13MB/s > 8*512 4816 0.19s 83.76MB 0.21s 75.84MB/s > 16*512 2408 0.19s 83.99MB 0.21s 77.18MB/s > 32*512 1204 0.19s 84.45MB 0.22s 71.79MB/s > 64*512 602 0.20s 79.98MB 0.20s 78.44MB/s > 128*512 301 0.18s 86.51MB 0.22s 71.53MB/s > 256*512 150 0.19s 82.83MB 0.20s 78.86MB/s > 512*512 75 0.19s 82.77MB 0.21s 76.39MB/s > 1024*512 37 0.19s 85.62MB 0.21s 76.64MB/s > 2048*512 18 0.21s 77.72MB 0.20s 80.30MB/s > 4096*512 9 0.26s 61.06MB 0.30s 53.79MB/s > 8192*512 4 0.83s 19.20MB 0.41s 39.12MB/s > 16384*512 2 0.84s 19.01MB 0.41s 39.03MB/s > 32768*512 1 0.82s 19.59MB 0.39s 40.89MB/s > > kernel from 19/08/08 00:00:00: > 1*512 38528 0.45s 35.59MB 0.20s 81.43MB/s > 2*512 19264 0.45s 35.56MB 0.20s 79.24MB/s > 4*512 9632 0.49s 32.66MB 0.22s 73.72MB/s > 8*512 4816 0.47s 34.06MB 0.21s 75.52MB/s > 16*512 2408 0.53s 30.16MB 0.22s 72.58MB/s > 32*512 1204 0.31s 51.68MB 0.40s 40.14MB/s > 64*512 602 0.43s 37.23MB 0.25s 63.57MB/s > 128*512 301 0.51s 31.39MB 0.26s 62.70MB/s > 256*512 150 0.47s 34.02MB 0.23s 69.06MB/s > 512*512 75 0.47s 34.01MB 0.23s 70.52MB/s > 1024*512 37 0.53s 30.12MB 0.22s 73.01MB/s > 2048*512 18 0.55s 29.07MB 0.23s 70.64MB/s > 4096*512 9 0.46s 34.69MB 0.21s 75.92MB/s > 8192*512 4 0.81s 19.66MB 0.43s 36.89MB/s > 16384*512 2 0.80s 19.99MB 0.40s 40.29MB/s > 32768*512 1 1.11s 14.41MB 0.38s 42.56MB/s > > > > > From pyunyh at gmail.com Fri Oct 3 08:36:49 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Fri Oct 3 08:36:57 2008 Subject: FreeBSD 6.5-prerelease and if_re - patches needed? In-Reply-To: <20081002222542.849d5481.torfinn.ingolfsen@broadpark.no> References: <20080921215704.eca7300b.torfinn.ingolfsen@broadpark.no> <20080922021022.GC26294@cdnetworks.co.kr> <20081002222542.849d5481.torfinn.ingolfsen@broadpark.no> Message-ID: <20081003083443.GD71518@cdnetworks.co.kr> On Thu, Oct 02, 2008 at 10:25:42PM +0200, Torfinn Ingolfsen wrote: > On Mon, 22 Sep 2008 11:10:23 +0900 > Pyun YongHyeon wrote: > > > Due to lack of time and energy the change made in HEAD wasn't MFCed > > to RELENG_6 so you may still need some patch. stable/7 should have > > no such problems though. > > Does anybody happen to know which patch? > > > Maybe the issue you're seeing comes from misuse of bus_dma(9) which > > was corrected in stable/7. > > But not MFC'ed to RELENG_6 I guess? > Is therer a patch for RELENG_6 somewhere? I couldn't find spare time to regenerate patches for RELENG_6. Sorry. Maybe you can use if_re.c/if_rlreg.h in RELENG_7 with minor modification. -- Regards, Pyun YongHyeon From danny at cs.huji.ac.il Fri Oct 3 09:02:46 2008 From: danny at cs.huji.ac.il (Danny Braniss) Date: Fri Oct 3 09:02:58 2008 Subject: bad NFS/UDP performance In-Reply-To: References: <20080926081806.GA19055@icarus.home.lan> <20080926095230.GA20789@icarus.home.lan> Message-ID: > > On Fri, 3 Oct 2008, Danny Braniss wrote: > > >>> it more difficult than I expected. > >>> for one, the kernel date was missleading, the actual source update is the key, so > >>> the window of changes is now 28/July to 19/August. I have the diffs, but nothing > >>> yet seems relevant. > >>> > >>> on the other hand, I tried NFS/TCP, and there things seem ok, ie the > >>> 'good' and the 'bad' give the same throughput, which seem to point to UDP > >>> changes ... > >> > >> Can you post the network-numbers? > > so I ran some more test, these are for writes IO: > > OK, so it looks like this was almost certainly the rwlock change. What > happens if you pretty much universally substitute the following in > udp_usrreq.c: > > Currently Change to > --------- --------- > INP_RLOCK INP_WLOCK > INP_RUNLOCK INP_WUNLOCK > INP_RLOCK_ASSERT INP_WLOCK_ASSERT > I guess you were almost certainly correct :-) I did the global subst. on the udp_usrreq.c from 19/08, __FBSDID("$FreeBSD: src/sys/netinet/udp_usrreq.c,v 1.218.2.3 2008/08/18 23:00:41 bz Exp $"); and now udp is fine again! danny > Robert N M Watson > Computer Laboratory > University of Cambridge > > > > > server is a NetApp: > > > > kernel from 18/08/08 00:00:0 : > > /----- UDP ----//---- TCP -------/ > > 1*512 38528 0.19s 83.50MB 0.20s 80.82MB/s > > 2*512 19264 0.21s 76.83MB 0.21s 77.57MB/s > > 4*512 9632 0.19s 85.51MB 0.22s 73.13MB/s > > 8*512 4816 0.19s 83.76MB 0.21s 75.84MB/s > > 16*512 2408 0.19s 83.99MB 0.21s 77.18MB/s > > 32*512 1204 0.19s 84.45MB 0.22s 71.79MB/s > > 64*512 602 0.20s 79.98MB 0.20s 78.44MB/s > > 128*512 301 0.18s 86.51MB 0.22s 71.53MB/s > > 256*512 150 0.19s 82.83MB 0.20s 78.86MB/s > > 512*512 75 0.19s 82.77MB 0.21s 76.39MB/s > > 1024*512 37 0.19s 85.62MB 0.21s 76.64MB/s > > 2048*512 18 0.21s 77.72MB 0.20s 80.30MB/s > > 4096*512 9 0.26s 61.06MB 0.30s 53.79MB/s > > 8192*512 4 0.83s 19.20MB 0.41s 39.12MB/s > > 16384*512 2 0.84s 19.01MB 0.41s 39.03MB/s > > 32768*512 1 0.82s 19.59MB 0.39s 40.89MB/s > > > > kernel from 19/08/08 00:00:00: > > 1*512 38528 0.45s 35.59MB 0.20s 81.43MB/s > > 2*512 19264 0.45s 35.56MB 0.20s 79.24MB/s > > 4*512 9632 0.49s 32.66MB 0.22s 73.72MB/s > > 8*512 4816 0.47s 34.06MB 0.21s 75.52MB/s > > 16*512 2408 0.53s 30.16MB 0.22s 72.58MB/s > > 32*512 1204 0.31s 51.68MB 0.40s 40.14MB/s > > 64*512 602 0.43s 37.23MB 0.25s 63.57MB/s > > 128*512 301 0.51s 31.39MB 0.26s 62.70MB/s > > 256*512 150 0.47s 34.02MB 0.23s 69.06MB/s > > 512*512 75 0.47s 34.01MB 0.23s 70.52MB/s > > 1024*512 37 0.53s 30.12MB 0.22s 73.01MB/s > > 2048*512 18 0.55s 29.07MB 0.23s 70.64MB/s > > 4096*512 9 0.46s 34.69MB 0.21s 75.92MB/s > > 8192*512 4 0.81s 19.66MB 0.43s 36.89MB/s > > 16384*512 2 0.80s 19.99MB 0.40s 40.29MB/s > > 32768*512 1 1.11s 14.41MB 0.38s 42.56MB/s > > > > > > > > > > From rwatson at FreeBSD.org Fri Oct 3 09:06:17 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Fri Oct 3 09:06:30 2008 Subject: bad NFS/UDP performance In-Reply-To: References: <20080926081806.GA19055@icarus.home.lan> <20080926095230.GA20789@icarus.home.lan> Message-ID: On Fri, 3 Oct 2008, Danny Braniss wrote: >> OK, so it looks like this was almost certainly the rwlock change. What >> happens if you pretty much universally substitute the following in >> udp_usrreq.c: >> >> Currently Change to >> --------- --------- >> INP_RLOCK INP_WLOCK >> INP_RUNLOCK INP_WUNLOCK >> INP_RLOCK_ASSERT INP_WLOCK_ASSERT > > I guess you were almost certainly correct :-) I did the global subst. on the > udp_usrreq.c from 19/08, __FBSDID("$FreeBSD: src/sys/netinet/udp_usrreq.c,v > 1.218.2.3 2008/08/18 23:00:41 bz Exp $"); and now udp is fine again! OK. This is a change I'd rather not back out since it significantly improves performance for many other UDP workloads, so we need to figure out why it's hurting us so much here so that we know if there are reasonable alternatives. Would it be possible for you to do a run of the workload with both kernels using LOCK_PROFILING around the benchmark, and then we can compare lock contention in the two cases? What we often find is that relieving contention at one point causes new contention at another point, and if the primitive used at that point handles contention less well for whatever reason, performance can be reduced rather than improved. So maybe we're looking at an issue in the dispatched UDP code from so_upcall? Another less satisfying (and fundamentally more difficult) answer might be "something to do with the scheduler", but a bit more analysis may shed some light. Robert N M Watson Computer Laboratory University of Cambridge > > danny > > >> Robert N M Watson >> Computer Laboratory >> University of Cambridge >> >>> >>> server is a NetApp: >>> >>> kernel from 18/08/08 00:00:0 : >>> /----- UDP ----//---- TCP -------/ >>> 1*512 38528 0.19s 83.50MB 0.20s 80.82MB/s >>> 2*512 19264 0.21s 76.83MB 0.21s 77.57MB/s >>> 4*512 9632 0.19s 85.51MB 0.22s 73.13MB/s >>> 8*512 4816 0.19s 83.76MB 0.21s 75.84MB/s >>> 16*512 2408 0.19s 83.99MB 0.21s 77.18MB/s >>> 32*512 1204 0.19s 84.45MB 0.22s 71.79MB/s >>> 64*512 602 0.20s 79.98MB 0.20s 78.44MB/s >>> 128*512 301 0.18s 86.51MB 0.22s 71.53MB/s >>> 256*512 150 0.19s 82.83MB 0.20s 78.86MB/s >>> 512*512 75 0.19s 82.77MB 0.21s 76.39MB/s >>> 1024*512 37 0.19s 85.62MB 0.21s 76.64MB/s >>> 2048*512 18 0.21s 77.72MB 0.20s 80.30MB/s >>> 4096*512 9 0.26s 61.06MB 0.30s 53.79MB/s >>> 8192*512 4 0.83s 19.20MB 0.41s 39.12MB/s >>> 16384*512 2 0.84s 19.01MB 0.41s 39.03MB/s >>> 32768*512 1 0.82s 19.59MB 0.39s 40.89MB/s >>> >>> kernel from 19/08/08 00:00:00: >>> 1*512 38528 0.45s 35.59MB 0.20s 81.43MB/s >>> 2*512 19264 0.45s 35.56MB 0.20s 79.24MB/s >>> 4*512 9632 0.49s 32.66MB 0.22s 73.72MB/s >>> 8*512 4816 0.47s 34.06MB 0.21s 75.52MB/s >>> 16*512 2408 0.53s 30.16MB 0.22s 72.58MB/s >>> 32*512 1204 0.31s 51.68MB 0.40s 40.14MB/s >>> 64*512 602 0.43s 37.23MB 0.25s 63.57MB/s >>> 128*512 301 0.51s 31.39MB 0.26s 62.70MB/s >>> 256*512 150 0.47s 34.02MB 0.23s 69.06MB/s >>> 512*512 75 0.47s 34.01MB 0.23s 70.52MB/s >>> 1024*512 37 0.53s 30.12MB 0.22s 73.01MB/s >>> 2048*512 18 0.55s 29.07MB 0.23s 70.64MB/s >>> 4096*512 9 0.46s 34.69MB 0.21s 75.92MB/s >>> 8192*512 4 0.81s 19.66MB 0.43s 36.89MB/s >>> 16384*512 2 0.80s 19.99MB 0.40s 40.29MB/s >>> 32768*512 1 1.11s 14.41MB 0.38s 42.56MB/s >>> >>> >>> >>> >>> > > > From lehmann at ans-netz.de Fri Oct 3 09:08:47 2008 From: lehmann at ans-netz.de (Oliver Lehmann) Date: Fri Oct 3 09:08:54 2008 Subject: system hangup - I'm lost In-Reply-To: <20081002225036.GC2539@phenom.cordula.ws> References: <20080929221408.54e6a03a.lehmann@ans-netz.de> <20081001172943.99e9d494.lehmann@ans-netz.de> <20081002185106.a1183896.lehmann@ans-netz.de> <20081002225036.GC2539@phenom.cordula.ws> Message-ID: <20081003110840.f1c2d5da.lehmann@ans-netz.de> cpghost wrote: > If it's PATA, check the cabling, then check it again, and just to > make sure, replace the cable even if the system used to work flawlessly > in the past. I've had this on a few servers, but replacing the cables > always fixed the problem for me. It's SATA - it's a 3ware 9500S-4LP controller. I can just hope it would have detect any drive problem (even if it would result because of bad cabeling). If not I don't know why I had a raid controller anyway ;) The only other disk drive I've on that system is an USB attached hdd for backup purpose... So I can't realy try having the swap somewhere else.. //nudel> /c0 show all /c0 Driver Version = 3.60.04.003 /c0 Model = 9500S-4LP /c0 Available Memory = 112MB /c0 Firmware Version = FE9X 2.08.00.009 /c0 Bios Version = BE9X 2.03.01.052 /c0 Boot Loader Version = BL9X 2.02.00.001 /c0 Serial Number = D19004A5300589 /c0 PCB Version = Rev 019 /c0 PCHIP Version = 1.50 /c0 ACHIP Version = 3.20 /c0 Number of Ports = 4 /c0 Number of Drives = 4 /c0 Number of Units = 1 /c0 Total Optimal Units = 1 /c0 Not Optimal Units = 0 /c0 JBOD Export Policy = off /c0 Disk Spinup Policy = 1 /c0 Spinup Stagger Time Policy (sec) = 2 /c0 Cache on Degrade Policy = Follow Unit Policy Unit UnitType Status %RCmpl %V/I/M Stripe Size(GB) Cache AVrfy ------------------------------------------------------------------------------ u0 RAID-5 OK - - 64K 698.461 ON OFF Port Status Unit Size Blocks Serial --------------------------------------------------------------- p0 OK u0 232.88 GB 488397168 WD-WCANK1079272 p1 OK u0 232.88 GB 488397168 WD-WCANK1120378 p2 OK u0 232.88 GB 488397168 WD-WCANK1120936 p3 OK u0 232.88 GB 488397168 WD-WCANK1120805 Name OnlineState BBUReady Status Volt Temp Hours LastCapTest --------------------------------------------------------------------------- bbu On Yes OK OK OK 255 24-Aug-2008 //nudel> -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ From danny at cs.huji.ac.il Fri Oct 3 09:17:46 2008 From: danny at cs.huji.ac.il (Danny Braniss) Date: Fri Oct 3 09:17:53 2008 Subject: bad NFS/UDP performance In-Reply-To: References: <20080926081806.GA19055@icarus.home.lan> <20080926095230.GA20789@icarus.home.lan> Message-ID: > > On Fri, 3 Oct 2008, Danny Braniss wrote: > > >> OK, so it looks like this was almost certainly the rwlock change. What > >> happens if you pretty much universally substitute the following in > >> udp_usrreq.c: > >> > >> Currently Change to > >> --------- --------- > >> INP_RLOCK INP_WLOCK > >> INP_RUNLOCK INP_WUNLOCK > >> INP_RLOCK_ASSERT INP_WLOCK_ASSERT > > > > I guess you were almost certainly correct :-) I did the global subst. on the > > udp_usrreq.c from 19/08, __FBSDID("$FreeBSD: src/sys/netinet/udp_usrreq.c,v > > 1.218.2.3 2008/08/18 23:00:41 bz Exp $"); and now udp is fine again! > > OK. This is a change I'd rather not back out since it significantly improves > performance for many other UDP workloads, so we need to figure out why it's > hurting us so much here so that we know if there are reasonable alternatives. > > Would it be possible for you to do a run of the workload with both kernels > using LOCK_PROFILING around the benchmark, and then we can compare lock > contention in the two cases? What we often find is that relieving contention > at one point causes new contention at another point, and if the primitive used > at that point handles contention less well for whatever reason, performance > can be reduced rather than improved. So maybe we're looking at an issue in > the dispatched UDP code from so_upcall? Another less satisfying (and > fundamentally more difficult) answer might be "something to do with the > scheduler", but a bit more analysis may shed some light. gladly, but have no idea how to do LOCK_PROFILING, so some pointers would be helpfull. as a side note, many years ago I checked out NFS/TCP and it was really bad, I even remember NetApp telling us to drop TCP, but now, things look rather better. Wonder what caused it. danny From danny at cs.huji.ac.il Fri Oct 3 09:21:10 2008 From: danny at cs.huji.ac.il (Danny Braniss) Date: Fri Oct 3 09:21:17 2008 Subject: bad NFS/UDP performance In-Reply-To: References: <20080926081806.GA19055@icarus.home.lan> <20080926095230.GA20789@icarus.home.lan> Message-ID: forget it about LOCK_PROFILING, I'm RTFM now :-) though some hints on values might be helpful. have a nice weekend, danny From rwatson at FreeBSD.org Fri Oct 3 09:25:24 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Fri Oct 3 09:25:31 2008 Subject: bad NFS/UDP performance In-Reply-To: References: <20080926081806.GA19055@icarus.home.lan> <20080926095230.GA20789@icarus.home.lan> Message-ID: On Fri, 3 Oct 2008, Danny Braniss wrote: > gladly, but have no idea how to do LOCK_PROFILING, so some pointers would be > helpfull. The LOCK_PROFILING(9) man page isn't a bad starting point -- I find that the defaults work fine most of the time, so just use them. Turn the enable syscl on just before you begin a run, and turn it off immediately afterwards. Make sure to reset between reruns (rebooting to a new kernel is fine too!). > as a side note, many years ago I checked out NFS/TCP and it was really bad, > I even remember NetApp telling us to drop TCP, but now, things look rather > better. Wonder what caused it. Well, the virtues of TCP become more apparent with higher network speeds, as the logic to fill pipes using TCP, manage flow control, etc, is a lot more sophisticated than what's in the RPC code for using UDP. The downsides to UDP are also becoming more apparent: as network speeds go up, fragmented UDP risks IP ID collisions which could lead to data corruption, or at the very least, dropped packets. We have changed the default for NFSv3 mounts to TCP in 8.x, and talked about doing it for 7.1; unfortunately the timing wasn't quite right, so it most likely will appear in 7.2. Robert N M Watson Computer Laboratory University of Cambridge From jonc at chen.org.nz Fri Oct 3 09:39:39 2008 From: jonc at chen.org.nz (Jonathan Chen) Date: Fri Oct 3 09:39:45 2008 Subject: top/ps CPU percentage broken on 7.1-PRERELEASE? In-Reply-To: <200810031003.14400.shoesoft@gmx.net> References: <200810031003.14400.shoesoft@gmx.net> Message-ID: <20081003093937.GA4944@osiris.chen.org.nz> On Fri, Oct 03, 2008 at 10:03:13AM +0200, Stefan Ehmann wrote: > The CPU % displayed by top/ps for single processes seem to be broken here. > > E.g. for a simple shell loop: > top starts displaying around 20% for bash. Within some seconds it converges to > 0%. > > ps values seem to be consistent with top. > > The value in the time column seems to be correct. On every refresh it > increases by 2s. > > last pid: 19353; load averages: 0.99, 0.90, 0.76 up 0+00:37:29 > 09:07:00 > 119 processes: 2 running, 114 sleeping, 1 stopped, 2 zombie > CPU: 98.5% user, 0.0% nice, 1.1% system, 0.4% interrupt, 0.0% idle > Mem: 376M Active, 407M Inact, 144M Wired, 47M Cache, 110M Buf, 13M Free > Swap: 1280M Total, 1280M Free > > PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND > 19352 stefan 1 99 0 4432K 2080K RUN 0:03 15.48% bash > > All other process are using 0% CPU. > > I did a buildworld/kernel yesterday to be sure everything is in sync. I have > CURRENT on a different hard disk. Haven't seen the problem there. > Are there any relevant fixes that weren't MFCed? > > Does anyone else see this? This is a single CPU i386 machine. Yes, my Java processes now run at 800% at times on my dual processor AMD64 system. -- Jonathan Chen ---------------------------------------------------------------------- The Internet: an empirical test of the idea that a million monkeys banging on a million keyboards can produce Shakespeare From koitsu at FreeBSD.org Fri Oct 3 11:17:05 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Fri Oct 3 11:17:12 2008 Subject: pf rules not being loaded during boot on 7.1-PRERELEASE In-Reply-To: <48E535D3.8000805@cran.org.uk> References: <48E535D3.8000805@cran.org.uk> Message-ID: <20081003111703.GA27385@icarus.home.lan> On Thu, Oct 02, 2008 at 09:57:55PM +0100, Bruce Cran wrote: > I recently upgraded my i386 router from 7.0 to 7.1-PRERELEASE. I > rebooted it today but despite pf_enable="YES" being in /etc/rc.conf no > rules got loaded during boot, despite pf itself having been enabled: > > router# pfctl -s rules > router# pfctl -e -f /etc/pf.conf > pfctl: pf already enabled > [connection is closed due to new rules being loaded] > router# pfctl -s rules > scrub in all fragment reassemble > [... lots of rules listed] > > Has anyone else seen this problem, or have I just missed something > that's changed between 7.0 and 7.1 in the way pf works? I was seeing something similar on my own box which I just upgraded from a 150-day-old RELENG_6 to present RELENG_6. pfctl -s rules output no rules. pfctl -s info showed packet counters, but no interface stats (due to the rules not being loaded, e.g. no loginterface). kldstat showed pflog.ko and pf.ko loaded. If I did /etc/rc.d/pf start, the rules would loaded, and everything starts working as expected. I rebooted the box and saw the following on serial console, which I'm pretty sure is what's responsible for the breakage: Enabling pf. Oct 3 04:14:51 pflogd[374]: [priv]: msg PRIV_OPEN_LOG received cannot determine interface bandwidth for bge0, specify an absolute bandwidth altq not defined on bge0 altq not defined on bge0 /conf/ME/pf.conf:52: errors in queue definition altq not defined on bge0 /conf/ME/pf.conf:53: errors in queue definition altq not defined on bge0 /conf/ME/pf.conf:54: errors in queue definition pfctl: Syntax error in config file: pf rules not loaded pf enabled I'd recommend you check your kernel console log on boot-up and see if anything is showing up there. I'm about to go digging to find out what's wrong with my ALTQ rules. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From koitsu at FreeBSD.org Fri Oct 3 11:38:28 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Fri Oct 3 11:38:36 2008 Subject: pf rules not being loaded during boot on 7.1-PRERELEASE In-Reply-To: <20081003111703.GA27385@icarus.home.lan> References: <48E535D3.8000805@cran.org.uk> <20081003111703.GA27385@icarus.home.lan> Message-ID: <20081003113824.GA27757@icarus.home.lan> On Fri, Oct 03, 2008 at 04:17:03AM -0700, Jeremy Chadwick wrote: > On Thu, Oct 02, 2008 at 09:57:55PM +0100, Bruce Cran wrote: > > I recently upgraded my i386 router from 7.0 to 7.1-PRERELEASE. I > > rebooted it today but despite pf_enable="YES" being in /etc/rc.conf no > > rules got loaded during boot, despite pf itself having been enabled: > > > > router# pfctl -s rules > > router# pfctl -e -f /etc/pf.conf > > pfctl: pf already enabled > > [connection is closed due to new rules being loaded] > > router# pfctl -s rules > > scrub in all fragment reassemble > > [... lots of rules listed] > > > > Has anyone else seen this problem, or have I just missed something > > that's changed between 7.0 and 7.1 in the way pf works? > > I was seeing something similar on my own box which I just upgraded from > a 150-day-old RELENG_6 to present RELENG_6. pfctl -s rules output no > rules. pfctl -s info showed packet counters, but no interface stats > (due to the rules not being loaded, e.g. no loginterface). > > kldstat showed pflog.ko and pf.ko loaded. > > If I did /etc/rc.d/pf start, the rules would loaded, and everything > starts working as expected. > > I rebooted the box and saw the following on serial console, which I'm > pretty sure is what's responsible for the breakage: > > Enabling pf. > Oct 3 04:14:51 pflogd[374]: [priv]: msg PRIV_OPEN_LOG received > cannot determine interface bandwidth for bge0, specify an absolute > bandwidth > altq not defined on bge0 > altq not defined on bge0 > /conf/ME/pf.conf:52: errors in queue definition > altq not defined on bge0 > /conf/ME/pf.conf:53: errors in queue definition > altq not defined on bge0 > /conf/ME/pf.conf:54: errors in queue definition > pfctl: Syntax error in config file: pf rules not loaded > pf enabled Cross-posting to freebsd-pf (I'm sorry for doing this, but it needs attention from both -pf and -stable). I've figured out what the problem is. This is not good, and is guaranteed to bite other people. I'd like to believe this is an rc-related problem, but I'm not sure how to fix it. The problem in my case: The physical interfaces were brought online, but were still technically offline (the switch and NIC PHY were taking some time to negotiate speed and duplex). Boot messages: bge0: link state changed to DOWN bge1: link state changed to DOWN lo0: flags=8049 mtu 16384 inet 127.0.0.1 netmask 0xff000000 bge0: flags=8843 mtu 1500 options=1b inet XXXXXXXXXXX netmask 0xffffff80 broadcast XXXXXXXXXXXXX ether 00:30:48:81:fc:8a media: Ethernet autoselect (none) status: no carrier bge1: flags=8843 mtu 1500 options=1b inet XXXXXXXXX netmask 0xffffff00 broadcast XXXXXXXXXXX ether 00:30:48:81:fc:8b media: Ethernet autoselect (none) status: no carrier Note that the interfaces are UP, not DOWN. Then the very next thing seen on the console: Starting pflog. pflog0: promiscuous mode enabled Enabling pf. Oct 3 04:14:51 pflogd[374]: [priv]: msg PRIV_OPEN_LOG received cannot determine interface bandwidth for bge0, specify an absolute bandwidth altq not defined on bge0 altq not defined on bge0 /conf/ME/pf.conf:52: errors in queue definition altq not defined on bge0 /conf/ME/pf.conf:53: errors in queue definition altq not defined on bge0 /conf/ME/pf.conf:54: errors in queue definition pfctl: Syntax error in config file: pf rules not loaded pf enabled The error message about "interface bandwidth" is the key here. My ALTQ rules use "bandwidth ", not a static amount in bits: altq on $ext_if cbq bandwidth 100% queue { std, blah, blah2 } queue std bandwidth 95% cbq(default borrow) queue blah bandwidth 384Kb queue blah2 bandwidth 384Kb Since the PHY hadn't negotiated speed, pf was unable to determine what the percentage really mapped to bandwidth/bit-wise. If at all possible, pf should wait for the interfaces to come up fully (that includes autonegotiation being completed; do we have framework for this?) before starting. I changed my rules to use a static speeds (100% --> 100Mb, and 95% --> 95Mb), which appear to work, but after the 2nd reboot the speed/duplex had been negotiated by the time pf had started, so I don't know if it truly fixed anything. I don't know what pf will do if you say "100Mb" for an interface which has no link/speed defined yet. It may behave the same way as shown above; I don't know. This needs some thought and definitely a solution. Again, note that I'm using RELENG_6, but I've a feeling this might bite RELENG_7 too. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From volker at vwsoft.com Fri Oct 3 13:22:23 2008 From: volker at vwsoft.com (Volker) Date: Fri Oct 3 13:22:31 2008 Subject: pf rules not being loaded during boot on 7.1-PRERELEASE In-Reply-To: <48E535D3.8000805@cran.org.uk> References: <48E535D3.8000805@cran.org.uk> Message-ID: <48E61880.903@vwsoft.com> On 12/23/-58 20:59, Bruce Cran wrote: >
I recently upgraded my i386 router from 7.0 > to 7.1-PRERELEASE. I rebooted it today but despite pf_enable="YES" > being in /etc/rc.conf no rules got loaded during boot, despite pf itself > having been enabled: > > router# pfctl -s rules > router# pfctl -e -f /etc/pf.conf > pfctl: pf already enabled > [connection is closed due to new rules being loaded] > router# pfctl -s rules > scrub in all fragment reassemble > [... lots of rules listed] > > Has anyone else seen this problem, or have I just missed something > that's changed between 7.0 and 7.1 in the way pf works? > Hi Bruce, > # pfctl -sr | wc -l > 81 > # grep pf /etc/rc.conf > pf_enable="YES" > pf_rules="/etc/Firewall/pf-ces.conf" > pflog_enable="YES" this is from a very recent 7-STABLE box: > # uname -a > FreeBSD cesar.sz.vwsoft.com 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #46: Tue Sep 30 23:33:36 CEST 2008 root@cesar.sz.vwsoft.com:/usr/obj/usr/src/sys/CESAR i386 Do you mind to show me your rules? What does ``pfctl -gnf /path/to/your/rules'' give? Volker From danny at cs.huji.ac.il Fri Oct 3 13:26:54 2008 From: danny at cs.huji.ac.il (Danny Braniss) Date: Fri Oct 3 13:27:07 2008 Subject: bad NFS/UDP performance In-Reply-To: References: <20080926081806.GA19055@icarus.home.lan> <20080926095230.GA20789@icarus.home.lan> Message-ID: > > On Fri, 3 Oct 2008, Danny Braniss wrote: > > > gladly, but have no idea how to do LOCK_PROFILING, so some pointers would be > > helpfull. > > The LOCK_PROFILING(9) man page isn't a bad starting point -- I find that the > defaults work fine most of the time, so just use them. Turn the enable syscl > on just before you begin a run, and turn it off immediately afterwards. Make > sure to reset between reruns (rebooting to a new kernel is fine too!). > in ftp://ftp.cs.huji.ac.il/users/danny/lock.prof there 3 files: 7.1-100 host connected at 100 running -prerelease 7.1-1000 same but connected at 1000 7.0-1000 -stable with your 'patch' at 100 my benchmark didn't suffer from the profiling, average was about 9. at 1000 the benchmark got realy hit, average was around 12 for the patched, and 4 for the unpatched (less than at 100). danny From nox at jelal.kn-bremen.de Fri Oct 3 13:33:57 2008 From: nox at jelal.kn-bremen.de (Juergen Lock) Date: Fri Oct 3 13:34:10 2008 Subject: dtrace: processing aborted: Abort due to systemic unresponsiveness (dtrace_gethrtime()?) - and kgdb In-Reply-To: <20080917204107.GA11167@saturn.kn-bremen.de> References: <20080917204107.GA11167@saturn.kn-bremen.de> Message-ID: <20081003131600.GA5421@saturn.kn-bremen.de> On Wed, Sep 17, 2008 at 10:41:07PM +0200, I wrote: > Hi! > > I got curious in dtrace, and after mr's sys/amd64/amd64/trap.c > commit (r183050, thanx! :) I was able to build a kernel that could > kldload dtraceall on 7-stable amd64, but trying even simple things like > dtrace -n tick-1sec > only runs for a short time, or not at all, ending with $subject: > > # dtrace -n tick-1sec > dtrace: description 'tick-1sec' matched 1 probe > dtrace: buffer size lowered to 2m > CPU ID FUNCTION:NAME > 1 32125 :tick-1sec > dtrace: processing aborted: Abort due to systemic unresponsiveness > # dtrace -n tick-1sec > dtrace: description 'tick-1sec' matched 1 probe > dtrace: buffer size lowered to 2m > dtrace: processing aborted: Abort due to systemic unresponsiveness > # > > Looking around on the net I find that this is probably related to > dtrace_gethrtime() (this box is SMP), which I see defined in > sys/amd64/amd64/tsc.c, but also in sys/cddl/dev/dtrace/amd64/dtrace_subr.c, > and in sys/cddl/dev/dtrace/i386/dtrace_subr.c, but nowhere under sys/i386. > The versions in sys/cddl/dev/dtrace take cpu-dependent tsc offsets into > account which the one in sys/amd64/amd64/tsc.c doesn't, is there any > particular reason this version is used? Also I don't see it in HEAD... > I since found out two things: a) the version of dtrace_gethrtime() in sys/amd64/amd64/tsc.c is indeed not needed, and b) removing it still didn't fix my problem, stopping powerd then did, even with the original kernel. Doh! :) Anyway, I'm still pretty sure the #ifdef KDTRACE_HOOKS code in sys/amd64/amd64/tsc.c can go, the version of dtrace_gethrtime() in sys/cddl/dev/dtrace/amd64/dtrace_subr.c looks more correct at least... Thanx, Juergen From admin at kkip.pl Fri Oct 3 14:22:56 2008 From: admin at kkip.pl (Bartosz Stec) Date: Fri Oct 3 14:23:03 2008 Subject: fxp performance with POLLING Message-ID: <48E62ABA.6070901@kkip.pl> Hello again :) With POLLING enabled I experience about 10%-25% performance drop when copying files over network. Tested with both SAMBA and NFS. Is it normal? FreeBSD 7.1-PRERELEASE #0: Sat Sep 6 01:52:12 CEST 2008 fxp0: port 0xc800-0xc83f mem 0xe1021000-0xe1021fff irq 20 at device 8.0 on pci1 # ifconfig fxp0 fxp0: flags=9843 metric 0 mtu 1500 options=8 ether 00:20:ed:42:87:13 inet 192.168.0.2 netmask 0xffffff00 broadcast 192.168.0.255 media: Ethernet autoselect (100baseTX ) status: active BTW overall SAMBA performance still sucks on 7.1-pre as much as on RELENG_5 ...:( - 7.5 MB/s peak. -- Bartosz Stec From pdegoeje at service2media.com Fri Oct 3 15:06:23 2008 From: pdegoeje at service2media.com (Pieter de Goeje) Date: Fri Oct 3 15:06:30 2008 Subject: fxp performance with POLLING In-Reply-To: <48E62ABA.6070901@kkip.pl> References: <48E62ABA.6070901@kkip.pl> Message-ID: <200810031706.11941.pdegoeje@service2media.com> On Friday 03 October 2008, Bartosz Stec wrote: > Hello again :) > > With POLLING enabled I experience about 10%-25% performance drop when > copying files over network. Tested with both SAMBA and NFS. Is it normal? Yes. You don't want to use polling unless you set kern.hz to 10000 or something in that range. If you have a NIC with interrupt moderation, polling should almost never be necessary. Note that polling can still be useful for routers, because it allows you to have a much more responsive system even when handling heavy network traffic. -- Pieter de Goeje From henrik at 50hz.ws Fri Oct 3 16:51:37 2008 From: henrik at 50hz.ws (Henrik Friedrichsen) Date: Fri Oct 3 16:51:45 2008 Subject: USB detach/attach hangs with 7.0-RELEASE and 7.1-PRERELEASE In-Reply-To: References: <48E02557.2020303@incunabulum.net> Message-ID: <20081003145135.GA4528@dsp.50hz.ws> USB support in the BIOS? What kind of support does the BIOS provide that you can disable? I'm only able to disable the USB device, but that'd turn it off completely :( Henrik. On Mon, Sep 29, 2008 at 10:05:02PM +0200, Ronald Klop wrote: > On Mon, 29 Sep 2008 02:46:15 +0200, Bruce M Simpson > wrote: > > >Hi, > > > >I've noticed some general instability with plugging in or removing USB > >devices with FreeBSD 7.x, even when the devices are not actively in use. > > > >I had this happen with umass and ucom devices 3 times today. The machine > >hangs solid, there are no obvious signs of a panic or trap to DDB. I > >can't provide backtraces unfortunately -- these hangs happen on both my > >laptop and desktop, and I usually have X running -- if I had more > >specific information, I'd open a PR. > > > >Again, there seems to be no reason why this should happen, the devices > >are off-the-shelf consumer items known to work with existing drivers, > >and have been repeatedly used in other OSes without these hangs > >happening; consider this an "anecdotal report". > > > >[For some reason my IBM laptop will often not allow me to break into DDB > >on a driver related panic, and will just immediately reboot -- I lack > >free time to track down exactly why this could be. > >My desktop has a USB keyboard and this appears not to be supported by > >DDB, I ordered a PS/2 keyboard which hasn't arrived, but that's another > >story.] > > > >thanks > >BMS > > On my computer I had to disable USB support in the BIOS because it > 'conflicted' with USB support of FreeBSD. > FreeBSD still detects USB and all connected devices. > Maybe this helps on your computer also. > > Ronald. > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From cswiger at mac.com Fri Oct 3 18:02:43 2008 From: cswiger at mac.com (Chuck Swiger) Date: Fri Oct 3 18:02:50 2008 Subject: fxp performance with POLLING In-Reply-To: <200810031706.11941.pdegoeje@service2media.com> References: <48E62ABA.6070901@kkip.pl> <200810031706.11941.pdegoeje@service2media.com> Message-ID: <48E65A6E.4090203@mac.com> Pieter de Goeje wrote: > On Friday 03 October 2008, Bartosz Stec wrote: >> Hello again :) >> >> With POLLING enabled I experience about 10%-25% performance drop when >> copying files over network. Tested with both SAMBA and NFS. Is it normal? > > Yes. You don't want to use polling unless you set kern.hz to 10000 or > something in that range. HZ = 1000 or 2000 is fine for most purposes, at least up through T3 level bandwidth. For a home LAN or small business office of a half-dozen machines using DSL/Cable (~ 1-5 MBs up), even a P2-300 or VIA C3 600 at HZ=250 works OK as a firewall/router. The main thing that using polling does is that it adds a reasonably fixed amount of latency (ie, the poll interval) but gives solid processing performance even under heavy load, just as you say: > If you have a NIC with interrupt moderation, polling > should almost never be necessary. Note that polling can still be useful for > routers, because it allows you to have a much more responsive system even > when handling heavy network traffic. Note that he's got the link0 flag going, so that should mean he's using firmware with the fxp NIC which does interrupt moderation. Regards, -- -Chuck From gpalmer at freebsd.org Fri Oct 3 18:04:53 2008 From: gpalmer at freebsd.org (Gary Palmer) Date: Fri Oct 3 18:05:02 2008 Subject: pf rules not being loaded during boot on 7.1-PRERELEASE In-Reply-To: <20081003111703.GA27385@icarus.home.lan> References: <48E535D3.8000805@cran.org.uk> <20081003111703.GA27385@icarus.home.lan> Message-ID: <20081003180452.GA1262@in-addr.com> On Fri, Oct 03, 2008 at 04:17:03AM -0700, Jeremy Chadwick wrote: > On Thu, Oct 02, 2008 at 09:57:55PM +0100, Bruce Cran wrote: > > I recently upgraded my i386 router from 7.0 to 7.1-PRERELEASE. I > > rebooted it today but despite pf_enable="YES" being in /etc/rc.conf no > > rules got loaded during boot, despite pf itself having been enabled: > > > > router# pfctl -s rules > > router# pfctl -e -f /etc/pf.conf > > pfctl: pf already enabled > > [connection is closed due to new rules being loaded] > > router# pfctl -s rules > > scrub in all fragment reassemble > > [... lots of rules listed] > > > > Has anyone else seen this problem, or have I just missed something > > that's changed between 7.0 and 7.1 in the way pf works? > > I was seeing something similar on my own box which I just upgraded from > a 150-day-old RELENG_6 to present RELENG_6. pfctl -s rules output no > rules. pfctl -s info showed packet counters, but no interface stats > (due to the rules not being loaded, e.g. no loginterface). > > kldstat showed pflog.ko and pf.ko loaded. > > If I did /etc/rc.d/pf start, the rules would loaded, and everything > starts working as expected. > > I rebooted the box and saw the following on serial console, which I'm > pretty sure is what's responsible for the breakage: > > Enabling pf. > Oct 3 04:14:51 pflogd[374]: [priv]: msg PRIV_OPEN_LOG received > cannot determine interface bandwidth for bge0, specify an absolute > bandwidth > altq not defined on bge0 > altq not defined on bge0 > /conf/ME/pf.conf:52: errors in queue definition > altq not defined on bge0 > /conf/ME/pf.conf:53: errors in queue definition > altq not defined on bge0 > /conf/ME/pf.conf:54: errors in queue definition > pfctl: Syntax error in config file: pf rules not loaded > pf enabled > > I'd recommend you check your kernel console log on boot-up and see if > anything is showing up there. I'm about to go digging to find out > what's wrong with my ALTQ rules. I noticed the last time I rebooted my gateway to patch the latest v6 hole that vr0 (in my case) had not negotiated link by the time pf started (even tho its a static IP address, not DHCP). This meant that there was no link speed for altq to base its queueing on, and the entire pf load failed (I think). I changed my vr0 altq line to hardcode the speed at 100mbit and I think that should fix it Why this is an issue now and it wasn't previously I'm not sure. The current failure mode is certainly not helpful. I'm not sure if we should force pf to wait for link on altq interfaces or not. Regards, Gary From blue at white.lv Fri Oct 3 18:12:33 2008 From: blue at white.lv (Eugene M. Kim) Date: Fri Oct 3 18:12:39 2008 Subject: NFSv4 ACL on RELENG_7? Message-ID: <48E6608A.1010606@white.lv> Hello, A quick question: Is there an NFSv4 ACL patch available for testing on RELENG_7? (I have a quite busy machine on which I wanted to test-drive NFSv4 ACL.) Cheers, Eugene From watson at FreeBSD.org Fri Oct 3 18:55:15 2008 From: watson at FreeBSD.org (Robert Watson) Date: Fri Oct 3 18:55:22 2008 Subject: bad NFS/UDP performance In-Reply-To: References: <20080926081806.GA19055@icarus.home.lan> <20080926095230.GA20789@icarus.home.lan> Message-ID: On Fri, 3 Oct 2008, Danny Braniss wrote: >> On Fri, 3 Oct 2008, Danny Braniss wrote: >> >>> gladly, but have no idea how to do LOCK_PROFILING, so some pointers would >>> be helpfull. >> >> The LOCK_PROFILING(9) man page isn't a bad starting point -- I find that >> the defaults work fine most of the time, so just use them. Turn the enable >> syscl on just before you begin a run, and turn it off immediately >> afterwards. Make sure to reset between reruns (rebooting to a new kernel >> is fine too!). > > in ftp://ftp.cs.huji.ac.il/users/danny/lock.prof > there 3 files: > 7.1-100 host connected at 100 running -prerelease > 7.1-1000 same but connected at 1000 > 7.0-1000 -stable with your 'patch' > at 100 my benchmark didn't suffer from the profiling, average was about 9. > at 1000 the benchmark got realy hit, average was around 12 for the patched, > and 4 for the unpatched (less than at 100). Interesting. A bit of post-processing: robert@fledge:/tmp> cat 7.1-1000 | awk -F' ' '{print $3" "$9}' | sort -n | tail -10 2413283 /r+d/7/sys/kern/kern_mutex.c:141 2470096 /r+d/7/sys/nfsclient/nfs_socket.c:1218 2676282 /r+d/7/sys/net/route.c:293 2754866 /r+d/7/sys/kern/vfs_bio.c:1468 3196298 /r+d/7/sys/nfsclient/nfs_bio.c:1664 3318742 /r+d/7/sys/net/route.c:1584 3711139 /r+d/7/sys/dev/bge/if_bge.c:3287 3753518 /r+d/7/sys/net/if_ethersubr.c:405 3961312 /r+d/7/sys/nfsclient/nfs_subs.c:1066 10688531 /r+d/7/sys/dev/bge/if_bge.c:3726 robert@fledge:/tmp> cat 7.0-1000 | awk -F' ' '{print $3" "$9}' | sort -n | tail -10 468631 /r+d/hunt/src/sys/nfsclient/nfs_nfsiod.c:286 501989 /r+d/hunt/src/sys/nfsclient/nfs_vnops.c:1148 631587 /r+d/hunt/src/sys/nfsclient/nfs_socket.c:1198 701155 /r+d/hunt/src/sys/nfsclient/nfs_socket.c:1258 718211 /r+d/hunt/src/sys/kern/kern_mutex.c:141 1118711 /r+d/hunt/src/sys/nfsclient/nfs_bio.c:1664 1169125 /r+d/hunt/src/sys/nfsclient/nfs_subs.c:1066 1222867 /r+d/hunt/src/sys/kern/vfs_bio.c:1468 3876072 /r+d/hunt/src/sys/netinet/udp_usrreq.c:545 5198927 /r+d/hunt/src/sys/netinet/udp_usrreq.c:864 The first set above is with the unmodified 7-STABLE tree, the second with a reversion of read locking on the UDP inpcb. The big blinking sign of interest is that the bge interface lock is massively contended in the first set of output, and basically doesn't appear in the second. There are various reasons bge could stand out quite so much -- one possibly is that previously, the udp lock serialized all access to the interface from the send code, preventing the send and receive paths from contending. A few things to try: - Let's look compare the context switch rates on the two benchmarks. Could you run vmstat and look at the cpu cs line during the benchmarks and see how similar the two are as the benchmarks run? You'll want to run it with vmstat -w 1 and collect several samples per benchmark, since we're really interested in the distribution rather than an individual sample. - Is there any chance you could drop an if_em card into the same box and run the identical benchmarks with and without LOCK_PROFILING to see whether it behaves differently than bge when the patch is applied? if_em's interrupt handling is quite different, and may significantly affect lock use, and hence contention. Thanks, Robert N M Watson Computer Laboratory University of Cambridge From bruce at cran.org.uk Fri Oct 3 22:06:21 2008 From: bruce at cran.org.uk (Bruce Cran) Date: Fri Oct 3 22:06:28 2008 Subject: pf rules not being loaded during boot on 7.1-PRERELEASE In-Reply-To: <20081003113824.GA27757@icarus.home.lan> References: <48E535D3.8000805@cran.org.uk> <20081003111703.GA27385@icarus.home.lan> <20081003113824.GA27757@icarus.home.lan> Message-ID: <20081003230534.60b4c1cb@tau.draftnet> On Fri, 3 Oct 2008 04:38:24 -0700 Jeremy Chadwick wrote: > I've figured out what the problem is. This is not good, and is > guaranteed to bite other people. I'd like to believe this is an > rc-related problem, but I'm not sure how to fix it. > > The problem in my case: > > The physical interfaces were brought online, but were still > technically offline (the switch and NIC PHY were taking some time to > negotiate speed and duplex). Boot messages: > My box is headless so I didn't see the startup messages until I attached a serial cable. It's a similar problem in my case, but caused because I'm firewalling an ADSL connection which uses PPP, and pf is being enabled before PPP has configured tun0: Setting hostname: router.draftnet. vr0: link state changed to DOWN dc0: link state changed to UP dc3: link state changed to UP lo0: flags=8049 metric 0 mtu 16384 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x8 inet 127.0.0.1 netmask 0xff000000 vr0: flags=8843 metric 0 mtu 1500 options=2808 ether 00:40:63:e3:d1:b7 inet6 XXXXXXXXXX%vr0 prefixlen 64 tentative scopeid 0x1 inet XXXXXXXXX netmask 0xffffff00 broadcast XXXXXXXXXX media: Ethernet autoselect (none) status: no carrier dc0: flags=8843 metric 0 mtu 1500 options=8 ether 00:80:c8:c9:96:6d inet6 XXXXXXXXX%dc0 prefixlen 64 tentative scopeid 0x2 inet XXXXXXXXX netmask 0xffffff00 broadcast XXXXXXXXX media: Ethernet autoselect (100baseTX ) status: active dc3: flags=8843 metric 0 mtu 1500 options=8 ether 00:80:c8:c9:96:70 inet6 XXXXXXXXX%dc3 prefixlen 64 tentative scopeid 0x5 inet XXXXXXXXX netmask 0xffffff00 broadcast XXXXXXXXX media: Ethernet autoselect (100baseTX ) status: active Enabling pf. no IP address found for tun0 /etc/pf.conf:45: could not parse host specification pfctl: Syntax error in config file: pf rules not loaded pf enabled Starting PPP profile: demonLoading /lib/libalias_cuseeme.so Loading /lib/libalias_ftp.so Loading /lib/libalias_irc.so Lodading /lib/libalcias_nbt.so Load1ing /lib/libalia:s_pptp.so Loadi ng /lib/libaliasl_skinny.so Loadiing /lib/libalians_smedia.so k. no IP address found for tun0 s /etc/pf.conf:45t: could not parsae host specificattion pfctl: Synetax error in con fig file: pf rulces not loaded ahdd net default: agateway tun0 Adnditional routingg options: IP gateeway=YES. dadd net ::ffff:0 .0.0.0: gateway t::1 add net ::0o.0.0.0: gateway ::1 net.inet6.iDp6.forwarding: 0O -> 1 net.inet6W.ip6.accept_rtadNv: 0 -> 0 dc2: link state changed to DOWN The messages following "link state changed to DOWN" indicate that all the interfaces are now properly configured with IP addresses, including the external ADSL tun0 and IPv6 gif0 interfaces. -- Bruce Cran From dan at langille.org Fri Oct 3 22:19:50 2008 From: dan at langille.org (Dan Langille) Date: Fri Oct 3 22:19:57 2008 Subject: Upgrading to 7.x : make check-old Message-ID: <48E69A3B.7090904@langille.org> Folks: I have upgraded a server from 6.3 to 7.0. That went rather smoothly. I have a question about removing old libraries via make delete-old. Given the list of old libraries shown at the end of this URL: http://www.freebsddiary.org/upgrade-6.3-to-7.0.php Is that list more or less expected? From what I can tell, it's pretty safe to now do a make delete-old-libs. Do you concur? No, I won't hold you to it. I'm just looking for backup of my decision. From dan at langille.org Fri Oct 3 22:24:58 2008 From: dan at langille.org (Dan Langille) Date: Fri Oct 3 22:25:06 2008 Subject: make delete-old vs make-delete-libs Message-ID: <48E69B70.3090804@langille.org> I'm wondering if these commands from /usr/src/Makefile are correctly described: # check-old - List obsolete directories/files/libraries. # check-old-dirs - List obsolete directories. # check-old-files - List obsolete files. # check-old-libs - List obsolete libraries. # delete-old - Delete obsolete directories/files/libraries. # delete-old-dirs - Delete obsolete directories. # delete-old-files - Delete obsolete files. # delete-old-libs - Delete obsolete libraries. From the above, it appears as if 'make delete-old' is the same as doing: make delete-old-dirs make delete-old-files make delete-old-libs Running the command indicates otherwise. In fact, make delete-old outputs: >>> Removing old files (only deletes safe to delete libs) and: >>> Old directories removed To remove old libraries run 'make delete-old-libs'. That indicates, to me, that only old files were deleted. No old libraries were touched. What's up here? Which is right? thanks. From volker at vwsoft.com Fri Oct 3 23:05:42 2008 From: volker at vwsoft.com (Volker) Date: Fri Oct 3 23:05:51 2008 Subject: pf rules not being loaded during boot on 7.1-PRERELEASE In-Reply-To: <20081003230534.60b4c1cb@tau.draftnet> References: <48E535D3.8000805@cran.org.uk> <20081003111703.GA27385@icarus.home.lan> <20081003113824.GA27757@icarus.home.lan> <20081003230534.60b4c1cb@tau.draftnet> Message-ID: <48E69F6D.5050001@vwsoft.com> On 10/04/08 00:05, Bruce Cran wrote: > On Fri, 3 Oct 2008 04:38:24 -0700 > Jeremy Chadwick wrote: >> I've figured out what the problem is. This is not good, and is >> guaranteed to bite other people. I'd like to believe this is an >> rc-related problem, but I'm not sure how to fix it. >> >> The problem in my case: >> >> The physical interfaces were brought online, but were still >> technically offline (the switch and NIC PHY were taking some time to >> negotiate speed and duplex). Boot messages: >> > > My box is headless so I didn't see the startup messages until I > attached a serial cable. It's a similar problem in my case, but caused > because I'm firewalling an ADSL connection which uses PPP, and pf is > being enabled before PPP has configured tun0: > > Setting hostname: router.draftnet. > vr0: link state changed to DOWN > dc0: link state changed to UP > dc3: link state changed to UP > lo0: flags=8049 metric 0 mtu 16384 > inet6 ::1 prefixlen 128 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x8 > inet 127.0.0.1 netmask 0xff000000 > vr0: flags=8843 metric 0 mtu > 1500 options=2808 > ether 00:40:63:e3:d1:b7 > inet6 XXXXXXXXXX%vr0 prefixlen 64 tentative > scopeid 0x1 inet XXXXXXXXX netmask 0xffffff00 broadcast XXXXXXXXXX > media: Ethernet autoselect (none) > status: no carrier > dc0: flags=8843 metric 0 mtu > 1500 options=8 > ether 00:80:c8:c9:96:6d > inet6 XXXXXXXXX%dc0 prefixlen 64 tentative > scopeid 0x2 inet XXXXXXXXX netmask 0xffffff00 broadcast XXXXXXXXX > media: Ethernet autoselect (100baseTX ) > status: active > dc3: flags=8843 metric 0 mtu > 1500 options=8 > ether 00:80:c8:c9:96:70 > inet6 XXXXXXXXX%dc3 prefixlen 64 tentative > scopeid 0x5 inet XXXXXXXXX netmask 0xffffff00 broadcast XXXXXXXXX > media: Ethernet autoselect (100baseTX ) > status: active > Enabling pf. > no IP address found for tun0 > /etc/pf.conf:45: could not parse host specification > pfctl: Syntax error in config file: pf rules not loaded > pf enabled > Starting PPP profile: demonLoading /lib/libalias_cuseeme.so > Loading /lib/libalias_ftp.so > Loading /lib/libalias_irc.so > Lodading /lib/libalcias_nbt.so > Load1ing /lib/libalia:s_pptp.so > Loadi ng /lib/libaliasl_skinny.so > Loadiing /lib/libalians_smedia.so > k. > no IP address found for tun0 > s > /etc/pf.conf:45t: could not parsae host specificattion > pfctl: Synetax error in con fig file: pf rulces not loaded > ahdd net default: agateway tun0 > Adnditional routingg options: IP gateeway=YES. > dadd net ::ffff:0 .0.0.0: gateway t::1 > add net ::0o.0.0.0: gateway ::1 > net.inet6.iDp6.forwarding: 0O -> 1 > net.inet6W.ip6.accept_rtadNv: 0 -> 0 > > dc2: link state changed to DOWN > > The messages following "link state changed to DOWN" indicate that all > the interfaces are now properly configured with IP addresses, including > the external ADSL tun0 and IPv6 gif0 interfaces. > Bruce, looking into my crystal ball... ;) You seem to have a rule like: pass ... on tun0 from any to tun0 ... If you change that into: pass ... on tun0 from any to (tun0) ... pf will happily parse your rules and activate your firewall even while tun0 does not already have an IP address. You may also try to use rules naming an interface family instead of a single interface. Other than that suggestion, I may help you if you'll send me your rules (private mail is ok for me). Volker From bruce at cran.org.uk Fri Oct 3 23:23:01 2008 From: bruce at cran.org.uk (Bruce Cran) Date: Fri Oct 3 23:23:13 2008 Subject: pf rules not being loaded during boot on 7.1-PRERELEASE In-Reply-To: <48E69F6D.5050001@vwsoft.com> References: <48E535D3.8000805@cran.org.uk> <20081003111703.GA27385@icarus.home.lan> <20081003113824.GA27757@icarus.home.lan> <20081003230534.60b4c1cb@tau.draftnet> <48E69F6D.5050001@vwsoft.com> Message-ID: <20081004002229.7089be9c@tau.draftnet> On Sat, 04 Oct 2008 00:40:45 +0200 Volker wrote: > You seem to have a rule like: > > pass ... on tun0 from any to tun0 ... > > If you change that into: > > pass ... on tun0 from any to (tun0) ... > > pf will happily parse your rules and activate your firewall even while > tun0 does not already have an IP address. You may also try to use > rules naming an interface family instead of a single interface. You're right - I mostly used lines with (tun0) but line 45 didn't have the brackets. I've just added them, rebooted and pf loaded the rules during boot. -- Bruce Cran From volker at vwsoft.com Fri Oct 3 23:26:07 2008 From: volker at vwsoft.com (Volker) Date: Fri Oct 3 23:26:14 2008 Subject: pf rules not being loaded during boot on 7.1-PRERELEASE In-Reply-To: <20081004002229.7089be9c@tau.draftnet> References: <48E535D3.8000805@cran.org.uk> <20081003111703.GA27385@icarus.home.lan> <20081003113824.GA27757@icarus.home.lan> <20081003230534.60b4c1cb@tau.draftnet> <48E69F6D.5050001@vwsoft.com> <20081004002229.7089be9c@tau.draftnet> Message-ID: <48E6A9FD.4060406@vwsoft.com> On 10/04/08 01:22, Bruce Cran wrote: > On Sat, 04 Oct 2008 00:40:45 +0200 > Volker wrote: >> You seem to have a rule like: >> >> pass ... on tun0 from any to tun0 ... >> >> If you change that into: >> >> pass ... on tun0 from any to (tun0) ... >> >> pf will happily parse your rules and activate your firewall even while >> tun0 does not already have an IP address. You may also try to use >> rules naming an interface family instead of a single interface. > > You're right - I mostly used lines with (tun0) but line 45 didn't have > the brackets. I've just added them, rebooted and pf loaded the rules > during boot. > Well, sometimes my crystal ball works ;) From shoesoft at gmx.net Sat Oct 4 06:10:47 2008 From: shoesoft at gmx.net (Stefan Ehmann) Date: Sat Oct 4 06:10:55 2008 Subject: top/ps CPU percentage broken on 7.1-PRERELEASE? (works with SCHED_4BSD) In-Reply-To: <20081003093937.GA4944@osiris.chen.org.nz> References: <200810031003.14400.shoesoft@gmx.net> <20081003093937.GA4944@osiris.chen.org.nz> Message-ID: <200810040810.42363.shoesoft@gmx.net> On Friday 03 October 2008 11:39:37 Jonathan Chen wrote: > On Fri, Oct 03, 2008 at 10:03:13AM +0200, Stefan Ehmann wrote: > > The CPU % displayed by top/ps for single processes seem to be broken > > here. > > > > E.g. for a simple shell loop: > > top starts displaying around 20% for bash. Within some seconds it > > converges to 0%. > > > > ps values seem to be consistent with top. > > > > The value in the time column seems to be correct. On every refresh it > > increases by 2s. > > > > last pid: 19353; load averages: 0.99, 0.90, 0.76 up 0+00:37:29 > > 09:07:00 > > 119 processes: 2 running, 114 sleeping, 1 stopped, 2 zombie > > CPU: 98.5% user, 0.0% nice, 1.1% system, 0.4% interrupt, 0.0% idle > > Mem: 376M Active, 407M Inact, 144M Wired, 47M Cache, 110M Buf, 13M Free > > Swap: 1280M Total, 1280M Free > > > > PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND > > 19352 stefan 1 99 0 4432K 2080K RUN 0:03 15.48% bash > > > > All other process are using 0% CPU. > > > > I did a buildworld/kernel yesterday to be sure everything is in sync. I > > have CURRENT on a different hard disk. Haven't seen the problem there. > > Are there any relevant fixes that weren't MFCed? > > > > Does anyone else see this? This is a single CPU i386 machine. > > Yes, my Java processes now run at 800% at times on my dual processor > AMD64 system. I've seen this behaviour too some time ago. Don't know if it's related to what I see. I recompiled my kernel with SCHED_4BSD and things work fine. So it seems to be a SCHED_ULE issue. From danny at cs.huji.ac.il Sat Oct 4 06:40:48 2008 From: danny at cs.huji.ac.il (Danny Braniss) Date: Sat Oct 4 06:40:56 2008 Subject: bad NFS/UDP performance In-Reply-To: References: <20080926081806.GA19055@icarus.home.lan> <20080926095230.GA20789@icarus.home.lan> Message-ID: > > On Fri, 3 Oct 2008, Danny Braniss wrote: > > >> On Fri, 3 Oct 2008, Danny Braniss wrote: > >> > >>> gladly, but have no idea how to do LOCK_PROFILING, so some pointers would > >>> be helpfull. > >> > >> The LOCK_PROFILING(9) man page isn't a bad starting point -- I find that > >> the defaults work fine most of the time, so just use them. Turn the enable > >> syscl on just before you begin a run, and turn it off immediately > >> afterwards. Make sure to reset between reruns (rebooting to a new kernel > >> is fine too!). > > > > in ftp://ftp.cs.huji.ac.il/users/danny/lock.prof > > there 3 files: > > 7.1-100 host connected at 100 running -prerelease > > 7.1-1000 same but connected at 1000 > > 7.0-1000 -stable with your 'patch' > > at 100 my benchmark didn't suffer from the profiling, average was about 9. > > at 1000 the benchmark got realy hit, average was around 12 for the patched, > > and 4 for the unpatched (less than at 100). > > Interesting. A bit of post-processing: > > robert@fledge:/tmp> cat 7.1-1000 | awk -F' ' '{print $3" "$9}' | sort -n | > tail -10 > 2413283 /r+d/7/sys/kern/kern_mutex.c:141 > 2470096 /r+d/7/sys/nfsclient/nfs_socket.c:1218 > 2676282 /r+d/7/sys/net/route.c:293 > 2754866 /r+d/7/sys/kern/vfs_bio.c:1468 > 3196298 /r+d/7/sys/nfsclient/nfs_bio.c:1664 > 3318742 /r+d/7/sys/net/route.c:1584 > 3711139 /r+d/7/sys/dev/bge/if_bge.c:3287 > 3753518 /r+d/7/sys/net/if_ethersubr.c:405 > 3961312 /r+d/7/sys/nfsclient/nfs_subs.c:1066 > 10688531 /r+d/7/sys/dev/bge/if_bge.c:3726 > robert@fledge:/tmp> cat 7.0-1000 | awk -F' ' '{print $3" "$9}' | sort -n | > tail -10 > 468631 /r+d/hunt/src/sys/nfsclient/nfs_nfsiod.c:286 > 501989 /r+d/hunt/src/sys/nfsclient/nfs_vnops.c:1148 > 631587 /r+d/hunt/src/sys/nfsclient/nfs_socket.c:1198 > 701155 /r+d/hunt/src/sys/nfsclient/nfs_socket.c:1258 > 718211 /r+d/hunt/src/sys/kern/kern_mutex.c:141 > 1118711 /r+d/hunt/src/sys/nfsclient/nfs_bio.c:1664 > 1169125 /r+d/hunt/src/sys/nfsclient/nfs_subs.c:1066 > 1222867 /r+d/hunt/src/sys/kern/vfs_bio.c:1468 > 3876072 /r+d/hunt/src/sys/netinet/udp_usrreq.c:545 > 5198927 /r+d/hunt/src/sys/netinet/udp_usrreq.c:864 > > The first set above is with the unmodified 7-STABLE tree, the second with a > reversion of read locking on the UDP inpcb. The big blinking sign of interest > is that the bge interface lock is massively contended in the first set of > output, and basically doesn't appear in the second. There are various reasons > bge could stand out quite so much -- one possibly is that previously, the udp > lock serialized all access to the interface from the send code, preventing the > send and receive paths from contending. > > A few things to try: > > - Let's look compare the context switch rates on the two benchmarks. Could > you run vmstat and look at the cpu cs line during the benchmarks and see how > similar the two are as the benchmarks run? You'll want to run it with > vmstat -w 1 and collect several samples per benchmark, since we're really > interested in the distribution rather than an individual sample. > > - Is there any chance you could drop an if_em card into the same box and run > the identical benchmarks with and without LOCK_PROFILING to see whether it > behaves differently than bge when the patch is applied? if_em's interrupt > handling is quite different, and may significantly affect lock use, and > hence contention. at the moment, the best I can do is run it on a different hardware that has if_em, the results are in ftp://ftp.cs.huji.ac.il/users/danny/lock.prof/7.1-1000.em the benchmark ran better with the Intel NIC, averaged UDP 54MB/s, TCP 53MB/s (I get the same numbers with an older kernel). danny From bsd24x7 at yahoo.com Sat Oct 4 11:44:21 2008 From: bsd24x7 at yahoo.com (Jeff Richards) Date: Sat Oct 4 11:44:28 2008 Subject: 'at now' not working as expected Message-ID: <884679.22561.qm@web110112.mail.gq1.yahoo.com> When I try to schedule something immediately with an 'at now' command it appears to queue up but can wait multiple minutes before actually executing. Is there something I have missed with FreeBSD's version of at?? I've used 'at now' with AIX, Linux, and OpenBSD and it immediately executes for those systems. I am running FreeBSD 7.0 stable. Thanks in advance. From mad at madpilot.net Sat Oct 4 12:04:13 2008 From: mad at madpilot.net (Guido Falsi) Date: Sat Oct 4 12:04:20 2008 Subject: 'at now' not working as expected In-Reply-To: <884679.22561.qm@web110112.mail.gq1.yahoo.com> References: <884679.22561.qm@web110112.mail.gq1.yahoo.com> Message-ID: <48E75BB7.2060206@madpilot.net> Jeff Richards wrote: > When I try to schedule something immediately with an 'at now' command it appears to queue up but can wait multiple minutes before actually executing. > > Is there something I have missed with FreeBSD's version of at? I've used 'at now' with AIX, Linux, and OpenBSD and it immediately executes for those systems. > > I am running FreeBSD 7.0 stable. atrun is launched from crontab with a 5 minute granularity. So I think that at now can launch command with at most a 5 minutes delay. If this is a problem you can make atrun be launched every minute reconfiguring the crontab and you will wait at mosta one minute. This is explained in the at(1) man page. I don't know about other systems at setup. -- Guido Falsi From bu7cher at yandex.ru Sat Oct 4 15:38:26 2008 From: bu7cher at yandex.ru (Andrey V. Elsukov) Date: Sat Oct 4 15:47:28 2008 Subject: Request for testing: ata(4) MFC Message-ID: <676151223134689@webmail38.yandex.ru> Hi, All. I prepared patch to make MFC of ata(4) driver into RELENG_7 before 7.1-RELEASE. Depending on results of the testing patch will be commited or not (if some regressions will be detected). So if you want or just can test it, please try and report here. -- WBR, Andrey V. Elsukov -------------- next part -------------- A non-text attachment was scrubbed... Name: ata.diff Type: application/octet-stream Size: 174223 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20081004/7f234b8e/ata-0001.obj From eirik at nynorsk.no Sat Oct 4 19:56:34 2008 From: eirik at nynorsk.no (=?ISO-8859-1?Q?Eirik_Wix=F8e_Svela?=) Date: Sat Oct 4 19:56:41 2008 Subject: Is FreeBSD a suitable choice for a MacBook? Message-ID: <48E7BD60.80001@nynorsk.no> I have an Apple MacBook with an Intel Core 2 Duo processor (November 2007 edition, cf. the Wikipedia article for specifications), and I have been considering switching to one of the free UNIX clones for some time now. I understand that Ubuntu GNU/Linux is supposed to work well on this kind of machine, but I would rather use some variant of BSD if that is a viable alternative. I would therefore like to ask you whether anyone here has any experience with FreeBSD, either 7.0-RELEASE or any other version, that they would like to share so I might know what to expect if I choose to go through with this. I have some time on my hands the next couple of weeks, so I am prepared to spend some days tweaking things to work if it is worth the effort, but if it isn't, I might as well take Ubuntu for a spin or do a clean install of Mac OS X. Best regards Eirik W. Svela OpenPGP key ID 0x46DCA4C4 From koitsu at FreeBSD.org Sun Oct 5 00:48:11 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Sun Oct 5 00:48:19 2008 Subject: Request for testing: ata(4) MFC In-Reply-To: <676151223134689@webmail38.yandex.ru> References: <676151223134689@webmail38.yandex.ru> Message-ID: <20081005004808.GA70137@icarus.home.lan> On Sat, Oct 04, 2008 at 07:38:09PM +0400, Andrey V. Elsukov wrote: > I prepared patch to make MFC of ata(4) driver into RELENG_7 > before 7.1-RELEASE. Depending on results of the testing patch > will be commited or not (if some regressions will be detected). > So if you want or just can test it, please try and report here. I will give this patch a try on the following hardware: * Supermicro P4SCE running RELENG_7 i386 - Intel ICH5R -- 1 disk attached (OS disk) - I can add a 2nd disk to this box no problem - Intel MatrixRAID capability (RAID-0 or RAID-1) - Hot-swap capable * Supermicro PDSMi+ running RELENG_7 amd64 - Intel ICH7R -- 1 disk attached (OS disk) - Promise TX4310 -- 4 disks attached (ZFS raidz1 pool) - Hot-swap capable I'll begin testing on the P4SCE box because I'm a little sensitive about potential data loss on the PDSMi+ system. :-) Also, does your patch include any fixes (intentional or inadvertent) for Intel MatrixRAID? This has been a sore spot for FreeBSD for quite some time, and I'm curious to know if that has been fixed. P.S. -- Mandatory plug: don't forget about kern/127717 :-) -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From dkelly at hiwaay.net Sun Oct 5 06:16:44 2008 From: dkelly at hiwaay.net (David Kelly) Date: Sun Oct 5 06:16:51 2008 Subject: Is FreeBSD a suitable choice for a MacBook? In-Reply-To: <48E7BD60.80001@nynorsk.no> References: <48E7BD60.80001@nynorsk.no> Message-ID: <83D0ECC4-B5F1-49E5-B437-52B3753F68F4@hiwaay.net> On Oct 4, 2008, at 2:00 PM, Eirik Wix?e Svela wrote: > I have an Apple MacBook with an Intel Core 2 Duo processor (November > 2007 edition, cf. the Wikipedia article for specifications), and I > have > been considering switching to one of the free UNIX clones for some > time > now. Why? > I understand that Ubuntu GNU/Linux is supposed to work well on this > kind of machine, but I would rather use some variant of BSD if that > is a > viable alternative. MacOS X *is* a genuine recognized variant of BSD. > I would therefore like to ask you whether anyone here has any > experience > with FreeBSD, either 7.0-RELEASE or any other version, that they would > like to share so I might know what to expect if I choose to go through > with this. I have some time on my hands the next couple of weeks, so I > am prepared to spend some days tweaking things to work if it is worth > the effort, but if it isn't, I might as well take Ubuntu for a spin or > do a clean install of Mac OS X. You sound as if you just got the machine and haven't given MacOS X a chance. Give MacOS X a chance. Download (if its not on your MacOS X install DVD) X Code, and Apple X11. -- David Kelly N4HHE, dkelly@HiWAAY.net ======================================================================== Whom computers would destroy, they must first drive mad. From bfrancom at gmail.com Sun Oct 5 07:33:22 2008 From: bfrancom at gmail.com (Ben Francom) Date: Sun Oct 5 07:33:30 2008 Subject: Is FreeBSD a suitable choice for a MacBook? In-Reply-To: <83D0ECC4-B5F1-49E5-B437-52B3753F68F4@hiwaay.net> References: <48E7BD60.80001@nynorsk.no> <83D0ECC4-B5F1-49E5-B437-52B3753F68F4@hiwaay.net> Message-ID: >> I have an Apple MacBook with an Intel Core 2 Duo processor (November >> 2007 edition, cf. the Wikipedia article for specifications), and I have >> been considering switching to one of the free UNIX clones for some time >> now. > > Why? Might I suggest: DRM, Vendor lock-in, $128 upgrade every 2 years, and crippled debugging tools. From alfred at freebsd.org Sun Oct 5 07:56:14 2008 From: alfred at freebsd.org (Alfred Perlstein) Date: Sun Oct 5 07:56:20 2008 Subject: trying to track down UFS "dup alloc" message on iSCSI In-Reply-To: <48E5AD16.5000101@modulus.org> References: <48E5AD16.5000101@modulus.org> Message-ID: <20081005075613.GW36572@elvis.mu.org> Hey Andrew, can you instrument the IO code a bit? It's possible that the iscsi stack is returning an error that UFS isn't catching. Or it's possible that iscsi stack is failing to return an error and just dropping the data packet. That could mean that UFS is assuming that the write is going through, but isn't either because it's not catching the error, or that iscsi is lying to it. -Alfred * Andrew Snow [081002 22:28] wrote: > > > I am playing with an iSCSI device on FreeBSD client running UFS2 on the > device over a LAN. Everything works well until I reboot the iSCSI > server - the client pauses for a minute or so then continues working > after iSCSI server comes back. No I/O errors are reported. Everything > seems to work fine for a little while! > > But shortly afterwards, I get a panic with the message > > panic: ffs_valloc: dup alloc > > > It seems related to the length of the delay the iSCSI device is paused - > restarting the iSCSI target daemon process doesn't cause the problem but > rebooting the whole target box does cause it. > > 1. Could this be related to the patch Matt Dillon created years ago > which I found here? > > http://leaf.dragonflybsd.org/mailarchive/bugs/2005-01/msg00093.html > > > 2. Can anyone think of any other reason this might happen? I know I am > stretching UFS to the limits here, expecting it to pause and restart > after more than a minute of locked disk :-) However, since all I/O > eventually complete successfully and no errors are reported, I find it > suspicious. > > > Cheers > > - Andrew > > > ps. running latest iSCSI code 2.1 on latest 7-STABLE box. > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" -- - Alfred Perlstein From alfred at freebsd.org Sun Oct 5 07:59:56 2008 From: alfred at freebsd.org (Alfred Perlstein) Date: Sun Oct 5 08:00:04 2008 Subject: fxp performance with POLLING In-Reply-To: <48E62ABA.6070901@kkip.pl> References: <48E62ABA.6070901@kkip.pl> Message-ID: <20081005075956.GX36572@elvis.mu.org> * Bartosz Stec [081003 07:23] wrote: > Hello again :) > > With POLLING enabled I experience about 10%-25% performance drop when > copying files over network. Tested with both SAMBA and NFS. Is it normal? > > FreeBSD 7.1-PRERELEASE #0: Sat Sep 6 01:52:12 CEST 2008 > fxp0: port 0xc800-0xc83f mem > 0xe1021000-0xe1021fff irq 20 at device 8.0 on pci1 > > # ifconfig fxp0 > fxp0: flags=9843 > metric 0 mtu 1500 > options=8 > ether 00:20:ed:42:87:13 > inet 192.168.0.2 netmask 0xffffff00 broadcast 192.168.0.255 > media: Ethernet autoselect (100baseTX ) > status: active > > BTW overall SAMBA performance still sucks on 7.1-pre as much as on > RELENG_5 ...:( - 7.5 MB/s peak. 7.5MB is 75% effeciency of a 100mbit card. Not amazing, but not "sucks". Where do you see faster performance? Between windows machines on the same hardware or linux server? -- - Alfred Perlstein From glz at hidden-powers.com Sun Oct 5 09:06:31 2008 From: glz at hidden-powers.com (Goran Lowkrantz) Date: Sun Oct 5 09:06:38 2008 Subject: Request for testing: ata(4) MFC In-Reply-To: <676151223134689@webmail38.yandex.ru> References: <676151223134689@webmail38.yandex.ru> Message-ID: --On Saturday, October 04, 2008 19:38 +0400 "Andrey V. Elsukov" wrote: > Hi, All. > > I prepared patch to make MFC of ata(4) driver into RELENG_7 > before 7.1-RELEASE. Depending on results of the testing patch > will be commited or not (if some regressions will be detected). > So if you want or just can test it, please try and report here. > Installed and tested with no ill effects on an ASUS M2N-VM DVI board. Still need to manually apply the attached patch, picked up on the list a while ago, to have the built-in SATA controller detected and recognized as AHCI capable. Cheers, Goran Attachments: lspci output of controller under test. original patch for controller. updated patch against tested patchset. --- "There is hopeful symbolism in the fact that flags do not wave in a vacuum." -- Arthur C. Clarke -------------- next part -------------- 00:09.0 SATA controller [0106]: nVidia Corporation MCP67 AHCI Controller [10de:0554] (rev a2) (prog-if 01 [AHCI 1.0]) Subsystem: ASUSTeK Computer Inc. Unknown device [1043:82b3] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- -------------- next part -------------- Index: src/sys/dev/ata/ata-chipset.c =================================================================== RCS file: /ncvs/src/sys/dev/ata/ata-chipset.c,v retrieving revision 1.225 diff -u -p -r1.225 ata-chipset.c --- src/sys/dev/ata/ata-chipset.c 15 Aug 2008 10:55:11 -0000 1.225 +++ src/sys/dev/ata/ata-chipset.c 23 Sep 2008 05:06:28 -0000 @@ -3372,7 +3372,9 @@ ata_nvidia_ident(device_t dev) { ATA_NFORCE_MCP61_S3, 0, 0, NV4|NVQ, ATA_SA300, "nForce MCP61" }, { ATA_NFORCE_MCP65, 0, AMDNVIDIA, NVIDIA, ATA_UDMA6, "nForce MCP65" }, { ATA_NFORCE_MCP67, 0, AMDNVIDIA, NVIDIA, ATA_UDMA6, "nForce MCP67" }, + { ATA_NFORCE_MCP67_A1, 0, 0, NVAHCI, ATA_SA300, "nForce MCP67" }, { ATA_NFORCE_MCP73, 0, AMDNVIDIA, NVIDIA, ATA_UDMA6, "nForce MCP73" }, + { ATA_NFORCE_MCP73_A1, 0, 0, NVAHCI, ATA_SA300, "nForce MCP73" }, { ATA_NFORCE_MCP77, 0, AMDNVIDIA, NVIDIA, ATA_UDMA6, "nForce MCP77" }, { 0, 0, 0, 0, 0, 0}} ; @@ -3380,7 +3382,12 @@ ata_nvidia_ident(device_t dev) return ENXIO; ata_set_desc(dev); - ctlr->chipinit = ata_nvidia_chipinit; + + if (ctlr->chip->cfg2 == NVAHCI) + ctlr->chipinit = ata_ahci_chipinit; + else + ctlr->chipinit = ata_nvidia_chipinit; + return 0; } Index: src/sys/dev/ata/ata-pci.h =================================================================== RCS file: /ncvs/src/sys/dev/ata/ata-pci.h,v retrieving revision 1.89 diff -u -p -r1.89 ata-pci.h --- src/sys/dev/ata/ata-pci.h 10 Jul 2008 21:36:53 -0000 1.89 +++ src/sys/dev/ata/ata-pci.h 23 Sep 2008 05:06:28 -0000 @@ -243,8 +243,10 @@ struct ata_connect_task { #define ATA_NFORCE_MCP61_S2 0x03f610de #define ATA_NFORCE_MCP61_S3 0x03f710de #define ATA_NFORCE_MCP65 0x044810de +#define ATA_NFORCE_MCP67_A1 0x055010de #define ATA_NFORCE_MCP67 0x056010de #define ATA_NFORCE_MCP73 0x056c10de +#define ATA_NFORCE_MCP73_A1 0x07f810de #define ATA_NFORCE_MCP77 0x075910de #define ATA_PROMISE_ID 0x105a @@ -450,6 +452,7 @@ struct ata_connect_task { #define NVIDIA 0x0004 #define NV4 0x0010 #define NVQ 0x0020 +#define NVAHCI 0x0040 #define VIACLK 0x0100 #define VIABUG 0x0200 #define VIABAR 0x0400 -------------- next part -------------- A non-text attachment was scrubbed... Name: ata_nvidia_ahci-20081004.diff Type: application/octet-stream Size: 1800 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20081005/f1ba9188/ata_nvidia_ahci-20081004.obj From kmacy at freebsd.org Sun Oct 5 09:31:10 2008 From: kmacy at freebsd.org (Kip Macy) Date: Sun Oct 5 09:31:17 2008 Subject: Is FreeBSD a suitable choice for a MacBook? In-Reply-To: <83D0ECC4-B5F1-49E5-B437-52B3753F68F4@hiwaay.net> References: <48E7BD60.80001@nynorsk.no> <83D0ECC4-B5F1-49E5-B437-52B3753F68F4@hiwaay.net> Message-ID: <3c1674c90810050210n5be68940me0b7214001f6fd1d@mail.gmail.com> > > You sound as if you just got the machine and haven't given MacOS X a chance. > Give MacOS X a chance. Download (if its not on your MacOS X install DVD) X > Code, and Apple X11. > X11 is barely usable under Leopard. Apps crash regularly and full-screen doesn't work. He may simply want to be able to boot in to FreeBSD as well. Cheers. From marius at alchemy.franken.de Sun Oct 5 11:22:52 2008 From: marius at alchemy.franken.de (Marius Strobl) Date: Sun Oct 5 11:22:59 2008 Subject: Request for testing: ata(4) MFC In-Reply-To: <676151223134689@webmail38.yandex.ru> References: <676151223134689@webmail38.yandex.ru> Message-ID: <20081005110436.GA95778@alchemy.franken.de> On Sat, Oct 04, 2008 at 07:38:09PM +0400, Andrey V. Elsukov wrote: > Hi, All. > > I prepared patch to make MFC of ata(4) driver into RELENG_7 > before 7.1-RELEASE. Depending on results of the testing patch > will be commited or not (if some regressions will be detected). > So if you want or just can test it, please try and report here. One regression of the post-PM code is that support for some Promise controllers is broken in that probing drives causes a hang. In my case it's a FasTrak S150 TX4 with a PDC20319 but there are also other variants affected, see f.e.: http://lists.freebsd.org/pipermail/freebsd-current/2008-May/085923.html Marius From eirik at nynorsk.no Sun Oct 5 11:25:36 2008 From: eirik at nynorsk.no (=?ISO-8859-1?Q?Eirik_Wix=F8e_Svela?=) Date: Sun Oct 5 11:25:42 2008 Subject: Is FreeBSD a suitable choice for a MacBook? In-Reply-To: <83D0ECC4-B5F1-49E5-B437-52B3753F68F4@hiwaay.net> References: <48E7BD60.80001@nynorsk.no> <83D0ECC4-B5F1-49E5-B437-52B3753F68F4@hiwaay.net> Message-ID: <48E8A433.40108@nynorsk.no> Thank you for your reply, David. You seem to be answering a question I did not ask, but allow me to respond briefly in any case: I have been using the operating system since January, and I am full aware of its line of inheritance as well as the UNIX 03 certification, and I have no major beef with it for everyday purposes. However, for all its ease of use and outstanding graphical user interface, I still find that its crossbred nature makes for a somewhat untidy system when dealing with nitty-gritty UNIX tasks such as enabling and configuring the firewall, configuring the system for maximum security (the default file permissions allow everyone to watch what's inside everyone else's home directories, for instance), installing an application by hand and so on. I also much prefer the free software movement and its principles to Apple and its "principles". Now, could someone answer my original question? Regards From wolfgang at lyxys.ka.sub.org Sun Oct 5 11:44:28 2008 From: wolfgang at lyxys.ka.sub.org (Wolfgang Zenker) Date: Sun Oct 5 11:44:36 2008 Subject: Upgrading to 7.x : make check-old In-Reply-To: <48E69A3B.7090904@langille.org> References: <48E69A3B.7090904@langille.org> Message-ID: <20081005114425.GA3978@lyxys.ka.sub.org> Hi, * Dan Langille [081004 00:18]: > Folks: > I have upgraded a server from 6.3 to 7.0. That went rather smoothly. I > have a question about removing old libraries via make delete-old. > Given the list of old libraries shown at the end of this URL: > http://www.freebsddiary.org/upgrade-6.3-to-7.0.php > Is that list more or less expected? From what I can tell, it's pretty > safe to now do a make delete-old-libs. Do you concur? that depends on you having updated all ports/packages as well as the base system. I think I used a tool that checks which shared libraries are used by which program but can't remember how it was called; but anyway you can simply use ldd on your binaries in /usr/local/* to check if any of them still use one of the old libs. Wolfgang From sos at FreeBSD.ORG Sun Oct 5 11:51:25 2008 From: sos at FreeBSD.ORG (=?ISO-8859-1?Q?S=F8ren_Schmidt?=) Date: Sun Oct 5 11:51:32 2008 Subject: Request for testing: ata(4) MFC In-Reply-To: <20081005110436.GA95778@alchemy.franken.de> References: <676151223134689@webmail38.yandex.ru> <20081005110436.GA95778@alchemy.franken.de> Message-ID: <2F4F7D82-D674-4B2D-AC3A-315A6E2CD2E4@FreeBSD.ORG> On 5Oct, 2008, at 13:04 , Marius Strobl wrote: > On Sat, Oct 04, 2008 at 07:38:09PM +0400, Andrey V. Elsukov wrote: >> Hi, All. >> >> I prepared patch to make MFC of ata(4) driver into RELENG_7 >> before 7.1-RELEASE. Depending on results of the testing patch >> will be commited or not (if some regressions will be detected). >> So if you want or just can test it, please try and report here. > > One regression of the post-PM code is that support for some > Promise controllers is broken in that probing drives causes > a hang. In my case it's a FasTrak S150 TX4 with a PDC20319 > but there are also other variants affected, see f.e.: > http://lists.freebsd.org/pipermail/freebsd-current/2008-May/ > 085923.html I'm aware of the Promise problems and its on my TODO list, just havn't gotten around to it yet. When I have the current floating patch for splitting up ata-chipset.c in vendor specific files I'll have a go on that report (makes it lots easier to work with). -S?ren From swhetzel at gmail.com Sun Oct 5 11:52:04 2008 From: swhetzel at gmail.com (Scot Hetzel) Date: Sun Oct 5 11:52:11 2008 Subject: Upgrading to 7.x : make check-old In-Reply-To: <20081005114425.GA3978@lyxys.ka.sub.org> References: <48E69A3B.7090904@langille.org> <20081005114425.GA3978@lyxys.ka.sub.org> Message-ID: <790a9fff0810050452u3f83840fg313b86cee3f9cf02@mail.gmail.com> On 10/5/08, Wolfgang Zenker wrote: > > Is that list more or less expected? From what I can tell, it's pretty > > safe to now do a make delete-old-libs. Do you concur? > > > that depends on you having updated all ports/packages as well as the > base system. I think I used a tool that checks which shared libraries are > used by which program but can't remember how it was called; but anyway you > can simply use ldd on your binaries in /usr/local/* to check if any of > them still use one of the old libs. > I have used the devel/libcheck utility to check for missing libraries after upgrading the installed ports. Scot From wolfgang at lyxys.ka.sub.org Sun Oct 5 11:58:25 2008 From: wolfgang at lyxys.ka.sub.org (Wolfgang Zenker) Date: Sun Oct 5 11:58:32 2008 Subject: Upgrading to 7.x : make check-old Message-ID: <20081005115823.GA4732@lyxys.ka.sub.org> [forgot to send to list first time] Hi, * Scot Hetzel [081005 13:52]: > On 10/5/08, Wolfgang Zenker wrote: >> > Is that list more or less expected? From what I can tell, it's pretty >> > safe to now do a make delete-old-libs. Do you concur? >> that depends on you having updated all ports/packages as well as the >> base system. I think I used a tool that checks which shared libraries are >> used by which program but can't remember how it was called; but anyway you >> can simply use ldd on your binaries in /usr/local/* to check if any of >> them still use one of the old libs. > I have used the devel/libcheck utility to check for missing libraries > after upgrading the installed ports. I guess you mean the sysutils/libchk utility and that was the one I used. Wolfgang From unicorn at blackhats.org Sun Oct 5 12:08:49 2008 From: unicorn at blackhats.org (Quux) Date: Sun Oct 5 12:08:55 2008 Subject: Is FreeBSD a suitable choice for a MacBook? In-Reply-To: <48E7BD60.80001@nynorsk.no> References: <48E7BD60.80001@nynorsk.no> Message-ID: <0AC44BDA-B3CF-4240-9732-12E411260104@blackhats.org> On 4 Oct 2008, at 21:00, Eirik Wix?e Svela wrote: > I have an Apple MacBook with an Intel Core 2 Duo processor (November > 2007 edition, cf. the Wikipedia article for specifications), and I > have > been considering switching to one of the free UNIX clones for some > time > now. I understand that Ubuntu GNU/Linux is supposed to work well on > this > kind of machine, but I would rather use some variant of BSD if that > is a > viable alternative. Only used FreeBSD (and several Linux variations and Windows varieties) on my Macbook Pro, but none of these as the boot operating system. All of these do however run as expected in a virtual environment like Parallels. > I would therefore like to ask you whether anyone here has any > experience > with FreeBSD, either 7.0-RELEASE or any other version, that they would > like to share so I might know what to expect if I choose to go through > with this. I have some time on my hands the next couple of weeks, so I > am prepared to spend some days tweaking things to work if it is worth > the effort, but if it isn't, I might as well take Ubuntu for a spin or > do a clean install of Mac OS X. > > Best regards > Eirik W. Svela > OpenPGP key ID 0x46DCA4C4 > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org > " Ciao, Hans. From xi at borderworlds.dk Sun Oct 5 14:25:17 2008 From: xi at borderworlds.dk (Christian Laursen) Date: Sun Oct 5 14:25:25 2008 Subject: Is FreeBSD a suitable choice for a MacBook? In-Reply-To: <48E7BD60.80001@nynorsk.no> ("Eirik =?iso-8859-1?Q?Wix=F8e?= Svela"'s message of "Sat\, 04 Oct 2008 21\:00\:48 +0200") References: <48E7BD60.80001@nynorsk.no> Message-ID: Eirik Wix?e Svela writes: > I have an Apple MacBook with an Intel Core 2 Duo processor (November > 2007 edition, cf. the Wikipedia article for specifications), and I have > been considering switching to one of the free UNIX clones for some time > now. I understand that Ubuntu GNU/Linux is supposed to work well on this > kind of machine, but I would rather use some variant of BSD if that is a > viable alternative. I have a MacBook running FreeBSD. IIRC I bought it in January 2008 so it's probably the same model as yours. > I would therefore like to ask you whether anyone here has any experience > with FreeBSD, either 7.0-RELEASE or any other version, that they would > like to share so I might know what to expect if I choose to go through > with this. I have some time on my hands the next couple of weeks, so I > am prepared to spend some days tweaking things to work if it is worth > the effort, but if it isn't, I might as well take Ubuntu for a spin or > do a clean install of Mac OS X. I have made a few notes here: http://borderworlds.dk/notes/freebsd-macbook.html I just used boot camp and did a pretty standard install. I would recommend installing a 7.1-BETA release to have the wired ethernet working from the beginning. -- Christian Laursen From swhetzel at gmail.com Sun Oct 5 15:26:39 2008 From: swhetzel at gmail.com (Scot Hetzel) Date: Sun Oct 5 15:26:46 2008 Subject: Upgrading to 7.x : make check-old In-Reply-To: <20081005115823.GA4732@lyxys.ka.sub.org> References: <20081005115823.GA4732@lyxys.ka.sub.org> Message-ID: <790a9fff0810050826r73e34d73pa90f2206d23c33b7@mail.gmail.com> On 10/5/08, Wolfgang Zenker wrote: > [forgot to send to list first time] > > > Hi, > > * Scot Hetzel [081005 13:52]: > > On 10/5/08, Wolfgang Zenker wrote: > >> > Is that list more or less expected? From what I can tell, it's pretty > >> > safe to now do a make delete-old-libs. Do you concur? > > >> that depends on you having updated all ports/packages as well as the > >> base system. I think I used a tool that checks which shared libraries are > >> used by which program but can't remember how it was called; but anyway you > >> can simply use ldd on your binaries in /usr/local/* to check if any of > >> them still use one of the old libs. > > > I have used the devel/libcheck utility to check for missing libraries > > after upgrading the installed ports. > > I guess you mean the sysutils/libchk utility and that was the one I used. > sysutils/libchk is the one I had used. Scot From dan at langille.org Sun Oct 5 21:06:33 2008 From: dan at langille.org (Dan Langille) Date: Sun Oct 5 21:06:40 2008 Subject: Upgrading to 7.x : make check-old In-Reply-To: <20081005114425.GA3978@lyxys.ka.sub.org> References: <48E69A3B.7090904@langille.org> <20081005114425.GA3978@lyxys.ka.sub.org> Message-ID: <48E92C0D.60008@langille.org> Wolfgang Zenker wrote: > Hi, > > * Dan Langille [081004 00:18]: >> Folks: > >> I have upgraded a server from 6.3 to 7.0. That went rather smoothly. I >> have a question about removing old libraries via make delete-old. > >> Given the list of old libraries shown at the end of this URL: > >> http://www.freebsddiary.org/upgrade-6.3-to-7.0.php > >> Is that list more or less expected? From what I can tell, it's pretty >> safe to now do a make delete-old-libs. Do you concur? > > that depends on you having updated all ports/packages as well as the > base system. I did that. I made sure of that. > I think I used a tool that checks which shared libraries are > used by which program but can't remember how it was called; but anyway you > can simply use ldd on your binaries in /usr/local/* to check if any of > them still use one of the old libs. Is this correct: Worst case: some ports stop running? If so, I can live with that. :o Thank you. From dan at langille.org Sun Oct 5 21:07:29 2008 From: dan at langille.org (Dan Langille) Date: Sun Oct 5 21:07:36 2008 Subject: Upgrading to 7.x : make check-old In-Reply-To: <790a9fff0810050452u3f83840fg313b86cee3f9cf02@mail.gmail.com> References: <48E69A3B.7090904@langille.org> <20081005114425.GA3978@lyxys.ka.sub.org> <790a9fff0810050452u3f83840fg313b86cee3f9cf02@mail.gmail.com> Message-ID: <48E92C48.4010509@langille.org> Scot Hetzel wrote: > On 10/5/08, Wolfgang Zenker wrote: >> > Is that list more or less expected? From what I can tell, it's pretty >> > safe to now do a make delete-old-libs. Do you concur? >> >> >> that depends on you having updated all ports/packages as well as the >> base system. I think I used a tool that checks which shared libraries are >> used by which program but can't remember how it was called; but anyway you >> can simply use ldd on your binaries in /usr/local/* to check if any of >> them still use one of the old libs. >> > > I have used the devel/libcheck utility to check for missing libraries > after upgrading the installed ports. Noted. Did that. I may compare that to the ldd output. From rwatson at FreeBSD.org Sun Oct 5 22:21:06 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Sun Oct 5 22:21:14 2008 Subject: bad NFS/UDP performance In-Reply-To: References: <20080926081806.GA19055@icarus.home.lan> <20080926095230.GA20789@icarus.home.lan> Message-ID: On Sat, 4 Oct 2008, Danny Braniss wrote: > at the moment, the best I can do is run it on a different hardware that has > if_em, the results are in > ftp://ftp.cs.huji.ac.il/users/danny/lock.prof/7.1-1000.em the > benchmark ran better with the Intel NIC, averaged UDP 54MB/s, TCP 53MB/s (I > get the same numbers with an older kernel). Dear Danny: Unfortunately, I was left slightly unclear on the comparison you are making above. Could you confirm whether or not, with if_em, you see a performance regression using UDP NFS between 7.0-RELEASE and the most recent 7.1-STABLE, and if you do, whether or not the RLOCK->WLOCK change has any effect on performance? It would be nice to know on the same hardware but at least with different hardware we get a sense of whether or not this might affect other systems or whether it's limited to a narrower set of configurations. Thanks, Robert N M Watson Computer Laboratory University of Cambridge From bu7cher at yandex.ru Mon Oct 6 05:03:32 2008 From: bu7cher at yandex.ru (Andrey V. Elsukov) Date: Mon Oct 6 05:03:39 2008 Subject: Request for testing: ata(4) MFC In-Reply-To: <20081005004808.GA70137@icarus.home.lan> References: <676151223134689@webmail38.yandex.ru> <20081005004808.GA70137@icarus.home.lan> Message-ID: <48E99C18.6070602@yandex.ru> Jeremy Chadwick wrote: > Also, does your patch include any fixes (intentional or inadvertent) for > Intel MatrixRAID? This has been a sore spot for FreeBSD for quite > some time, and I'm curious to know if that has been fixed. There is only one fix for Intel Matrix RAID: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/121899 > P.S. -- Mandatory plug: don't forget about kern/127717 :-) First of it should be commited into HEAD.. -- WBR, Andrey V. Elsukov From koitsu at FreeBSD.org Mon Oct 6 05:12:15 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Mon Oct 6 05:12:30 2008 Subject: Request for testing: ata(4) MFC In-Reply-To: <48E99C18.6070602@yandex.ru> References: <676151223134689@webmail38.yandex.ru> <20081005004808.GA70137@icarus.home.lan> <48E99C18.6070602@yandex.ru> Message-ID: <20081006051211.GA10542@icarus.home.lan> On Mon, Oct 06, 2008 at 09:03:20AM +0400, Andrey V. Elsukov wrote: > Jeremy Chadwick wrote: >> Also, does your patch include any fixes (intentional or inadvertent) for >> Intel MatrixRAID? This has been a sore spot for FreeBSD for quite >> some time, and I'm curious to know if that has been fixed. > > There is only one fix for Intel Matrix RAID: > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/121899 Ahh, yeah, I've seen that one as well. I'll apply the patch and let you know if the behaviour documented in the PR happens. >> P.S. -- Mandatory plug: don't forget about kern/127717 :-) > > First of it should be commited into HEAD.. Cool, thanks! -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From admin at kkip.pl Mon Oct 6 07:02:33 2008 From: admin at kkip.pl (Bartosz Stec) Date: Mon Oct 6 07:02:41 2008 Subject: fxp performance with POLLING In-Reply-To: <20081005075956.GX36572@elvis.mu.org> References: <48E62ABA.6070901@kkip.pl> <20081005075956.GX36572@elvis.mu.org> Message-ID: <48E9B809.5080309@kkip.pl> Alfred Perlstein wrote: > * Bartosz Stec [081003 07:23] wrote: > >> Hello again :) >> >> With POLLING enabled I experience about 10%-25% performance drop when >> copying files over network. Tested with both SAMBA and NFS. Is it normal? >> >> FreeBSD 7.1-PRERELEASE #0: Sat Sep 6 01:52:12 CEST 2008 >> fxp0: port 0xc800-0xc83f mem >> 0xe1021000-0xe1021fff irq 20 at device 8.0 on pci1 >> >> # ifconfig fxp0 >> fxp0: flags=9843 >> metric 0 mtu 1500 >> options=8 >> ether 00:20:ed:42:87:13 >> inet 192.168.0.2 netmask 0xffffff00 broadcast 192.168.0.255 >> media: Ethernet autoselect (100baseTX ) >> status: active >> >> BTW overall SAMBA performance still sucks on 7.1-pre as much as on >> RELENG_5 ...:( - 7.5 MB/s peak. >> > > 7.5MB is 75% effeciency of a 100mbit card. Not amazing, but > not "sucks". > > Where do you see faster performance? > > Between windows machines on the same hardware or linux server? > > It sucks because it is a peak performance. About 5-6 MB/s average. I tried polling only because I found some suggestions on mailing lists, that it could improve performance with SAMBA on FreeBSD. As you see at the top of this thread - not in my case :) I also tried sysctl tunings, and smb.conf settings, also suggested on maling lists, with no or very little improvements noticed. Most of suggestions unfortunately end with "change OS to Linux if you want to use SAMBA". I think I will try to change NIC to 1Gbit - hope that helps :) Or maybe there's some "FreeBSD and SAMBA tuning guide" which I didn't found? -- Bartosz Stec From koitsu at FreeBSD.org Mon Oct 6 07:17:59 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Mon Oct 6 07:18:06 2008 Subject: fxp performance with POLLING In-Reply-To: <48E9B809.5080309@kkip.pl> References: <48E62ABA.6070901@kkip.pl> <20081005075956.GX36572@elvis.mu.org> <48E9B809.5080309@kkip.pl> Message-ID: <20081006071757.GA13076@icarus.home.lan> On Mon, Oct 06, 2008 at 09:02:33AM +0200, Bartosz Stec wrote: > Alfred Perlstein wrote: >> * Bartosz Stec [081003 07:23] wrote: >> >>> Hello again :) >>> >>> With POLLING enabled I experience about 10%-25% performance drop when >>> copying files over network. Tested with both SAMBA and NFS. Is it >>> normal? >>> >>> FreeBSD 7.1-PRERELEASE #0: Sat Sep 6 01:52:12 CEST 2008 >>> fxp0: port 0xc800-0xc83f mem >>> 0xe1021000-0xe1021fff irq 20 at device 8.0 on pci1 >>> >>> # ifconfig fxp0 >>> fxp0: flags=9843 >>> metric 0 mtu 1500 >>> options=8 >>> ether 00:20:ed:42:87:13 >>> inet 192.168.0.2 netmask 0xffffff00 broadcast 192.168.0.255 >>> media: Ethernet autoselect (100baseTX ) >>> status: active >>> >>> BTW overall SAMBA performance still sucks on 7.1-pre as much as on >>> RELENG_5 ...:( - 7.5 MB/s peak. >>> >> >> 7.5MB is 75% effeciency of a 100mbit card. Not amazing, but >> not "sucks". >> >> Where do you see faster performance? >> >> Between windows machines on the same hardware or linux server? >> >> > It sucks because it is a peak performance. About 5-6 MB/s average. I > tried polling only because I found some suggestions on mailing lists, > that it could improve performance with SAMBA on FreeBSD. As you see at > the top of this thread - not in my case :) I also tried sysctl tunings, > and smb.conf settings, also suggested on maling lists, with no or very > little improvements noticed. Most of suggestions unfortunately end with > "change OS to Linux if you want to use SAMBA". I think I will try to > change NIC to 1Gbit - hope that helps :) Or maybe there's some "FreeBSD > and SAMBA tuning guide" which I didn't found? Can you please test network I/O using something like netperf or one of the other network-benchmark tools and not things like NFS or Samba which rely on disk I/O and other aspects? -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From antik at bsd.ee Mon Oct 6 07:29:35 2008 From: antik at bsd.ee (Andrei Kolu) Date: Mon Oct 6 07:29:42 2008 Subject: fxp performance with POLLING In-Reply-To: <20081006071757.GA13076@icarus.home.lan> References: <48E62ABA.6070901@kkip.pl> <20081005075956.GX36572@elvis.mu.org> <48E9B809.5080309@kkip.pl> <20081006071757.GA13076@icarus.home.lan> Message-ID: <48E9BE5F.5020709@bsd.ee> Jeremy Chadwick wrote: > On Mon, Oct 06, 2008 at 09:02:33AM +0200, Bartosz Stec wrote: > >> Alfred Perlstein wrote: >> >>> * Bartosz Stec [081003 07:23] wrote: >>> >>> >>>> Hello again :) >>>> >>>> With POLLING enabled I experience about 10%-25% performance drop when >>>> copying files over network. Tested with both SAMBA and NFS. Is it >>>> normal? >>>> >>>> FreeBSD 7.1-PRERELEASE #0: Sat Sep 6 01:52:12 CEST 2008 >>>> fxp0: port 0xc800-0xc83f mem >>>> 0xe1021000-0xe1021fff irq 20 at device 8.0 on pci1 >>>> >>>> # ifconfig fxp0 >>>> fxp0: flags=9843 >>>> metric 0 mtu 1500 >>>> options=8 >>>> ether 00:20:ed:42:87:13 >>>> inet 192.168.0.2 netmask 0xffffff00 broadcast 192.168.0.255 >>>> media: Ethernet autoselect (100baseTX ) >>>> status: active >>>> >>>> BTW overall SAMBA performance still sucks on 7.1-pre as much as on >>>> RELENG_5 ...:( - 7.5 MB/s peak. >>>> >>>> >>> 7.5MB is 75% effeciency of a 100mbit card. Not amazing, but >>> not "sucks". >>> >>> Where do you see faster performance? >>> >>> Between windows machines on the same hardware or linux server? >>> >>> >>> >> It sucks because it is a peak performance. About 5-6 MB/s average. I >> tried polling only because I found some suggestions on mailing lists, >> that it could improve performance with SAMBA on FreeBSD. As you see at >> the top of this thread - not in my case :) I also tried sysctl tunings, >> and smb.conf settings, also suggested on maling lists, with no or very >> little improvements noticed. Most of suggestions unfortunately end with >> "change OS to Linux if you want to use SAMBA". I think I will try to >> change NIC to 1Gbit - hope that helps :) Or maybe there's some "FreeBSD >> and SAMBA tuning guide" which I didn't found? >> > > Can you please test network I/O using something like netperf or one of > the other network-benchmark tools and not things like NFS or Samba > which rely on disk I/O and other aspects? > > I remember when on FreeBSD 4.x I was able to copy files from samba and to samba up to 12MB/s on 100Mbit lan. Now with FreeBSD 6.x or 7.x I can have barely 8MB/s on 100Mbit and 27MB/s on Gigabit lan. Netperf shows 900Mbit/s in any direction, small variety with different switches (ca 10% difference). From cliftonr at lava.net Mon Oct 6 07:34:24 2008 From: cliftonr at lava.net (Clifton Royston) Date: Mon Oct 6 07:34:31 2008 Subject: fxp performance with POLLING In-Reply-To: <48E9BE5F.5020709@bsd.ee> References: <48E62ABA.6070901@kkip.pl> <20081005075956.GX36572@elvis.mu.org> <48E9B809.5080309@kkip.pl> <20081006071757.GA13076@icarus.home.lan> <48E9BE5F.5020709@bsd.ee> Message-ID: <20081006073420.GA23811@lava.net> On Mon, Oct 06, 2008 at 10:29:35AM +0300, Andrei Kolu wrote: ... > I remember when on FreeBSD 4.x I was able to copy files from samba and > to samba up to 12MB/s on 100Mbit lan. This part seems unlikely, particularly as bit rates are measured in decimal millions not computer millions. 12*8*1024*1024 = 100,663,296 so that would mean not merely zero but negative packet and network overhead. -- Clifton -- Clifton Royston -- cliftonr@iandicomputing.com / cliftonr@lava.net President - I and I Computing * http://www.iandicomputing.com/ Custom programming, network design, systems and network consulting services From admin at kkip.pl Mon Oct 6 09:19:06 2008 From: admin at kkip.pl (Bartosz Stec) Date: Mon Oct 6 09:19:14 2008 Subject: fxp performance with POLLING In-Reply-To: <20081006071757.GA13076@icarus.home.lan> References: <48E62ABA.6070901@kkip.pl> <20081005075956.GX36572@elvis.mu.org> <48E9B809.5080309@kkip.pl> <20081006071757.GA13076@icarus.home.lan> Message-ID: <48E9D808.9080501@kkip.pl> Jeremy Chadwick pisze: > On Mon, Oct 06, 2008 at 09:02:33AM +0200, Bartosz Stec wrote: > >> Alfred Perlstein wrote: >> >>> * Bartosz Stec [081003 07:23] wrote: >>> >>> >>>> Hello again :) >>>> >>>> With POLLING enabled I experience about 10%-25% performance drop when >>>> copying files over network. Tested with both SAMBA and NFS. Is it >>>> normal? >>>> >>>> FreeBSD 7.1-PRERELEASE #0: Sat Sep 6 01:52:12 CEST 2008 >>>> fxp0: port 0xc800-0xc83f mem >>>> 0xe1021000-0xe1021fff irq 20 at device 8.0 on pci1 >>>> >>>> # ifconfig fxp0 >>>> fxp0: flags=9843 >>>> metric 0 mtu 1500 >>>> options=8 >>>> ether 00:20:ed:42:87:13 >>>> inet 192.168.0.2 netmask 0xffffff00 broadcast 192.168.0.255 >>>> media: Ethernet autoselect (100baseTX ) >>>> status: active >>>> >>>> BTW overall SAMBA performance still sucks on 7.1-pre as much as on >>>> RELENG_5 ...:( - 7.5 MB/s peak. >>>> >>>> >>> 7.5MB is 75% effeciency of a 100mbit card. Not amazing, but >>> not "sucks". >>> >>> Where do you see faster performance? >>> >>> Between windows machines on the same hardware or linux server? >>> >>> >>> >> It sucks because it is a peak performance. About 5-6 MB/s average. I >> tried polling only because I found some suggestions on mailing lists, >> that it could improve performance with SAMBA on FreeBSD. As you see at >> the top of this thread - not in my case :) I also tried sysctl tunings, >> and smb.conf settings, also suggested on maling lists, with no or very >> little improvements noticed. Most of suggestions unfortunately end with >> "change OS to Linux if you want to use SAMBA". I think I will try to >> change NIC to 1Gbit - hope that helps :) Or maybe there's some "FreeBSD >> and SAMBA tuning guide" which I didn't found? >> > > Can you please test network I/O using something like netperf or one of > the other network-benchmark tools and not things like NFS or Samba > which rely on disk I/O and other aspects? > > OK It was first time i was using nerperf so I'm not sure I did it correctly. I installed netperf port on SAMBA serwer (IP 192.168.0.2), and also download windows binary to windows xp machine (IP 192.168.0.10). All tests ran for one minute. First test - netperf on FreeBSD and netserver on Windows: # netperf -l 60 -t TCP_STREAM -H 192.168.0.10 TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.0.10 (192.168.0.10) port 0 AF_INET Recv Send Send Socket Socket Message Elapsed Size Size Size Time Throughput bytes bytes bytes secs. 10^6bits/sec 8192 32768 32768 60.00 93.97 # netperf -l 60 -t TCP_SENDFILE -H 192.168.0.10 TCP SENDFILE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.0.10 (192.168.0.10) port 0 AF_INET Recv Send Send Socket Socket Message Elapsed Size Size Size Time Throughput bytes bytes bytes secs. 10^6bits/sec 8192 32768 32768 60.00 93.45 # netperf -l 60 -t TCP_RR -H 192.168.0.10 TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.0.10 (192.168.0.10) port 0 AF_INET Local /Remote Socket Size Request Resp. Elapsed Trans. Send Recv Size Size Time Rate bytes Bytes bytes bytes secs. per sec 32768 65536 1 1 60.00 2433.99 8192 8192 # ifconfig fxp0 fxp0: flags=9843 metric 0 mtu 1500 options=8 ether 00:20:ed:42:87:13 inet 192.168.0.2 netmask 0xffffff00 broadcast 192.168.0.255 media: Ethernet autoselect (100baseTX ) status: active Second test - netperf on Windows and netserver on FreeBSD: Unfortunately won't run: C:\software>netperf-a4 -l 60 -H 192.168.0.2 TCP STREAM TEST to 192.168.0.2 recv_response: partial response received: 0 bytes Hovewer, thanks to Alfred Perlstein who send mefollowing link: http://www.mavetju.org/mail/view_message.php?list=freebsd-net&id=755111&thread=no&tag=yes, I set SO_SNBUF and SO_RCVBUF in smb.conf to 2920. Without any additional tuning in sysctl I now got about 8MB/s which is *much* better result than before. It still could be better than that if I am reading netpertf results correctly :) Thanks Alfred! -- Bartosz Stec From edmunds at it-depo.lv Mon Oct 6 10:03:44 2008 From: edmunds at it-depo.lv (Edmunds Bergs) Date: Mon Oct 6 10:03:52 2008 Subject: Is FreeBSD a suitable choice for a MacBook? In-Reply-To: <20081005120024.5D445106576D@hub.freebsd.org> References: <20081005120024.5D445106576D@hub.freebsd.org> Message-ID: <48E9DD54.6070102@it-depo.lv> Hi. I think (IMHO) you can try some desktop orientated linux distro (ubunutu; kubuntu) or freebsd based PC-BSD desktop. If you are more experienced user and know what you`re doing then you can take some server orientated stuff and install it also as desktop. In fact it depends on your needs and what you really want to get from your box. Best Regards, Edmunds ============================= freebsd-stable-request@freebsd.org wrote: Message: 10 Date: Sun, 05 Oct 2008 13:25:39 +0200 From: Eirik Wix?e Svela Subject: Re: Is FreeBSD a suitable choice for a MacBook? To: freebsd-stable@freebsd.org Message-ID: <48E8A433.40108@nynorsk.no> Content-Type: text/plain; charset=ISO-8859-1 Thank you for your reply, David. You seem to be answering a question I did not ask, but allow me to respond briefly in any case: I have been using the operating system since January, and I am full aware of its line of inheritance as well as the UNIX 03 certification, and I have no major beef with it for everyday purposes. However, for all its ease of use and outstanding graphical user interface, I still find that its crossbred nature makes for a somewhat untidy system when dealing with nitty-gritty UNIX tasks such as enabling and configuring the firewall, configuring the system for maximum security (the default file permissions allow everyone to watch what's inside everyone else's home directories, for instance), installing an application by hand and so on. I also much prefer the free software movement and its principles to Apple and its "principles". Now, could someone answer my original question? Regards From utisoft at googlemail.com Mon Oct 6 12:08:29 2008 From: utisoft at googlemail.com (Chris Rees) Date: Mon Oct 6 12:08:37 2008 Subject: Is FreeBSD a suitable choice for a MacBook? Message-ID: > Date: Sat, 04 Oct 2008 21:00:48 +0200 > From: Eirik Wix?e Svela > Subject: Is FreeBSD a suitable choice for a MacBook? > To: freebsd-stable@freebsd.org > Message-ID: <48E7BD60.80001@nynorsk.no> > Content-Type: text/plain; charset=ISO-8859-1 > > I have an Apple MacBook with an Intel Core 2 Duo processor (November > 2007 edition, cf. the Wikipedia article for specifications), and I have > been considering switching to one of the free UNIX clones for some time > now. I understand that Ubuntu GNU/Linux is supposed to work well on this > kind of machine, but I would rather use some variant of BSD if that is a > viable alternative. > > I would therefore like to ask you whether anyone here has any experience > with FreeBSD, either 7.0-RELEASE or any other version, that they would > like to share so I might know what to expect if I choose to go through > with this. I have some time on my hands the next couple of weeks, so I > am prepared to spend some days tweaking things to work if it is worth > the effort, but if it isn't, I might as well take Ubuntu for a spin or > do a clean install of Mac OS X. > > Best regards > Eirik W. Svela > On my Macbook, I ran and used Ubuntu and FreeBSD in the days of 6.1 for a while, but the big problem is power management. On a laptop that is a killer... Standby is unreliable, breaks, and basically means that if you're on the move you have to shutdown and boot every time you want to put your laptop away. Is that what you really want? Say goodbye to your battery life too. Apart from that, all the cool parts of FreeBSD are just as good on it. I just found it's far better on my PC. -- R< $&h ! > $- ! $+ $@ $2 < @ $1 .UUCP. > (sendmail.cf) From mcdouga9 at egr.msu.edu Mon Oct 6 12:55:05 2008 From: mcdouga9 at egr.msu.edu (Adam McDougall) Date: Mon Oct 6 12:55:12 2008 Subject: fxp performance with POLLING In-Reply-To: <48E9B809.5080309@kkip.pl> References: <48E62ABA.6070901@kkip.pl> <20081005075956.GX36572@elvis.mu.org> <48E9B809.5080309@kkip.pl> Message-ID: <48EA06B5.5060604@egr.msu.edu> Bartosz Stec wrote: >>> BTW overall SAMBA performance still sucks on 7.1-pre as much as on >>> RELENG_5 ...:( - 7.5 MB/s peak. >>> >> >> 7.5MB is 75% effeciency of a 100mbit card. Not amazing, but >> not "sucks". >> >> Where do you see faster performance? >> >> Between windows machines on the same hardware or linux server? >> >> > It sucks because it is a peak performance. About 5-6 MB/s average. I > tried polling only because I found some suggestions on mailing lists, > that it could improve performance with SAMBA on FreeBSD. As you see at > the top of this thread - not in my case :) I also tried sysctl tunings, > and smb.conf settings, also suggested on maling lists, with no or very > little improvements noticed. Most of suggestions unfortunately end with > "change OS to Linux if you want to use SAMBA". I think I will try to > change NIC to 1Gbit - hope that helps :) Or maybe there's some "FreeBSD > and SAMBA tuning guide" which I didn't found? > Please try experimenting with "socket options" in smb.conf, I've found that some tuning is desirable on any OS with Samba, but these are the values that worked best for me with Windows XP clients in mind. Win2003 clients seemed much faster without tuning (same base code as XP 64bit) and I suspect it has a different SMB implementation. I'd suggest starting with "socket options = TCP_NODELAY IPTOS_THROUGHPUT SO_RCVBUF=8192 SO_SNDBUF=8192" and if you aren't satisfied, experiment with the numbers and which options are enabled. Be sure that the client has been disconnected from Samba completely to make sure you are testing the values in the config file. I'm pretty sure with these tunings I was able to get closer to 10MB/sec on 100Mbit, which satisfies me for the average user. # Most people will find that this option gives better performance. # See smb.conf(5) and /usr/share/doc/samba-doc/htmldocs/speed.html # for details # You may want to add the following on a Linux system: # SO_RCVBUF=8192 SO_SNDBUF=8192 # socket options = TCP_NODELAY # For some reason, 8192 is pretty fast on a XP lab 100Mb client. Other sizes tested and dissapointing in that situation. Windows Server 2k3 on gig is much faster, and likes larger values. There might be some merit in testing 49152 in some situations. (20080617) # TCP_NODELAY makes a huge improvement. IPTOS_THROUGHPUT is negligible locally. # mcdouga9 20070110 socket options = TCP_NODELAY IPTOS_THROUGHPUT SO_RCVBUF=8192 SO_SNDBUF=8192 # socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192 From antik at bsd.ee Mon Oct 6 13:08:27 2008 From: antik at bsd.ee (Andrei Kolu) Date: Mon Oct 6 13:08:34 2008 Subject: fxp performance with POLLING In-Reply-To: <20081006073420.GA23811@lava.net> References: <48E62ABA.6070901@kkip.pl> <20081005075956.GX36572@elvis.mu.org> <48E9B809.5080309@kkip.pl> <20081006071757.GA13076@icarus.home.lan> <48E9BE5F.5020709@bsd.ee> <20081006073420.GA23811@lava.net> Message-ID: <48EA0DCF.7000004@bsd.ee> Clifton Royston wrote: > On Mon, Oct 06, 2008 at 10:29:35AM +0300, Andrei Kolu wrote: > ... > >> I remember when on FreeBSD 4.x I was able to copy files from samba and >> to samba up to 12MB/s on 100Mbit lan. >> > > This part seems unlikely, particularly as bit rates are measured in > decimal millions not computer millions. > > 12*8*1024*1024 = 100,663,296 so that would mean not merely zero but > negative packet and network overhead. > > -- Clifton > OK, I am reading right now description for Trendnet Mini-GBIC Features: -------------------------------------------------------------------- (TEG-MGBSX, TEG-MGBS10, TEW-MGBS40, TEW-MGBS80) Compliant with IEEE 802.3z Gigabit Ethernet and Fiber Channel Standards Industry standard SFP package Duplex LC connector 1.0625Gbps Fiber Channel Compliant 1.25Gbps Gigabit Ethernet Compliant -------------------------------------------------------------------- So, I guess that 100Mbit and 1000Mbit is not set in stone and you can actually achieve higher speeds than "standard". BTW: 1 megabit = 106 = 1,000,000 bits which is equal to 125,000 bytes. 100 megabit = 12,500,000 bytes = 12,5MB Or I am wrong? From petefrench at ticketswitch.com Mon Oct 6 13:24:36 2008 From: petefrench at ticketswitch.com (Pete French) Date: Mon Oct 6 13:24:48 2008 Subject: fxp performance with POLLING In-Reply-To: <48EA0DCF.7000004@bsd.ee> Message-ID: > 1 megabit = 106 = 1,000,000 bits which is equal to 125,000 bytes. you are assuming eight bits per byte - but this is a serial line so you should use ten bits per byte instead. -pete. From koitsu at FreeBSD.org Mon Oct 6 13:34:49 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Mon Oct 6 13:38:27 2008 Subject: fxp performance with POLLING In-Reply-To: <48EA06B5.5060604@egr.msu.edu> References: <48E62ABA.6070901@kkip.pl> <20081005075956.GX36572@elvis.mu.org> <48E9B809.5080309@kkip.pl> <48EA06B5.5060604@egr.msu.edu> Message-ID: <20081006133445.GA21479@icarus.home.lan> On Mon, Oct 06, 2008 at 08:38:13AM -0400, Adam McDougall wrote: > Bartosz Stec wrote: > >>>> BTW overall SAMBA performance still sucks on 7.1-pre as much as on >>>> RELENG_5 ...:( - 7.5 MB/s peak. >>>> >>> >>> 7.5MB is 75% effeciency of a 100mbit card. Not amazing, but >>> not "sucks". >>> >>> Where do you see faster performance? >>> >>> Between windows machines on the same hardware or linux server? >>> >>> >> It sucks because it is a peak performance. About 5-6 MB/s average. I >> tried polling only because I found some suggestions on mailing lists, >> that it could improve performance with SAMBA on FreeBSD. As you see at >> the top of this thread - not in my case :) I also tried sysctl tunings, >> and smb.conf settings, also suggested on maling lists, with no or very >> little improvements noticed. Most of suggestions unfortunately end with >> "change OS to Linux if you want to use SAMBA". I think I will try to >> change NIC to 1Gbit - hope that helps :) Or maybe there's some "FreeBSD >> and SAMBA tuning guide" which I didn't found? >> > > Please try experimenting with "socket options" in smb.conf, I've found > that some tuning is desirable on any OS with Samba, but these are the > values that worked best for me with Windows XP clients in mind. Win2003 > clients seemed much faster without tuning (same base code as XP 64bit) > and I suspect it has a different SMB implementation. I'd suggest > starting with "socket options = TCP_NODELAY IPTOS_THROUGHPUT > SO_RCVBUF=8192 SO_SNDBUF=8192" and if you aren't satisfied, experiment > with the numbers and which options are enabled. Be sure that the > client has been disconnected from Samba completely to make sure you are > testing the values in the config file. I'm pretty sure with these > tunings I was able to get closer to 10MB/sec on 100Mbit, which satisfies > me for the average user. Interesting. I use gigE on my home network, and most of my Samba shares consist of very large files (ISO images and HD videos). Setting the buffer sizes to 8KB results in horrible performance; a 420MB ISO image taking ~50 seconds to copy. Copying is from the Samba server to the Windows machine. ZFS is used on FreeBSD, across 4 disks in a raidz1 pool; all disks are SATA300 with 16MByte cache. Increasing the Samba buffers to 64KB (65536) drops the transfer to 30 seconds, and increasing it to 128KB (131072) drops to 15-20 seconds. NICs involved are an Attansic L1E (on Windows XP, with TCP buffer sizes tuned in the registry, ditto with enabling TCP window resizing), and an em(4) (on FreeBSD). There are two switches between the boxes: an HP ProCurve, and a generic D-Link switch. Everything is gigE. Additionally, don't forget about IPTOS_LOWDELAY, and the "write cache size" and "read size" options in smb.conf. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From unga888 at yahoo.com Mon Oct 6 13:46:15 2008 From: unga888 at yahoo.com (Unga) Date: Mon Oct 6 13:46:22 2008 Subject: Help me to develop a FreeBSD patch for gcc-4.2.1 Message-ID: <669322.44942.qm@web57005.mail.re3.yahoo.com> Hi all I need to patch the gcc original sources to suit the FreeBSD, specially to support FreeBSD kernel compilation. I have tried it, spent lot of time, but it still develops compilation errors. The FreeBSD stable comes with gcc-4.2.1 but the sources are scattered over the /usr/src, therefore, I find it difficult to re-create the gcc-4.2.1 to its original directory layout to make a patch. I appreciate it very much, if you guys could help me to identify the pieces. Or alternatively, if someone could straight away put the FreeBSD gcc sources back to a directory and make a patch compared to the original gcc-4.2.1 sources from GNU and post here, I could apply the patch on my side and verify it was done correctly, whether I can compile the FreeBSD kernel or not. Many thanks in advance. Kind regards Unga From flygt at sr.se Mon Oct 6 14:16:46 2008 From: flygt at sr.se (Gunnar Flygt) Date: Mon Oct 6 14:16:54 2008 Subject: Possibility of backporting of Heimdal 1.1 Message-ID: <20081006140255.GA74575@sr.se> Is there any possibility that heimdal 1.1 that works beautifully in Current will be backported to FreeBSD-7.x? Gunnar Flygt Sveriges Radio Teknik/IT From admin at kkip.pl Mon Oct 6 14:25:28 2008 From: admin at kkip.pl (Bartosz Stec) Date: Mon Oct 6 14:25:36 2008 Subject: reloading samba config made system unresponsible Message-ID: <48EA1FD2.5080402@kkip.pl> My tries to tune smb.conf to achieve better performance expose very strange bug: Just executing: /usr/local/etc/rc.d/samba reload made my system unresponsible from network. It happens three times until now so I'm sure that is the cause (but it happened after some succesful reloads a couple of minutes earlier, so it's not happening all the time command is executed). Symptoms: - machine only responding to ping requests - ssh session shows, that config reload was succesful, and that's last thing showed (no shell after message) - can't connect with another ssh session, but no refuse nor timeout - on local console system seems responsible (alt +[1-9] works), but any try to login cause it to wait forever for password prompt - no kernel or error message on screen, and nothing suspicious in logs - alt+ctrl+del does nothing - pressing power button and waiting for system to shutdown does nothing - hard reset was the only way - after first restart I've made full fsck and started rebuilding gmirror - when machine hangs second time rebuilding doesn't stop I'm not a developer but it looks like some kind of deadlock? Note that changes I made to smb.conf was only in socket options. -- Bartosz Stec From hk at alogis.com Mon Oct 6 14:27:18 2008 From: hk at alogis.com (Holger Kipp) Date: Mon Oct 6 14:27:26 2008 Subject: Samba 3.2.4 not in ports? Message-ID: <20081006142714.GA89553@intserv.int1.b.intern> Hi all, Sorry if this is a faq or something obvious, but is there a reason why current version of samba 3.2.4 is not in ports? I only see 3.0.32 at the moment :-( Best regards, Holger From afriedman at drsns.com Mon Oct 6 15:18:28 2008 From: afriedman at drsns.com (Dr. Aharon Friedman) Date: Mon Oct 6 15:18:37 2008 Subject: Is FreeBSD a suitable choice for a MacBook? --- WHY? Message-ID: <363BDDAF-76C7-49AE-A8F5-EE1995C4CCBF@drsns.com> I am not sure why you would want to put FreeBSD on the Mac. Mac is already FreeBSD. Most of the FreeBSD ports have been made available to the Mac through Macports. X11 comes with it, and Apple gives you access to the kernel source code. If you must for some reason have FreeBSD, I recommend using a virtual machine software such as VM Ware Fusion (the are cheeper when you buy from Amazon - about $60). It does work very well for me. Although I use the Mac OS for all my Unix needs, I have installed a Windows XP Pro 64 bit for my Windows need. You could create a Linux and / or FreeBSD virtual machine. The software will even download it for you. Aharon Friedman From danny at cs.huji.ac.il Mon Oct 6 15:46:14 2008 From: danny at cs.huji.ac.il (Danny Braniss) Date: Mon Oct 6 15:46:23 2008 Subject: bad NFS/UDP performance In-Reply-To: References: <20080926081806.GA19055@icarus.home.lan> <20080926095230.GA20789@icarus.home.lan> Message-ID: > > On Sat, 4 Oct 2008, Danny Braniss wrote: > > > at the moment, the best I can do is run it on a different hardware that has > > if_em, the results are in > > ftp://ftp.cs.huji.ac.il/users/danny/lock.prof/7.1-1000.em the > > benchmark ran better with the Intel NIC, averaged UDP 54MB/s, TCP 53MB/s (I > > get the same numbers with an older kernel). > > Dear Danny: > > Unfortunately, I was left slightly unclear on the comparison you are making > above. Could you confirm whether or not, with if_em, you see a performance > regression using UDP NFS between 7.0-RELEASE and the most recent 7.1-STABLE, > and if you do, whether or not the RLOCK->WLOCK change has any effect on > performance? It would be nice to know on the same hardware but at least with > different hardware we get a sense of whether or not this might affect other > systems or whether it's limited to a narrower set of configurations. > > Thanks, 7.1-1000.em vanilla 7.1 1 x Intel Core Duo 7.1-1000.x2200.em vanilla 7.1 2 x Dual-Core AMD Opteron 7.0-1000.x2200.em 7.0 + RLOCK->WLOCK the plot thickens. I put an em card in, and the throughput is almost the same than with the bge. all the tests were done on the same host, a Sun x2200/amd/2cpux2core except for the one over the weekend that is a intel Core Duo, and not the same if_em card, sorry about that but one has PCI X, the other PCI Express :-(. what is becoming obvious is that NFS/UDP is very temperamental/sensitive :-) danny From geo at pulsar.bg Mon Oct 6 15:47:41 2008 From: geo at pulsar.bg (Georgi Iovchev) Date: Mon Oct 6 15:47:49 2008 Subject: can not wake on lan after halt -p (or shutdown -p now) on releng_7 and releng_7_0 Message-ID: <596673353.20081006181334@pulsar.bg> Hello list I have a shutdown problem. I have a machine with gigabyte GA-G33M-DS2R motherboard. Integrated network card is Realtek 8111B. I can not wake the computer after I shutdown it from FreeBSD. It is a dualboot system - windows xp and freebsd. If I shutdown the computer from windows - later I can wake it up with magic packet. Even if i shutdown the machine on the boot menu with the power button - than later I can wake on lan. The only situation where I CANNOT wake it is when I shutdown the machine from freebsd (halt -p). First I tested with 7.0-RELEASE-p5 amd64 (RELENG_7_0) and than I upgraded to 7.1 PRERELASE amd64 (RELENG_7). I also tested with two network cards - the integrated one Realtek 8111B and another one Intel PRO1000PT PCI-E with WOL enabled. With both nics and both freebsd versions the situation is the same - after shutdown from bsd the computer is not able to wake on lan. The indication on the switch port says that after shut down there is active link. Here is some information after last update: [root@backup ~]# uname -a FreeBSD backup.pulsar.bg 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #1: Mon Oct 6 17:01:26 EEST 2008 root@backup.pulsar.bg:/usr/obj/usr/src/sys/MYCONF amd64 [root@backup ~]# pciconf -lv ... re0@pci0:3:0:0: class=0x020000 card=0xe0001458 chip=0x816810ec rev=0x01 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC' class = network subclass = ethernet ... em0@pci0:1:0:0: class=0x020000 card=0x10838086 chip=0x10b98086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' device = '82572EI PRO/1000 PT Desktop Adapter (Copper)' class = network subclass = ethernet ... [root@backup ~]# ifconfig re0 wol [root@backup ~]# ifconfig em0 wol [root@backup ~]# ifconfig em0: flags=8802 metric 0 mtu 1500 options=19b ether 00:1b:21:22:52:cd media: Ethernet autoselect status: no carrier re0: flags=8843 metric 0 mtu 1500 options=389b ether 00:1f:d0:24:19:e9 inet 78.142.42.158 netmask 0xfffffff0 broadcast 78.142.42.159 inet 192.168.0.6 netmask 0xffffff00 broadcast 192.168.0.255 media: Ethernet autoselect (100baseTX ) status: active lo0: flags=8049 metric 0 mtu 16384 inet 127.0.0.1 netmask 0xff000000 I suppose that I should post more info but I dont know what exactly is needed. Need help! 10x in advance Georgi Iovchev From afriedman at drsns.com Mon Oct 6 16:19:33 2008 From: afriedman at drsns.com (Dr. Aharon Friedman) Date: Mon Oct 6 16:19:40 2008 Subject: Is FreeBSD a suitable choice for a MacBook? --- WHY? In-Reply-To: <6228eb140810060825g784d0d1fle6738d3186cc4451@mail.gmail.com> References: <363BDDAF-76C7-49AE-A8F5-EE1995C4CCBF@drsns.com> <6228eb140810060825g784d0d1fle6738d3186cc4451@mail.gmail.com> Message-ID: Sorry, I meant BSD. Here is the link: http://www.freebsd.org/news/press-rel-3.html Aharon Friedman On Oct 6, 2008, at 11:25 AM, David Sanders wrote: > 2008/10/6 Dr. Aharon Friedman : >> I am not sure why you would want to put FreeBSD on the Mac. Mac is >> already >> FreeBSD. Most of the FreeBSD ports have been made available to the >> Mac >> through Macports. X11 comes with it, and Apple gives you access to >> the >> kernel source code. >> >> If you must for some reason have FreeBSD, I recommend using a virtual >> machine software such as VM Ware Fusion (the are cheeper when you >> buy from >> Amazon - about $60). It does work very well for me. Although I >> use the Mac >> OS for all my Unix needs, I have installed a Windows XP Pro 64 bit >> for my >> Windows need. You could create a Linux and / or FreeBSD virtual >> machine. >> The software will even download it for you. >> > > I'm just a lurker, but even I know that only some of the userland > apps in OS X > are BSD-based. The kernel is mach microkernel based and not even > slightly > similar. > > I don't think anyone is answering the OP's question, but put simply > Mac OS is > not BSD, and the X11 implementation is buggy to say the least. I > wouldn't > recommend it for most OSS stack dev work. From rwatson at FreeBSD.org Mon Oct 6 17:37:00 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Mon Oct 6 17:37:07 2008 Subject: Is FreeBSD a suitable choice for a MacBook? --- WHY? In-Reply-To: References: <363BDDAF-76C7-49AE-A8F5-EE1995C4CCBF@drsns.com> <6228eb140810060825g784d0d1fle6738d3186cc4451@mail.gmail.com> Message-ID: On Mon, 6 Oct 2008, Dr. Aharon Friedman wrote: > Sorry, I meant BSD. > > Here is the link: > > http://www.freebsd.org/news/press-rel-3.html > > Aharon Friedman I don't see the origina message you replied to on the list, so am replying to it via your post... >> I'm just a lurker, but even I know that only some of the userland apps in >> OS X are BSD-based. The kernel is mach microkernel based and not even >> slightly similar. This claim regarding the kernel is highly inaccurate. There are significant quantities of FreeBSD, Mach, and Apple-originated code in the Mac OS X kernel, both because Apple pulled in a lot of FreeBSD code early on, but also because code moves between the two kernels fairly easily and fairly frequently, and in both directions. You'll find a FreeBSD-derived VFS, network stack, and countless other kernel parts in Mac OS X from their first open source drop forward. More recently, though, you'll find that the Audit implementation present in FreeBSD 6.x and later is based on the Mac OS X kernel audit code, and the TrustedBSD MAC Framework that appeared in Mac OS X Leopard is straight from FreeBSD. It's certainly true that there's a lot of non-FreeBSD code -- XNU uses the Mach scheduler and Mach IPC, and a quite different driver framework, for example. There's also some convergent evolution: FreeBSD contains a Mach-derived VM that also comes from the original Mach project. Finally, just to be clear: XNU is not a micro-kernel, even though it contains significant amounts of Mach code. The "microkernel" and remainder of the kernel run in a single address space, and although certain separation is (often) maintained in the source code / abstractions, the Mach, FreeBSD, and device driver parts run in a unified and tightly integrated way. Robert N M Watson Computer Laboratory University of Cambridge From peterjeremy at optushome.com.au Mon Oct 6 18:03:56 2008 From: peterjeremy at optushome.com.au (Peter Jeremy) Date: Mon Oct 6 18:04:04 2008 Subject: Help me to develop a FreeBSD patch for gcc-4.2.1 In-Reply-To: <669322.44942.qm@web57005.mail.re3.yahoo.com> References: <669322.44942.qm@web57005.mail.re3.yahoo.com> Message-ID: <20081006180353.GF18237@server.vk2pj.dyndns.org> Please wrap your mail before 80 columns. On 2008-Oct-06 06:19:34 -0700, Unga wrote: >The FreeBSD stable comes with gcc-4.2.1 but the sources are scattered >over the /usr/src, therefore, I find it difficult to re-create the >gcc-4.2.1 to its original directory layout to make a patch. The original sources for gcc can be found in /usr/src/contrib/gcc - note that this is not a complete gcc 4.2.1 distribution as parts of gcc that are not relevant for FreeBSD have been deleted. Refer to the FREEBSD-* files for details. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20081006/b9b8a694/attachment.pgp From ronald-freebsd8 at klop.yi.org Mon Oct 6 20:29:26 2008 From: ronald-freebsd8 at klop.yi.org (Ronald Klop) Date: Mon Oct 6 20:29:38 2008 Subject: USB detach/attach hangs with 7.0-RELEASE and 7.1-PRERELEASE In-Reply-To: <20081003145135.GA4528@dsp.50hz.ws> References: <48E02557.2020303@incunabulum.net> <20081003145135.GA4528@dsp.50hz.ws> Message-ID: In that case I'm out of options. Maybe somebody else on the list can respond. Succes, Ronald. On Fri, 03 Oct 2008 16:51:35 +0200, Henrik Friedrichsen wrote: > USB support in the BIOS? What kind of support does the BIOS provide that > you can disable? > I'm only able to disable the USB device, but that'd turn it off > completely :( > > Henrik. > > On Mon, Sep 29, 2008 at 10:05:02PM +0200, Ronald Klop wrote: >> On Mon, 29 Sep 2008 02:46:15 +0200, Bruce M Simpson >> >> wrote: >> >> >Hi, >> > >> >I've noticed some general instability with plugging in or removing USB >> >devices with FreeBSD 7.x, even when the devices are not actively in >> use. >> > >> >I had this happen with umass and ucom devices 3 times today. The >> machine >> >hangs solid, there are no obvious signs of a panic or trap to DDB. I >> >can't provide backtraces unfortunately -- these hangs happen on both my >> >laptop and desktop, and I usually have X running -- if I had more >> >specific information, I'd open a PR. >> > >> >Again, there seems to be no reason why this should happen, the devices >> >are off-the-shelf consumer items known to work with existing drivers, >> >and have been repeatedly used in other OSes without these hangs >> >happening; consider this an "anecdotal report". >> > >> >[For some reason my IBM laptop will often not allow me to break into >> DDB >> >on a driver related panic, and will just immediately reboot -- I lack >> >free time to track down exactly why this could be. >> >My desktop has a USB keyboard and this appears not to be supported by >> >DDB, I ordered a PS/2 keyboard which hasn't arrived, but that's another >> >story.] >> > >> >thanks >> >BMS >> >> On my computer I had to disable USB support in the BIOS because it >> 'conflicted' with USB support of FreeBSD. >> FreeBSD still detects USB and all connected devices. >> Maybe this helps on your computer also. >> >> Ronald. >> >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to >> "freebsd-stable-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From afriedman at drsns.com Mon Oct 6 20:53:53 2008 From: afriedman at drsns.com (Dr. Aharon Friedman) Date: Mon Oct 6 20:54:00 2008 Subject: Is FreeBSD a suitable choice for a MacBook? --- WHY? In-Reply-To: References: <363BDDAF-76C7-49AE-A8F5-EE1995C4CCBF@drsns.com> <6228eb140810060825g784d0d1fle6738d3186cc4451@mail.gmail.com> Message-ID: Thanks Robert, I just did not want to go into a lot of details. My bottom line was that unless you want to run a very specific port that has not been ported to Mac OSX (these are quite rare), I do not see the reason to install FreeBSD on a Mac Book. As for X11 it is maintained as a separate port, and one can go to: http://xquartz.macosforge.org/trac/ to download the latest version which is much less buggy. The only caveat is that when Apple updates the operating system it reverts to whatever they have on the official release and one has to reinstall the latest version. Aharon Friedman On Oct 6, 2008, at 1:36 PM, Robert Watson wrote: > > On Mon, 6 Oct 2008, Dr. Aharon Friedman wrote: > >> Sorry, I meant BSD. >> >> Here is the link: >> >> http://www.freebsd.org/news/press-rel-3.html >> >> Aharon Friedman > > I don't see the origina message you replied to on the list, so am > replying to it via your post... > >>> I'm just a lurker, but even I know that only some of the userland >>> apps in OS X are BSD-based. The kernel is mach microkernel based >>> and not even slightly similar. > > This claim regarding the kernel is highly inaccurate. There are > significant quantities of FreeBSD, Mach, and Apple-originated code > in the Mac OS X kernel, both because Apple pulled in a lot of > FreeBSD code early on, but also because code moves between the two > kernels fairly easily and fairly frequently, and in both directions. > You'll find a FreeBSD-derived VFS, network stack, and countless > other kernel parts in Mac OS X from their first open source drop > forward. More recently, though, you'll find that the Audit > implementation present in FreeBSD 6.x and later is based on the Mac > OS X kernel audit code, and the TrustedBSD MAC Framework that > appeared in Mac OS X Leopard is straight from FreeBSD. > > It's certainly true that there's a lot of non-FreeBSD code -- XNU > uses the Mach scheduler and Mach IPC, and a quite different driver > framework, for example. There's also some convergent evolution: > FreeBSD contains a Mach-derived VM that also comes from the original > Mach project. > > Finally, just to be clear: XNU is not a micro-kernel, even though it > contains significant amounts of Mach code. The "microkernel" and > remainder of the kernel run in a single address space, and although > certain separation is (often) maintained in the source code / > abstractions, the Mach, FreeBSD, and device driver parts run in a > unified and tightly integrated way. > > Robert N M Watson > Computer Laboratory > University of Cambridge From galen.sampson at gmail.com Mon Oct 6 21:44:33 2008 From: galen.sampson at gmail.com (Galen Sampson) Date: Mon Oct 6 21:44:40 2008 Subject: Possibility of backporting of Heimdal 1.1 In-Reply-To: <20081006140255.GA74575@sr.se> References: <20081006140255.GA74575@sr.se> Message-ID: <48EA820F.1030109@gmail.com> I would like to second that. The heimdal in 7.0 is quite old. It is in fact inoperable with an mit kerberos realm when using ssh. The byte order is incorrect such that you get MIC checksum failures. After much googling (not documented in the krb5.conf man page or handbook) I found that a fix was added in the heimdal in 7.0, but defaults to the old incompatible byte order. The heimdal in current uses the correct byte order by default. For those having the this issue with freebsd 7.0 the fix is adding the following lines to /etc/krb5.conf: [gssapi] correct_des3_mic = host/*@SOME.REALM Gunnar Flygt wrote: > Is there any possibility that heimdal 1.1 that works beautifully in > Current will be backported to FreeBSD-7.x? > > Gunnar Flygt > Sveriges Radio Teknik/IT > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From Johan at double-l.nl Tue Oct 7 08:05:57 2008 From: Johan at double-l.nl (Johan Hendriks) Date: Tue Oct 7 08:06:05 2008 Subject: Samba 3.2.4 not in ports? References: <20081006142714.GA89553@intserv.int1.b.intern> Message-ID: <57200BF94E69E54880C9BB1AF714BBCB5DE16F@w2003s01.double-l.local> >Onderwerp: Samba 3.2.4 not in ports? >Hi all, >Sorry if this is a faq or something obvious, but >is there a reason why current version of samba 3.2.4 >is not in ports? I only see 3.0.32 at the moment :-( >Best regards, >Holger This has been asked before, there are some issues with samba 3.2.x The maintainer said that maybe a 3.2.2 or even higher will be in ports but we are now at 3.2.4 and still no 3.2.x in ports. So the issues are not worked out yet. Be patient, it will hit the tree some time. But maybe it is time for a samba32-devel in the ports tree so it gets more testing. Regards, Johan Hendriks No virus found in this outgoing message. Checked by AVG - http://www.avg.com Version: 8.0.173 / Virus Database: 270.7.6/1711 - Release Date: 6-10-2008 17:37 From unga888 at yahoo.com Tue Oct 7 09:06:04 2008 From: unga888 at yahoo.com (Unga) Date: Tue Oct 7 09:06:11 2008 Subject: Help me to develop a FreeBSD patch for gcc-4.2.1 In-Reply-To: <20081006180353.GF18237@server.vk2pj.dyndns.org> Message-ID: <579024.2364.qm@web57007.mail.re3.yahoo.com> --- On Tue, 10/7/08, Peter Jeremy wrote: > On 2008-Oct-06 06:19:34 -0700, Unga > wrote: > >The FreeBSD stable comes with gcc-4.2.1 but the sources > are scattered > >over the /usr/src, therefore, I find it difficult to > re-create the > >gcc-4.2.1 to its original directory layout to make a > patch. > > The original sources for gcc can be found in > /usr/src/contrib/gcc - > note that this is not a complete gcc 4.2.1 distribution as > parts of > gcc that are not relevant for FreeBSD have been deleted. > Refer to the > FREEBSD-* files for details. > Here is how I did that: 1. Unpack original GCC sources tar -xjf gcc-4.2.1.tar.bz2 mv -v gcc-4.2.1 gcc-4.2.1.orig 2. Bring under one roof FreeBSD-modified GCC sources mkdir -pv gcc-4.2.1 cd gcc-4.2.1 cp -R /usr/src/contrib/gcc . cp -R /usr/src/contrib/gcclibs/ . cp -R /usr/src/contrib/libobjc . cp -R /usr/src/contrib/libstdc++ libstdc++-v3 cd .. 3. Make a patch diff -aur gcc-4.2.1.orig gcc-4.2.1 >& FreeBSD-gcc.patch Now the question is have I collected all the GCC sources from FreeBSD source tree? Have I missed any? Now I unpacked the gcc-4.2.1.tar.bz2 into some other directory and applied this FreeBSD-gcc.patch. Ran configure and compiled. It develop following error: ../../gcc-4.2.1/gcc/c-format.c:1780: error: 'flag_format_extensions' undeclared (first use in this function) ../../gcc-4.2.1/gcc/c-format.c:1780: error: (Each undeclared identifier is reported only once ../../gcc-4.2.1/gcc/c-format.c:1780: error: for each function it appears in.) gmake[2]: *** [c-format.o] Error 1 So where is the flag_format_extensions is declared in FreeBSD? Best regards Unga From lhmwzy at gmail.com Tue Oct 7 09:32:45 2008 From: lhmwzy at gmail.com (lhmwzy) Date: Tue Oct 7 09:32:51 2008 Subject: zfs quota question Message-ID: <78fb9d960810070232u3f35010dv510dfa0fb2285568@mail.gmail.com> I create a zfs volume pool/lhm and give it quota 1M use "zfs set quota=1m pool/lhm" #zfs get all pool/lhm zfs get all pool/lhm [ttyp0][5:22:12pm] NAME PROPERTY VALUE SOURCE pool/lhm type filesystem - pool/lhm creation Tue Oct 7 17:14 2008 - pool/lhm used 1.00M - pool/lhm available 0 - pool/lhm referenced 1.00M - pool/lhm compressratio 7.25x - pool/lhm mounted yes - pool/lhm quota 1M local pool/lhm reservation none default pool/lhm recordsize 128K default But I cp 10 files,per file size is 2.4M to pool/lhm #ll -h /pool/lhm total 1013 -rw------- 1 root wheel 2.4M Oct 7 17:18 d -rw------- 1 root wheel 2.4M Oct 7 17:19 dd -rw------- 1 root wheel 2.4M Oct 7 17:19 ddd -rw------- 1 root wheel 2.4M Oct 7 17:19 dddd -rw------- 1 root wheel 2.4M Oct 7 17:19 ddddd -rw------- 1 root wheel 2.4M Oct 7 17:19 dddddd -rw------- 1 root wheel 2.4M Oct 7 17:19 dddddd2 -rw------- 1 root wheel 2.4M Oct 7 17:19 dddddd24 -rw------- 1 root wheel 2.1M Oct 7 17:19 dddddd247 -rw------- 1 root wheel 2.4M Oct 7 17:18 kldstat.core #du -hs /pool/lhm 1.0M . I am puzzled,the what's zfs quota mean? I understand is file quota,that can't put files which total size larger than 1M. But it seems my understanding is wrong. Anybody give a idea? From lhmwzy at gmail.com Tue Oct 7 09:34:27 2008 From: lhmwzy at gmail.com (lhmwzy) Date: Tue Oct 7 09:34:35 2008 Subject: zfs quota question In-Reply-To: <78fb9d960810070232u3f35010dv510dfa0fb2285568@mail.gmail.com> References: <78fb9d960810070232u3f35010dv510dfa0fb2285568@mail.gmail.com> Message-ID: <78fb9d960810070234r28362270xa3477420f8ac578a@mail.gmail.com> My system #uname -a FreeBSD bxzxfreebsd.slof.com 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #4: Mon Oct 6 15:02:42 CST 2008 root@bxzxfreebsd.slof.com:/usr/obj/usr/src/sys/lhmwzy amd64 zfs version: ZFS filesystem version 6 ZFS storage pool version 6 From jhugo at meraka.csir.co.za Tue Oct 7 09:53:00 2008 From: jhugo at meraka.csir.co.za (Johann Hugo) Date: Tue Oct 7 09:53:08 2008 Subject: "route flush" does not delete routes created with -interface option Message-ID: <200810071152.57186.jhugo@meraka.csir.co.za> Is there a way to get rid of all the routes in a routing table ? This is more or less what I do: route add 146.64.80.0/24 192.168.0.100 route add 146.141.0.0 -interface tun1 route add 146.182.0.0 -interface tun1 route add 146.230.0.0 -interface tun1 netstat -rn inet 146.64.80.0/24 192.168.0.100 UGS 0 0 sis0 146.141.0.0/16 tun1 US 0 0 tun1 146.182.0.0/16 tun1 US 0 0 tun1 146.230.0.0/16 tun1 US 0 0 tun1 If I do "route -n flush -inet" then it does not delete the routes created with a -interface option. see verbose output: route -vn flush -inet RTM_GET: Report Metrics: len 204, pid: 0, seq 0, errno 0, flags: locks: inits: sockaddrs: 146.64.80.0 192.168.0.100 (255) ffff ffff ff sis0:0.0.24.c7.8b.80 192.168.0.44 RTM_DELETE: Delete Route: len 204, pid: 0, seq 2, errno 0, flags: locks: inits: sockaddrs: 146.64.80.0 192.168.0.100 (255) ffff ffff ff sis0:0.0.24.c7.8b.80 192.168.0.44 RTM_GET: Report Metrics: len 260, pid: 0, seq 0, errno 0, flags: locks: inits: sockaddrs: 146.141.0.0 tun1 (255) ffff ffff tun1 dsl-146-145-96.telkomadsl.co.za dsl-146-144-01.telkomadsl.co.za RTM_GET: Report Metrics: len 260, pid: 0, seq 0, errno 0, flags: locks: inits: sockaddrs: 146.182.0.0 tun1 (255) ffff ffff tun1 dsl-146-145-96.telkomadsl.co.za dsl-146-144-01.telkomadsl.co.za RTM_GET: Report Metrics: len 260, pid: 0, seq 0, errno 0, flags: locks: inits: sockaddrs: 146.230.0.0 tun1 (255) ffff ffff tun1 dsl-146-145-96.telkomadsl.co.za dsl-146-144-01.telkomadsl.co.za uname -a FreeBSD groenwifi.cids.org.za 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #19: Tue Aug 26 13:40:13 UTC 2008 From koitsu at FreeBSD.org Tue Oct 7 09:54:39 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Tue Oct 7 09:54:46 2008 Subject: zfs quota question In-Reply-To: <78fb9d960810070232u3f35010dv510dfa0fb2285568@mail.gmail.com> References: <78fb9d960810070232u3f35010dv510dfa0fb2285568@mail.gmail.com> Message-ID: <20081007095437.GA44716@icarus.home.lan> On Tue, Oct 07, 2008 at 05:32:43PM +0800, lhmwzy wrote: > I create a zfs volume pool/lhm and give it quota 1M use "zfs set > quota=1m pool/lhm" > > #zfs get all pool/lhm > zfs get all pool/lhm > [ttyp0][5:22:12pm] > NAME PROPERTY VALUE SOURCE > pool/lhm type filesystem - > pool/lhm creation Tue Oct 7 17:14 2008 - > pool/lhm used 1.00M - > pool/lhm available 0 - > pool/lhm referenced 1.00M - > pool/lhm compressratio 7.25x - > pool/lhm mounted yes - > pool/lhm quota 1M local > pool/lhm reservation none default > pool/lhm recordsize 128K default > > But I cp 10 files,per file size is 2.4M to pool/lhm > #ll -h /pool/lhm > total 1013 > -rw------- 1 root wheel 2.4M Oct 7 17:18 d > -rw------- 1 root wheel 2.4M Oct 7 17:19 dd > -rw------- 1 root wheel 2.4M Oct 7 17:19 ddd > -rw------- 1 root wheel 2.4M Oct 7 17:19 dddd > -rw------- 1 root wheel 2.4M Oct 7 17:19 ddddd > -rw------- 1 root wheel 2.4M Oct 7 17:19 dddddd > -rw------- 1 root wheel 2.4M Oct 7 17:19 dddddd2 > -rw------- 1 root wheel 2.4M Oct 7 17:19 dddddd24 > -rw------- 1 root wheel 2.1M Oct 7 17:19 dddddd247 > -rw------- 1 root wheel 2.4M Oct 7 17:18 kldstat.core > > #du -hs /pool/lhm > 1.0M . > > I am puzzled,the what's zfs quota mean? > I understand is file quota,that can't put files which total size larger than 1M. > But it seems my understanding is wrong. > Anybody give a idea? I can confirm and reproduce what you're seeing. Based on all of the ZFS documentation and examples I've read, it appears to be a bug in FreeBSD ZFS. CC'ing pjd@, who maintains ZFS on FreeBSD. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From hk at alogis.com Tue Oct 7 10:10:01 2008 From: hk at alogis.com (Holger Kipp) Date: Tue Oct 7 10:10:15 2008 Subject: zfs quota question In-Reply-To: <20081007095437.GA44716@icarus.home.lan> References: <78fb9d960810070232u3f35010dv510dfa0fb2285568@mail.gmail.com> <20081007095437.GA44716@icarus.home.lan> Message-ID: <20081007100726.GB19896@intserv.int1.b.intern> On Tue, Oct 07, 2008 at 02:54:37AM -0700, Jeremy Chadwick wrote: > On Tue, Oct 07, 2008 at 05:32:43PM +0800, lhmwzy wrote: > > I create a zfs volume pool/lhm and give it quota 1M use "zfs set > > quota=1m pool/lhm" > I can confirm and reproduce what you're seeing. > > Based on all of the ZFS documentation and examples I've read, it appears > to be a bug in FreeBSD ZFS. > > CC'ing pjd@, who maintains ZFS on FreeBSD. I can't confirm this on a recent 7-STABLE (yesterday): intserv2# zfs set quota=1m tank/test intserv2# cp /usr/ports/distfiles/samba-3.0.32.tar.gz /tank/test/ cp: /tank/test/samba-3.0.32.tar.gz: Disc quota exceeded Regards, Holger Kipp From hk at alogis.com Tue Oct 7 10:10:02 2008 From: hk at alogis.com (Holger Kipp) Date: Tue Oct 7 10:10:16 2008 Subject: zfs quota question In-Reply-To: <78fb9d960810070232u3f35010dv510dfa0fb2285568@mail.gmail.com> References: <78fb9d960810070232u3f35010dv510dfa0fb2285568@mail.gmail.com> Message-ID: <20081007095925.GA19896@intserv.int1.b.intern> On Tue, Oct 07, 2008 at 05:32:43PM +0800, lhmwzy wrote: > I create a zfs volume pool/lhm and give it quota 1M use "zfs set > quota=1m pool/lhm" according to zfs manpage: Quotas cannot be set on volumes, as the "volsize" property acts as an implicit quota. Aditionally, I see you're using compression, so a 2.4M file might not use up that much space. Compressration 7.25x > #zfs get all pool/lhm > zfs get all pool/lhm > [ttyp0][5:22:12pm] > NAME PROPERTY VALUE SOURCE > pool/lhm type filesystem - > pool/lhm creation Tue Oct 7 17:14 2008 - > pool/lhm used 1.00M - > pool/lhm available 0 - > pool/lhm referenced 1.00M - > pool/lhm compressratio 7.25x - > pool/lhm mounted yes - > pool/lhm quota 1M local > pool/lhm reservation none default > pool/lhm recordsize 128K default If you find this answer helpful, donate money to some children help fund :-) Regards, Holger Kipp From koitsu at FreeBSD.org Tue Oct 7 10:13:01 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Tue Oct 7 10:13:09 2008 Subject: zfs quota question In-Reply-To: <20081007100726.GB19896@intserv.int1.b.intern> References: <78fb9d960810070232u3f35010dv510dfa0fb2285568@mail.gmail.com> <20081007095437.GA44716@icarus.home.lan> <20081007100726.GB19896@intserv.int1.b.intern> Message-ID: <20081007101259.GA45900@icarus.home.lan> On Tue, Oct 07, 2008 at 12:07:26PM +0200, Holger Kipp wrote: > On Tue, Oct 07, 2008 at 02:54:37AM -0700, Jeremy Chadwick wrote: > > On Tue, Oct 07, 2008 at 05:32:43PM +0800, lhmwzy wrote: > > > I create a zfs volume pool/lhm and give it quota 1M use "zfs set > > > quota=1m pool/lhm" > > > I can confirm and reproduce what you're seeing. > > > > Based on all of the ZFS documentation and examples I've read, it appears > > to be a bug in FreeBSD ZFS. > > > > CC'ing pjd@, who maintains ZFS on FreeBSD. > > I can't confirm this on a recent 7-STABLE (yesterday): > > intserv2# zfs set quota=1m tank/test > intserv2# cp /usr/ports/distfiles/samba-3.0.32.tar.gz /tank/test/ > cp: /tank/test/samba-3.0.32.tar.gz: Disc quota exceeded Interesting. The system I'm testing on: FreeBSD icarus.home.lan 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #0: Thu Oct 2 03:04:20 PDT 2008 root@icarus.home.lan:/usr/obj/usr/src/sys/PDSMI_PLUS_RELENG_7_amd64 amd64 Can you provide the output from "zfs get all tank tank/test"? Below are mine. Note that for the testing, I set the quota on storage/home to 4G, and did "dd if=/dev/zero of=/home/filler bs=1g count=8". I've since set the quota back to 16G. NAME PROPERTY VALUE SOURCE storage type filesystem - storage creation Wed Sep 24 17:47 2008 - storage used 181G - storage available 1.16T - storage referenced 180G - storage compressratio 1.02x - storage mounted yes - storage quota none default storage reservation none default storage recordsize 128K default storage mountpoint /storage default storage sharenfs off default storage checksum on default storage compression on local storage atime on local storage devices on default storage exec on default storage setuid on default storage readonly off default storage jailed off default storage snapdir hidden default storage aclmode groupmask default storage aclinherit secure default storage canmount on default storage shareiscsi off default storage xattr off temporary storage copies 1 default storage/home type filesystem - storage/home creation Wed Sep 24 20:26 2008 - storage/home used 944M - storage/home available 14.1G - storage/home referenced 944M - storage/home compressratio 1.25x - storage/home mounted yes - storage/home quota 15G local storage/home reservation none default storage/home recordsize 128K default storage/home mountpoint /home local storage/home sharenfs off default storage/home checksum on default storage/home compression on inherited from storage storage/home atime on inherited from storage storage/home devices on default storage/home exec on default storage/home setuid on default storage/home readonly off default storage/home jailed off default storage/home snapdir hidden default storage/home aclmode groupmask default storage/home aclinherit secure default storage/home canmount on default storage/home shareiscsi off default storage/home xattr off temporary storage/home copies 1 default Filesystem Size Used Avail Capacity Mounted on storage 1.3T 180G 1.2T 13% /storage storage/home 15G 944M 14G 6% /home -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From pjd at FreeBSD.org Tue Oct 7 10:17:47 2008 From: pjd at FreeBSD.org (Pawel Jakub Dawidek) Date: Tue Oct 7 10:17:56 2008 Subject: zfs quota question In-Reply-To: <20081007095437.GA44716@icarus.home.lan> References: <78fb9d960810070232u3f35010dv510dfa0fb2285568@mail.gmail.com> <20081007095437.GA44716@icarus.home.lan> Message-ID: <20081007101755.GB3464@garage.freebsd.pl> On Tue, Oct 07, 2008 at 02:54:37AM -0700, Jeremy Chadwick wrote: > On Tue, Oct 07, 2008 at 05:32:43PM +0800, lhmwzy wrote: > > I create a zfs volume pool/lhm and give it quota 1M use "zfs set > > quota=1m pool/lhm" > > > > #zfs get all pool/lhm > > zfs get all pool/lhm > > [ttyp0][5:22:12pm] > > NAME PROPERTY VALUE SOURCE > > pool/lhm type filesystem - > > pool/lhm creation Tue Oct 7 17:14 2008 - > > pool/lhm used 1.00M - > > pool/lhm available 0 - > > pool/lhm referenced 1.00M - > > pool/lhm compressratio 7.25x - Turn compression off and retry. -- Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20081007/d5875efb/attachment.pgp From hk at alogis.com Tue Oct 7 10:25:19 2008 From: hk at alogis.com (Holger Kipp) Date: Tue Oct 7 10:25:26 2008 Subject: zfs quota question In-Reply-To: <20081007101259.GA45900@icarus.home.lan> References: <78fb9d960810070232u3f35010dv510dfa0fb2285568@mail.gmail.com> <20081007095437.GA44716@icarus.home.lan> <20081007100726.GB19896@intserv.int1.b.intern> <20081007101259.GA45900@icarus.home.lan> Message-ID: <20081007102516.GA20597@intserv.int1.b.intern> On Tue, Oct 07, 2008 at 03:12:59AM -0700, Jeremy Chadwick wrote: > On Tue, Oct 07, 2008 at 12:07:26PM +0200, Holger Kipp wrote: > > On Tue, Oct 07, 2008 at 02:54:37AM -0700, Jeremy Chadwick wrote: > > > On Tue, Oct 07, 2008 at 05:32:43PM +0800, lhmwzy wrote: > > > > I create a zfs volume pool/lhm and give it quota 1M use "zfs set > > > > quota=1m pool/lhm" > > > > > I can confirm and reproduce what you're seeing. > > > > > > Based on all of the ZFS documentation and examples I've read, it appears > > > to be a bug in FreeBSD ZFS. > > > > > > CC'ing pjd@, who maintains ZFS on FreeBSD. > > > > I can't confirm this on a recent 7-STABLE (yesterday): > > > > intserv2# zfs set quota=1m tank/test > > intserv2# cp /usr/ports/distfiles/samba-3.0.32.tar.gz /tank/test/ > > cp: /tank/test/samba-3.0.32.tar.gz: Disc quota exceeded > > Interesting. The system I'm testing on: > > FreeBSD icarus.home.lan 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #0: Thu Oct 2 03:04:20 PDT 2008 root@icarus.home.lan:/usr/obj/usr/src/sys/PDSMI_PLUS_RELENG_7_amd64 amd64 > > Can you provide the output from "zfs get all tank tank/test"? > Below are mine. > > Note that for the testing, I set the quota on storage/home to 4G, and > did "dd if=/dev/zero of=/home/filler bs=1g count=8". I've since > set the quota back to 16G. > > NAME PROPERTY VALUE SOURCE > storage compressratio 1.02x - > > storage/home type filesystem - > storage/home compressratio 1.25x - I am not sure if you get correct results with /dev/zero and enabled compression. A file that only contains null bytes won't grow very fast in compressed form. You might want to create storage/test and disable compression for this, then set a limit of 1M or larger (if you like) and try once again. I currently have a pool defined without general compression and just used # zfs create tank/test # zfs set quota=1m tank/test # cp /usr/ports/distfiles/samba-3.0.32.tar.gz /tank/test/ cp: /tank/test/samba-3.0.32.tar.gz: Disc quota exceeded # zfs destroy tank/test and compressration is a very steady 1.00x ;-) Best regards, Holger Kipp From koitsu at FreeBSD.org Tue Oct 7 10:30:12 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Tue Oct 7 10:30:18 2008 Subject: zfs quota question In-Reply-To: <20081007101755.GB3464@garage.freebsd.pl> References: <78fb9d960810070232u3f35010dv510dfa0fb2285568@mail.gmail.com> <20081007095437.GA44716@icarus.home.lan> <20081007101755.GB3464@garage.freebsd.pl> Message-ID: <20081007102959.GA46215@icarus.home.lan> On Tue, Oct 07, 2008 at 12:17:55PM +0200, Pawel Jakub Dawidek wrote: > On Tue, Oct 07, 2008 at 02:54:37AM -0700, Jeremy Chadwick wrote: > > On Tue, Oct 07, 2008 at 05:32:43PM +0800, lhmwzy wrote: > > > I create a zfs volume pool/lhm and give it quota 1M use "zfs set > > > quota=1m pool/lhm" > > > > > > #zfs get all pool/lhm > > > zfs get all pool/lhm > > > [ttyp0][5:22:12pm] > > > NAME PROPERTY VALUE SOURCE > > > pool/lhm type filesystem - > > > pool/lhm creation Tue Oct 7 17:14 2008 - > > > pool/lhm used 1.00M - > > > pool/lhm available 0 - > > > pool/lhm referenced 1.00M - > > > pool/lhm compressratio 7.25x - > > Turn compression off and retry. Yep, that's the key! # zfs set quota=4g storage/home # zfs set compression=off storage # zfs get compression,quota,mountpoint NAME PROPERTY VALUE SOURCE storage compression off local storage quota none default storage mountpoint /storage default storage/home compression off inherited from storage storage/home quota 4G local storage/home mountpoint /home local # dd if=/dev/zero of=/home/filler bs=1g count=8 dd: /home/filler: Disc quota exceeded 4+0 records in 3+1 records out 3306553344 bytes transferred in 62.566567 secs (52848566 bytes/sec) # df -h /home Filesystem Size Used Avail Capacity Mounted on storage/home 4.0G 4.0G 0B 100% /home I had no idea compression could cause this. A useful feature, but obviously can result in misleading results... :-) Thanks as usual, Pawel! -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From pjd at FreeBSD.org Tue Oct 7 10:33:10 2008 From: pjd at FreeBSD.org (Pawel Jakub Dawidek) Date: Tue Oct 7 10:33:19 2008 Subject: zfs quota question In-Reply-To: <20081007102959.GA46215@icarus.home.lan> References: <78fb9d960810070232u3f35010dv510dfa0fb2285568@mail.gmail.com> <20081007095437.GA44716@icarus.home.lan> <20081007101755.GB3464@garage.freebsd.pl> <20081007102959.GA46215@icarus.home.lan> Message-ID: <20081007103319.GC3464@garage.freebsd.pl> On Tue, Oct 07, 2008 at 03:30:09AM -0700, Jeremy Chadwick wrote: > On Tue, Oct 07, 2008 at 12:17:55PM +0200, Pawel Jakub Dawidek wrote: > > Turn compression off and retry. > > Yep, that's the key! > > # zfs set quota=4g storage/home > # zfs set compression=off storage > # zfs get compression,quota,mountpoint > NAME PROPERTY VALUE SOURCE > storage compression off local > storage quota none default > storage mountpoint /storage default > storage/home compression off inherited from storage > storage/home quota 4G local > storage/home mountpoint /home local > > # dd if=/dev/zero of=/home/filler bs=1g count=8 > dd: /home/filler: Disc quota exceeded > 4+0 records in > 3+1 records out > 3306553344 bytes transferred in 62.566567 secs (52848566 bytes/sec) > > # df -h /home > Filesystem Size Used Avail Capacity Mounted on > storage/home 4.0G 4.0G 0B 100% /home > > I had no idea compression could cause this. A useful feature, but > obviously can result in misleading results... :-) Yeah, ZFS offers a lot, which can create confusion, unfortunately. Do we limit physical space with quota or only logical (before compression)? Should we take space consumed by snapshots into account or not? etc. -- Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20081007/9bba7a22/attachment-0001.pgp From petefrench at ticketswitch.com Tue Oct 7 10:43:49 2008 From: petefrench at ticketswitch.com (Pete French) Date: Tue Oct 7 10:43:56 2008 Subject: zfs quota question In-Reply-To: <20081007103319.GC3464@garage.freebsd.pl> Message-ID: > Yeah, ZFS offers a lot, which can create confusion, unfortunately. Do we > limit physical space with quota or only logical (before compression)? > Should we take space consumed by snapshots into account or not? etc. On a related note, is there any way to make du tell me how big files are in actual bytes on a compressed ZFS filesystem, aas opposed to space on the disc ? I love ZFS, but I suddenly found out last night that I have lost the ability tto do a 'du' on a directory to work out if it will fit onto a CD or not :-) -pete. From lhmwzy at gmail.com Tue Oct 7 10:56:53 2008 From: lhmwzy at gmail.com (lhmwzy) Date: Tue Oct 7 10:57:02 2008 Subject: zfs quota question In-Reply-To: <20081007095925.GA19896@intserv.int1.b.intern> References: <78fb9d960810070232u3f35010dv510dfa0fb2285568@mail.gmail.com> <20081007095925.GA19896@intserv.int1.b.intern> Message-ID: <78fb9d960810070356o3f0b3913n862d9cf011e52065@mail.gmail.com> sorry,I make a mistake. It is a filesystem,not a volume. 2008/10/7 Holger Kipp : > according to zfs manpage: > > Quotas cannot be set on volumes, as the "volsize" property acts as > an implicit quota. > From lhmwzy at gmail.com Tue Oct 7 11:00:21 2008 From: lhmwzy at gmail.com (lhmwzy) Date: Tue Oct 7 11:00:29 2008 Subject: zfs quota question In-Reply-To: <20081007101755.GB3464@garage.freebsd.pl> References: <78fb9d960810070232u3f35010dv510dfa0fb2285568@mail.gmail.com> <20081007095437.GA44716@icarus.home.lan> <20081007101755.GB3464@garage.freebsd.pl> Message-ID: <78fb9d960810070400v170e3220i285120dd388951b9@mail.gmail.com> You're right. I turn off the compression,everything go well. So this is my problem,not a ZFS of FreeBSD problme. Tks for reply. 2008/10/7 Pawel Jakub Dawidek : .00M - >> > pool/lhm compressratio 7.25x - > > Turn compression off and retry. > From lhmwzy at gmail.com Tue Oct 7 11:03:46 2008 From: lhmwzy at gmail.com (lhmwzy) Date: Tue Oct 7 11:03:55 2008 Subject: zfs quota question In-Reply-To: References: <20081007103319.GC3464@garage.freebsd.pl> Message-ID: <78fb9d960810070403k15681b40vccb8532b8a16c84d@mail.gmail.com> Yes,this is a problem. In my case,"du -h" displays 1M,but the actual size is about 24M. 2008/10/7 Pete French : >> Yeah, ZFS offers a lot, which can create confusion, unfortunately. Do we >> limit physical space with quota or only logical (before compression)? >> Should we take space consumed by snapshots into account or not? etc. > > On a related note, is there any way to make du tell me how big files > are in actual bytes on a compressed ZFS filesystem, aas opposed to space > on the disc ? I love ZFS, but I suddenly found out last night that I > have lost the ability tto do a 'du' on a directory to work out if it will > fit onto a CD or not :-) > > -pete. > From max at love2party.net Tue Oct 7 11:27:23 2008 From: max at love2party.net (Max Laier) Date: Tue Oct 7 11:27:31 2008 Subject: zfs quota question In-Reply-To: References: Message-ID: <200810071314.45922.max@love2party.net> On Tuesday 07 October 2008 12:43:45 Pete French wrote: > > Yeah, ZFS offers a lot, which can create confusion, unfortunately. Do we > > limit physical space with quota or only logical (before compression)? > > Should we take space consumed by snapshots into account or not? etc. > > On a related note, is there any way to make du tell me how big files > are in actual bytes on a compressed ZFS filesystem, aas opposed to space > on the disc ? I love ZFS, but I suddenly found out last night that I > have lost the ability tto do a 'du' on a directory to work out if it will > fit onto a CD or not :-) But you can't do that on UFS either: sparse files, hardlinks, ... The GNU du(1) has a "--apparent-size" switch to get the logical size instead of what the tool's name suggests (the disk usage). -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From gerrit at pmp.uni-hannover.de Tue Oct 7 12:37:35 2008 From: gerrit at pmp.uni-hannover.de (Gerrit =?ISO-8859-1?Q?K=FChn?=) Date: Tue Oct 7 12:37:43 2008 Subject: Regression 7.0R -> 7-stable? In-Reply-To: <20081007133801.00349649.gerrit@pmp.uni-hannover.de> References: <20080807132947.061d24eb.gerrit@pmp.uni-hannover.de> <489B7D62.4080606@delphij.net> <20080814084637.97997c02.gerrit@pmp.uni-hannover.de> <200808230750.09774.jhb@freebsd.org> <20080825094923.d2d29148.gerrit@pmp.uni-hannover.de> <20080825075332.GA64793@eos.sc1.parodius.com> <20080827111629.eba80560.gerrit@pmp.uni-hannover.de> <20081007133801.00349649.gerrit@pmp.uni-hannover.de> Message-ID: <20081007143724.a01502e4.gerrit@pmp.uni-hannover.de> On Tue, 7 Oct 2008 13:38:01 +0200 Gerrit K?hn wrote about Re: Regression 7.0R -> 7-stable?: [...] GK> However, yesterday I upgraded the system to a recent 7-stable GK> codebase, and now it locks again hard after probing the CPU cores. My GK> setup remained exactly the same, the new code just does not work. GK> Please let me know what I have do to provide further information. Well, comparing the kernel setups again I found one thing that makes a difference: The scheduler (somewhen SCHED_ULE has been declared the default). SCHED_ULE is crashing the system, SCHED_4BSD works fine... cu Gerrit From admin at kkip.pl Tue Oct 7 12:41:45 2008 From: admin at kkip.pl (Bartosz Stec) Date: Tue Oct 7 12:41:53 2008 Subject: reloading samba config made system unresponsible In-Reply-To: <48EA1FD2.5080402@kkip.pl> References: <48EA1FD2.5080402@kkip.pl> Message-ID: <48EB5900.7040103@kkip.pl> Bartosz Stec wrote: > My tries to tune smb.conf to achieve better performance expose very > strange bug: > Just executing: > > /usr/local/etc/rc.d/samba reload > > made my system unresponsible from network. It happens three times > until now so I'm sure that is the cause (but it happened after some > succesful reloads a couple of minutes earlier, so it's not happening > all the time command is executed). > Symptoms: > > - machine only responding to ping requests > - ssh session shows, that config reload was succesful, and that's > last thing showed (no shell after message) > - can't connect with another ssh session, but no refuse nor timeout > - on local console system seems responsible (alt +[1-9] works), but > any try to login cause it to wait forever for password prompt > - no kernel or error message on screen, and nothing suspicious in logs > - alt+ctrl+del does nothing > - pressing power button and waiting for system to shutdown does > nothing > - hard reset was the only way > - after first restart I've made full fsck and started rebuilding > gmirror - when machine hangs second time rebuilding doesn't stop > > I'm not a developer but it looks like some kind of deadlock? Note that > changes I made to smb.conf was only in socket options. > Update: The true reason of this was a filesystem - I've noticed some strange kernel message about "old format snaphot". Fsck didn't found any fs error, so I just deleted all snapshots from /usr. Problem is gone now. Note that snapshots were about 2 months old so it's still scary :) Sorry for confusion. -- Bartosz Stec From andrew at modulus.org Tue Oct 7 12:50:01 2008 From: andrew at modulus.org (Andrew Snow) Date: Tue Oct 7 12:50:08 2008 Subject: zfs quota question In-Reply-To: <200810071314.45922.max@love2party.net> References: <200810071314.45922.max@love2party.net> Message-ID: <48EB5ADD.2090900@modulus.org> >I love ZFS, but I suddenly found out last night that I > have lost the ability tto do a 'du' on a directory to work out if it will > fit onto a CD or not :-) I have created a shell script, /usr/local/bin/dirsize : #!/bin/sh find $1 -type f -ls | awk '{j += $7} END {print j}' Usage: dirsize From gerrit at pmp.uni-hannover.de Tue Oct 7 12:51:58 2008 From: gerrit at pmp.uni-hannover.de (Gerrit =?ISO-8859-1?Q?K=FChn?=) Date: Tue Oct 7 12:52:05 2008 Subject: Regression 7.0R -> 7-stable? In-Reply-To: <20080827111629.eba80560.gerrit@pmp.uni-hannover.de> References: <20080807132947.061d24eb.gerrit@pmp.uni-hannover.de> <489B7D62.4080606@delphij.net> <20080814084637.97997c02.gerrit@pmp.uni-hannover.de> <200808230750.09774.jhb@freebsd.org> <20080825094923.d2d29148.gerrit@pmp.uni-hannover.de> <20080825075332.GA64793@eos.sc1.parodius.com> <20080827111629.eba80560.gerrit@pmp.uni-hannover.de> Message-ID: <20081007133801.00349649.gerrit@pmp.uni-hannover.de> On Wed, 27 Aug 2008 11:16:29 +0200 Gerrit K?hn wrote about Re: Regression 7.0R -> 7-stable?: [...] GK> If someone can tell me what to do (except for putting ddb into the GK> kernel configuration) or point me at some documentation about this, I GK> can try getting some useful information from the debugger. Sorry to disturb all of you again, but the thing is still not fixed (or better: broken again) for me: I saw some patches referring to this problem and was able to compile a working kernel somewhen in September (don't know the exact date unfortunatley, but the kernel is from 22nd of September, so this is the latest possible date). After that I thought the issue had settled. However, yesterday I upgraded the system to a recent 7-stable codebase, and now it locks again hard after probing the CPU cores. My setup remained exactly the same, the new code just does not work. Please let me know what I have do to provide further information. cu Gerrit From koitsu at FreeBSD.org Tue Oct 7 13:37:13 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Tue Oct 7 13:37:19 2008 Subject: Regression 7.0R -> 7-stable? In-Reply-To: <20081007143724.a01502e4.gerrit@pmp.uni-hannover.de> References: <20080807132947.061d24eb.gerrit@pmp.uni-hannover.de> <489B7D62.4080606@delphij.net> <20080814084637.97997c02.gerrit@pmp.uni-hannover.de> <200808230750.09774.jhb@freebsd.org> <20080825094923.d2d29148.gerrit@pmp.uni-hannover.de> <20080825075332.GA64793@eos.sc1.parodius.com> <20080827111629.eba80560.gerrit@pmp.uni-hannover.de> <20081007133801.00349649.gerrit@pmp.uni-hannover.de> <20081007143724.a01502e4.gerrit@pmp.uni-hannover.de> Message-ID: <20081007133710.GA50114@icarus.home.lan> On Tue, Oct 07, 2008 at 02:37:24PM +0200, Gerrit K?hn wrote: > On Tue, 7 Oct 2008 13:38:01 +0200 Gerrit K?hn > wrote about Re: Regression 7.0R -> 7-stable?: > > [...] > > GK> However, yesterday I upgraded the system to a recent 7-stable > GK> codebase, and now it locks again hard after probing the CPU cores. My > GK> setup remained exactly the same, the new code just does not work. > GK> Please let me know what I have do to provide further information. > > Well, comparing the kernel setups again I found one thing that makes a > difference: The scheduler (somewhen SCHED_ULE has been declared the > default). > SCHED_ULE is crashing the system, SCHED_4BSD works fine... This is of great concern if in fact that's true. I'm adding Jeff Roberson, author of the ULE/SMP2.0 code, to the CC. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From jhb at freebsd.org Tue Oct 7 14:04:37 2008 From: jhb at freebsd.org (John Baldwin) Date: Tue Oct 7 14:04:44 2008 Subject: Regression 7.0R -> 7-stable? In-Reply-To: <20081007133710.GA50114@icarus.home.lan> References: <20080807132947.061d24eb.gerrit@pmp.uni-hannover.de> <20081007143724.a01502e4.gerrit@pmp.uni-hannover.de> <20081007133710.GA50114@icarus.home.lan> Message-ID: <200810071002.56788.jhb@freebsd.org> On Tuesday 07 October 2008 09:37:10 am Jeremy Chadwick wrote: > On Tue, Oct 07, 2008 at 02:37:24PM +0200, Gerrit K?hn wrote: > > On Tue, 7 Oct 2008 13:38:01 +0200 Gerrit K?hn > > wrote about Re: Regression 7.0R -> 7-stable?: > > > > [...] > > > > GK> However, yesterday I upgraded the system to a recent 7-stable > > GK> codebase, and now it locks again hard after probing the CPU cores. My > > GK> setup remained exactly the same, the new code just does not work. > > GK> Please let me know what I have do to provide further information. > > > > Well, comparing the kernel setups again I found one thing that makes a > > difference: The scheduler (somewhen SCHED_ULE has been declared the > > default). > > SCHED_ULE is crashing the system, SCHED_4BSD works fine... > > This is of great concern if in fact that's true. > > I'm adding Jeff Roberson, author of the ULE/SMP2.0 code, to the CC. Do you have more details about the crash? Are you getting an actual panic with messages on the console, or are you still seeing hangs? When you get a hang, can you break into the debugger and get a crash dump? -- John Baldwin From gerrit at pmp.uni-hannover.de Tue Oct 7 14:15:46 2008 From: gerrit at pmp.uni-hannover.de (Gerrit =?ISO-8859-1?Q?K=FChn?=) Date: Tue Oct 7 14:15:53 2008 Subject: Regression 7.0R -> 7-stable? In-Reply-To: <200810071002.56788.jhb@freebsd.org> References: <20080807132947.061d24eb.gerrit@pmp.uni-hannover.de> <20081007143724.a01502e4.gerrit@pmp.uni-hannover.de> <20081007133710.GA50114@icarus.home.lan> <200810071002.56788.jhb@freebsd.org> Message-ID: <20081007161534.b62b6333.gerrit@pmp.uni-hannover.de> On Tue, 7 Oct 2008 10:02:56 -0400 John Baldwin wrote about Re: Regression 7.0R -> 7-stable?: JB> Do you have more details about the crash? Are you getting an actual JB> panic with messages on the console, or are you still seeing hangs? Like it was before: system just hangs after displaying the probing messages about the CPU cores; next step for a working kernel would be mounting of the file systems (and changing from white kernel output to grey system output). JB> When you get a hang, can you break into the debugger and get a crash JB> dump? Is there a documentation somewhere how to do this? cu Gerrit From koitsu at FreeBSD.org Tue Oct 7 14:25:45 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Tue Oct 7 14:25:53 2008 Subject: Regression 7.0R -> 7-stable? In-Reply-To: <20081007161534.b62b6333.gerrit@pmp.uni-hannover.de> References: <20080807132947.061d24eb.gerrit@pmp.uni-hannover.de> <20081007143724.a01502e4.gerrit@pmp.uni-hannover.de> <20081007133710.GA50114@icarus.home.lan> <200810071002.56788.jhb@freebsd.org> <20081007161534.b62b6333.gerrit@pmp.uni-hannover.de> Message-ID: <20081007142542.GA51071@icarus.home.lan> On Tue, Oct 07, 2008 at 04:15:34PM +0200, Gerrit K?hn wrote: > On Tue, 7 Oct 2008 10:02:56 -0400 John Baldwin wrote > about Re: Regression 7.0R -> 7-stable?: > > JB> Do you have more details about the crash? Are you getting an actual > JB> panic with messages on the console, or are you still seeing hangs? > > Like it was before: system just hangs after displaying the probing > messages about the CPU cores; next step for a working kernel would be > mounting of the file systems (and changing from white kernel output to grey > system output). Actually, I think you mean mounting of the root filesystem, do you not? If so, others have recently reported this problem (hard lock-ups before or after printing "Mounting root from..."). > JB> When you get a hang, can you break into the debugger and get a crash > JB> dump? > > Is there a documentation somewhere how to do this? John can probably help you with the commands you need to type, but the FreeBSD Handbook goes over the general commands. As far as getting into the debugger, it's Control-Alt-Esc from the console. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From mike at sentex.net Tue Oct 7 14:57:02 2008 From: mike at sentex.net (Mike Tancsa) Date: Tue Oct 7 14:57:09 2008 Subject: Possibility of backporting of Heimdal 1.1 In-Reply-To: <48EA820F.1030109@gmail.com> References: <20081006140255.GA74575@sr.se> <48EA820F.1030109@gmail.com> Message-ID: <200810071456.m97Eun8J064681@lava.sentex.ca> At 05:24 PM 10/6/2008, Galen Sampson wrote: >I would like to second that. The heimdal in 7.0 is quite old. It >is in fact inoperable with an mit kerberos realm when using >ssh. The byte order is incorrect such that you get MIC checksum >failures. After much googling (not documented in the krb5.conf man >page or handbook) I found that a fix was added in the heimdal in >7.0, but defaults to the old incompatible byte order. The heimdal >in current uses the correct byte order by default. For those having >the this issue with freebsd 7.0 the fix is adding the following >lines to /etc/krb5.conf: > >[gssapi] >correct_des3_mic = host/*@SOME.REALM > >Gunnar Flygt wrote: >>Is there any possibility that heimdal 1.1 that works beautifully in >>Current will be backported to FreeBSD-7.x? >> >>Gunnar Flygt >>Sveriges Radio Teknik/IT I think someone mentioned the possibility of post 7.1R. But not 100% sure ---Mike From gerrit at pmp.uni-hannover.de Tue Oct 7 15:07:53 2008 From: gerrit at pmp.uni-hannover.de (Gerrit =?ISO-8859-1?Q?K=FChn?=) Date: Tue Oct 7 15:08:00 2008 Subject: Regression 7.0R -> 7-stable? In-Reply-To: <20081007142542.GA51071@icarus.home.lan> References: <20080807132947.061d24eb.gerrit@pmp.uni-hannover.de> <20081007143724.a01502e4.gerrit@pmp.uni-hannover.de> <20081007133710.GA50114@icarus.home.lan> <200810071002.56788.jhb@freebsd.org> <20081007161534.b62b6333.gerrit@pmp.uni-hannover.de> <20081007142542.GA51071@icarus.home.lan> Message-ID: <20081007170742.75669f32.gerrit@pmp.uni-hannover.de> On Tue, 7 Oct 2008 07:25:42 -0700 Jeremy Chadwick wrote about Re: Regression 7.0R -> 7-stable?: JC> > Like it was before: system just hangs after displaying the probing JC> > messages about the CPU cores; next step for a working kernel would JC> > be mounting of the file systems (and changing from white kernel JC> > output to grey system output). JC> Actually, I think you mean mounting of the root filesystem, do you not? JC> If so, others have recently reported this problem (hard lock-ups JC> before or after printing "Mounting root from..."). Yes, of course (sorry for being vague). JC> > JB> When you get a hang, can you break into the debugger and get a JC> > JB> crash dump? JC> > Is there a documentation somewhere how to do this? JC> John can probably help you with the commands you need to type, but the JC> FreeBSD Handbook goes over the general commands. JC> As far as getting into the debugger, it's Control-Alt-Esc from the JC> console. Ok, I added options KDB and DDB to my kernel configuration and compiled with SCHED_ULE. However, after hanging the system does not react on Ctrl-Alt-Esc. Am I missing something? cu Gerrit From jhb at freebsd.org Tue Oct 7 16:36:57 2008 From: jhb at freebsd.org (John Baldwin) Date: Tue Oct 7 16:37:04 2008 Subject: Regression 7.0R -> 7-stable? In-Reply-To: <20081007170742.75669f32.gerrit@pmp.uni-hannover.de> References: <20080807132947.061d24eb.gerrit@pmp.uni-hannover.de> <20081007142542.GA51071@icarus.home.lan> <20081007170742.75669f32.gerrit@pmp.uni-hannover.de> Message-ID: <200810071205.35961.jhb@freebsd.org> On Tuesday 07 October 2008 11:07:42 am Gerrit K?hn wrote: > JC> John can probably help you with the commands you need to type, but the > JC> FreeBSD Handbook goes over the general commands. > JC> As far as getting into the debugger, it's Control-Alt-Esc from the > JC> console. > > Ok, I added options KDB and DDB to my kernel configuration and compiled > with SCHED_ULE. However, after hanging the system does not react on > Ctrl-Alt-Esc. Am I missing something? Can you add VERBOSE_SYSINIT to your kernel config and do a boot -v? Also, are you able to log the output at all (such as via a serial console)? -- John Baldwin From xernet at hotmail.it Tue Oct 7 16:42:25 2008 From: xernet at hotmail.it (xer xernet) Date: Tue Oct 7 16:42:32 2008 Subject: stable 7.0 and nslookup help command In-Reply-To: References: Message-ID: Hello to anyone. I'm a FreeBSD user, i'm still a new bee but i still keep to learning. Anyway, here is my question: I use a FreeBSD STABLE-7 not installed by me, in this installation nslookup works very good and the "?" or "help" command working properly, infact the every time i recall the command "?" or "help" nslookup show me the file "nslookup.help" in /usr/share/misc. Now, i did installed (by me) e STABLE-7 and i don't understand why the "?" command is not implemented on nslookup, also the file "nslookup.help" doen't exist. How can i implement this feature on my fresh STABLE-7 install ? TIA xer _________________________________________________________________ Tutto il mondo MSN a portata di clic! http://toolbar.msn.com/overview.aspx?loc=it-it From koitsu at FreeBSD.org Tue Oct 7 17:33:44 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Tue Oct 7 17:33:51 2008 Subject: stable 7.0 and nslookup help command In-Reply-To: References: Message-ID: <20081007173341.GA54495@icarus.home.lan> On Tue, Oct 07, 2008 at 06:30:23PM +0200, xer xernet wrote: > Hello to anyone. > > I'm a FreeBSD user, i'm still a new bee but i still keep to learning. > Anyway, here is my question: > > I use a FreeBSD STABLE-7 not installed by me, in this installation nslookup works very good and the "?" or "help" command working properly, infact the every time i recall the command "?" or "help" nslookup show me the file "nslookup.help" in /usr/share/misc. > > Now, i did installed (by me) e STABLE-7 and i don't understand why the "?" command is not implemented on nslookup, also the file "nslookup.help" doen't exist. > How can i implement this feature on my fresh STABLE-7 install ? Not to dissuade you from what you're trying to accomplish, but "nslookup" has been deprecated (this has been stated a few times by the BIND folks), and "host" is probably on its way out as well (though I remember somewhere, sometime, nslookup used to state "being deprecated, use 'host' or 'dig' instead" -- or something like that). Please learn to use the "dig" command. I realise it has a somewhat high learning curve at first (syntax-wise it can be somewhat messy), but ultimately it's an immensely powerful -- or simple! -- DNS tool. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From joe at osoft.us Tue Oct 7 19:02:16 2008 From: joe at osoft.us (Joe Koberg) Date: Tue Oct 7 19:02:22 2008 Subject: fxp performance with POLLING In-Reply-To: References: Message-ID: <48EBAB50.5000707@osoft.us> Pete French wrote: >> 1 megabit = 106 = 1,000,000 bits which is equal to 125,000 bytes. >> > > you are assuming eight bits per byte - but this is a serial line so > you should use ten bits per byte instead. > > -pete. > That was a rule of thumb in the heyday of async serial lines, which used a start and stop bit per byte. However, ethernet at 100Mbit is 4B5B coded at a 125mhz rate. So the raw synchronous data rate really is 12.5Mbytes/s. Minus the sync preamble of 8 bytes per packet and the mandatory inter-frame-gap of 12 bytes that's a physical layer rate of (12.5M * (1500/(1500+20))) or 12.34Mbyte/s. Even in the later days of modems this rule applied less and less, because the modulation schemes became synchronous. Joe Koberg joe_at_osoft_dot_us From sthaug at nethelp.no Tue Oct 7 19:24:58 2008 From: sthaug at nethelp.no (sthaug@nethelp.no) Date: Tue Oct 7 19:25:06 2008 Subject: fxp performance with POLLING In-Reply-To: <48EBAB50.5000707@osoft.us> References: <48EBAB50.5000707@osoft.us> Message-ID: <20081007.212455.74712524.sthaug@nethelp.no> > However, ethernet at 100Mbit is 4B5B coded at a 125mhz rate. So the raw > synchronous data rate really is 12.5Mbytes/s. Minus the sync preamble > of 8 bytes per packet and the mandatory inter-frame-gap of 12 bytes > that's a physical layer rate of (12.5M * (1500/(1500+20))) or 12.34Mbyte/s. You need add Ethernet header (14 bytes) + CRC (4 bytes). This means you have a maximum data rate, assuming 1500 byte MTU, of 12.5M * 1500/1538 = 12.19 Mbyte/s. And for those used to powers of two, M here means one million, not 1048576. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From rwatson at FreeBSD.org Tue Oct 7 19:26:22 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Tue Oct 7 19:26:29 2008 Subject: stable 7.0 and nslookup help command In-Reply-To: <20081007173341.GA54495@icarus.home.lan> References: <20081007173341.GA54495@icarus.home.lan> Message-ID: On Tue, 7 Oct 2008, Jeremy Chadwick wrote: > Not to dissuade you from what you're trying to accomplish, but "nslookup" > has been deprecated (this has been stated a few times by the BIND folks), > and "host" is probably on its way out as well (though I remember somewhere, > sometime, nslookup used to state "being deprecated, use 'host' or 'dig' > instead" -- or something like that). > > Please learn to use the "dig" command. I realise it has a somewhat high > learning curve at first (syntax-wise it can be somewhat messy), but > ultimately it's an immensely powerful -- or simple! -- DNS tool. Ditto here -- dig requires a bit more understanding of DNS, but is actually a much more informative tool when it comes to querying DNS and debugging its quirks. Robert N M Watson Computer Laboratory University of Cambridge From petefrench at ticketswitch.com Tue Oct 7 20:53:09 2008 From: petefrench at ticketswitch.com (Pete French) Date: Tue Oct 7 20:53:16 2008 Subject: fxp performance with POLLING In-Reply-To: <48EBAB50.5000707@osoft.us> Message-ID: > That was a rule of thumb in the heyday of async serial lines, which used > a start and stop bit per byte. > > However, ethernet at 100Mbit is 4B5B coded at a 125mhz rate. So the raw Errr, 4B5B *is* 10 bits per byte surely? > Even in the later days of modems this rule applied less and less, > because the modulation schemes became synchronous. Gig ether is mainly 8B10, as is Firewire, SATA, FibreChannel and a load of others I can't remember off the top of my head. I wouldn't stay it's a hard and fast rule, but it still gives a better estimate than dividing by eight which is what people naiively do. Mind you, it assumes that you know the real bit rate, which in the case of 100baseT is, as you say, actualy 125mbits/sec. -pete. From joe at osoft.us Tue Oct 7 21:27:50 2008 From: joe at osoft.us (Joe Koberg) Date: Tue Oct 7 21:28:02 2008 Subject: fxp performance with POLLING In-Reply-To: References: Message-ID: <48EBD437.4050300@osoft.us> Pete French wrote: >> However, ethernet at 100Mbit is 4B5B coded at a 125mhz rate. So the raw >> > > Errr, 4B5B *is* 10 bits per byte surely? > ... > Gig ether is mainly 8B10, as is Firewire, SATA, FibreChannel and a > > Mind you, it assumes that you know the real bit rate, which in the > case of 100baseT is, as you say, actualy 125mbits/sec. > You are right. It definitely is 10 bits per byte clocked at a higher rate. I guess the "100mbit/s" rate is so strongly associated with the technology that I glossed right over that. Joe From delphij at delphij.net Tue Oct 7 22:11:02 2008 From: delphij at delphij.net (Xin LI) Date: Tue Oct 7 22:11:09 2008 Subject: [FreeBSD] Fix for ServerWorks HT1000 in upcoming 7.1? In-Reply-To: <200810011134.49795.jhb@freebsd.org> References: <520894aa0809301434h68b94628x54ec08fd48785feb@mail.gmail.com> <200810011134.49795.jhb@freebsd.org> Message-ID: <48EBDE69.1030609@delphij.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Did anyone who can trigger the data corruption has tried John's patch and let us know if it worked? Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkjr3mkACgkQi+vbBBjt66CW2gCcC6VaWPA7HE3Pd6CLfa3lkNUz r0MAnAsQI54d28MdeSOYZCQmFguT9EFV =xM/C -----END PGP SIGNATURE----- From oberman at es.net Tue Oct 7 22:44:25 2008 From: oberman at es.net (Kevin Oberman) Date: Tue Oct 7 22:44:36 2008 Subject: stable 7.0 and nslookup help command In-Reply-To: Your message of "Tue, 07 Oct 2008 20:26:21 BST." Message-ID: <20081007224422.5388D4500F@ptavv.es.net> More importantly, dig(1) uses the standard resolver routines while nslookup has its own. This has, in some cases, resulted in different results from nslookup than for what the stub resolver returns which can really lead one down the primrose path when troubleshooting. I consider nslookup to be evil. host(1) and dig(1) work well and I have not seen any plans to deprecate host(1). It's just that host is a quick lookup tool while dig(1) is a serious tool for DNS analysis and testing. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 224 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20081007/eb722541/attachment.pgp From kabaev at gmail.com Tue Oct 7 23:26:45 2008 From: kabaev at gmail.com (Alexander Kabaev) Date: Tue Oct 7 23:26:52 2008 Subject: Help me to develop a FreeBSD patch for gcc-4.2.1 In-Reply-To: <669322.44942.qm@web57005.mail.re3.yahoo.com> References: <669322.44942.qm@web57005.mail.re3.yahoo.com> Message-ID: <20081007185328.29220983@kan.dnsalias.net> On Mon, 6 Oct 2008 06:19:34 -0700 (PDT) Unga wrote: > Hi all > > I need to patch the gcc original sources to suit the FreeBSD, > specially to support FreeBSD kernel compilation. I have tried it, > spent lot of time, but it still develops compilation errors. > > The FreeBSD stable comes with gcc-4.2.1 but the sources are scattered > over the /usr/src, therefore, I find it difficult to re-create the > gcc-4.2.1 to its original directory layout to make a patch. > > I appreciate it very much, if you guys could help me to identify the > pieces. > > Or alternatively, if someone could straight away put the FreeBSD gcc > sources back to a directory and make a patch compared to the original > gcc-4.2.1 sources from GNU and post here, I could apply the patch on > my side and verify it was done correctly, whether I can compile the > FreeBSD kernel or not. > > Many thanks in advance. > > Kind regards > Unga If you still have CVS tree available, you can do 'cvs diff -rFSF' in contrib/gcc and apply the patches to files gcc-4.2.1/gcc. -- Alexander Kabaev -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20081007/40805711/signature.pgp From unga888 at yahoo.com Wed Oct 8 03:25:05 2008 From: unga888 at yahoo.com (Unga) Date: Wed Oct 8 03:25:12 2008 Subject: Help me to develop a FreeBSD patch for gcc-4.2.1 In-Reply-To: <20081007185328.29220983@kan.dnsalias.net> Message-ID: <72513.12488.qm@web57002.mail.re3.yahoo.com> --- On Wed, 10/8/08, Alexander Kabaev wrote: > > If you still have CVS tree available, you can do 'cvs > diff -rFSF' in > contrib/gcc and apply the patches to files gcc-4.2.1/gcc. > Hi Alexander, thanks for the reply. I'm new to 'cvs diff -rFSF'. I need to do more home work before I try your method. Could you kindly confirm it work for you? after applying the patch, does your compilation of gcc complete cleanly? I get errors. Therefore, could you try it please. I'm waiting for your reply. Best regards Unga From delphij at delphij.net Wed Oct 8 03:43:21 2008 From: delphij at delphij.net (Xin LI) Date: Wed Oct 8 03:43:27 2008 Subject: Would anybody port DragonFlyBSD's HAMMER fs to FreeBSD? In-Reply-To: <48E3F900.8020702@quip.cz> References: <78fb9d960809291927n60358006w7ef845e7cb40ed93@mail.gmail.com> <78fb9d960809301653o5cb09cefpf05eba0a9926b9fc@mail.gmail.com> <274267384.20080930223647@takeda.tk> <78fb9d960809302310s3f817505j6605420e451268e4@mail.gmail.com> <1031817271.20080930231836@takeda.tk> <78fb9d960809302329i5958966bh988c2531741e5c1@mail.gmail.com> <20081001071309.GA13616@icarus.home.lan> <78fb9d960810010015l14a98f56re49c9eb386305118@mail.gmail.com> <48E3F900.8020702@quip.cz> Message-ID: <48EC2C4B.10909@delphij.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Miroslav Lachman wrote: [...] > I have no crash of ZFS, but as I read in mailing lists, there are still > some problems, so let it be fixed and settle down before porting another > good filesystem. > > Just my ?0.02 For the record, pjd@'s previous ZFSv11 snapshot against -CURRENT has been proven to be very stable on our test environment (FreeBSD/amd64 on 2*4 core with 16GB of RAM box, JBOD 12 disks set up with 5+5 RAIID-Z2, 2 spare). My hope is that we can see the commit by the end of year so we will have a couple of months before having it in 7.2-RELEASE. The current version in RELENG_7 is also reasonably stable, at very least better than 7.0-RELEASE. Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkjsLEsACgkQi+vbBBjt66CgqQCfRVlsfp7XUbv7XckjBNXXLLob +gUAmwebeOqNHMH2yjo/MC31ngcRMGPb =96eo -----END PGP SIGNATURE----- From andrew-freebsd at areilly.bpc-users.org Wed Oct 8 03:49:14 2008 From: andrew-freebsd at areilly.bpc-users.org (Andrew Reilly) Date: Wed Oct 8 03:49:21 2008 Subject: Is FreeBSD a suitable choice for a MacBook? In-Reply-To: <3c1674c90810050210n5be68940me0b7214001f6fd1d@mail.gmail.com> References: <48E7BD60.80001@nynorsk.no> <83D0ECC4-B5F1-49E5-B437-52B3753F68F4@hiwaay.net> <3c1674c90810050210n5be68940me0b7214001f6fd1d@mail.gmail.com> Message-ID: <20081008034836.GA32263@duncan.reilly.home> On Sun, Oct 05, 2008 at 02:10:59AM -0700, Kip Macy wrote: > > You sound as if you just got the machine and haven't given MacOS X a chance. > > Give MacOS X a chance. Download (if its not on your MacOS X install DVD) X > > Code, and Apple X11. > > X11 is barely usable under Leopard. I've heard a few people complain about X11 on Mac, and I wonder what it is that they're doing that I'm not. Since my "other" systems are all FreeBSD, I use quite a few X11 applications on my two MacOS laptops (Tiger on PPC, Leopard on intel) The *only* problem I've ever had with X11 was on Tiger, where every so often the X11 server couldn't be contacted after coming out of sleep. Restarting X11 fixes that with no particular grief. Under Leopard it's rock solid reliable for my use. > Apps crash regularly and > full-screen doesn't work. Apps in general, or X11 ones? The only X11 full-screen app that I can think of is openoffice's presentation thing. I remember that working OK, but so did the Java GUI on NeoOffice, and now I'm using the experimental Aqua version, which also works properly, as far as I can tell. > He may simply want to be able to boot in to FreeBSD as well. Sure. I've thought about it myself on numerous occasions, but ultimately I can't think of anything that I could do within FreeBSD that I can't already do under MacOS. If I really, really want a FreeBSD environment, I've got VMWare (which is currently doing some Debian Linux, which IMO is much more annoying than either FreeBSD or MacOs, but that's probbly just my inexperience talking.) Cheers, Andrew From lhmwzy at gmail.com Wed Oct 8 04:18:28 2008 From: lhmwzy at gmail.com (lhmwzy) Date: Wed Oct 8 04:18:36 2008 Subject: zfs quota question In-Reply-To: <48EB5ADD.2090900@modulus.org> References: <200810071314.45922.max@love2party.net> <48EB5ADD.2090900@modulus.org> Message-ID: <78fb9d960810072118k47a64097yaa486ef5179efb1@mail.gmail.com> The fllow is better? #!/bin/sh find $1 -type f -exec ls -lh {} \; | awk '{j += $5} END {print j"M"}' 2008/10/7 Andrew Snow : >> I love ZFS, but I suddenly found out last night that I >> have lost the ability tto do a 'du' on a directory to work out if it will >> fit onto a CD or not :-) > > I have created a shell script, /usr/local/bin/dirsize : > > > #!/bin/sh > find $1 -type f -ls | awk '{j += $7} END {print j}' > > > > Usage: dirsize > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From xernet at hotmail.it Wed Oct 8 06:36:29 2008 From: xernet at hotmail.it (xer xernet) Date: Wed Oct 8 06:36:36 2008 Subject: stable 7.0 and nslookup help command In-Reply-To: <20081007224422.5388D4500F@ptavv.es.net> References: Your message of <20081007224422.5388D4500F@ptavv.es.net> Message-ID: Yes, thanx to all of you and your answers.. I'm just a dig user now, but.. The question now is: - if i want to implement /usr/share/misc/nslookup.help in nslookup (even if nslookup is evil) how can i do that? I need to know, i want learn this "fact" i will not use nslookup anymore, but i'm still curios HOW was implemented on older STABLE-5.5 Thanx again :-) > To: rwatson@FreeBSD.org > CC: koitsu@FreeBSD.org; xernet@hotmail.it; freebsd-stable@freebsd.org > Subject: Re: stable 7.0 and nslookup help command > Date: Tue, 7 Oct 2008 15:44:22 -0700 > From: oberman@es.net > > More importantly, dig(1) uses the standard resolver routines while > nslookup has its own. This has, in some cases, resulted in different > results from nslookup than for what the stub resolver returns which can > really lead one down the primrose path when troubleshooting. > > I consider nslookup to be evil. host(1) and dig(1) work well and I have > not seen any plans to deprecate host(1). It's just that host is a quick > lookup tool while dig(1) is a serious tool for DNS analysis and testing. > -- > R. Kevin Oberman, Network Engineer > Energy Sciences Network (ESnet) > Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) > E-mail: oberman@es.net Phone: +1 510 486-8634 > Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 _________________________________________________________________ Comunica, gioca e divertiti con i tuoi amici su Messenger! http://www.messenger.it From smithi at nimnet.asn.au Wed Oct 8 06:43:54 2008 From: smithi at nimnet.asn.au (Ian Smith) Date: Wed Oct 8 06:44:01 2008 Subject: zfs quota question In-Reply-To: <78fb9d960810072118k47a64097yaa486ef5179efb1@mail.gmail.com> References: <200810071314.45922.max@love2party.net> <48EB5ADD.2090900@modulus.org> <78fb9d960810072118k47a64097yaa486ef5179efb1@mail.gmail.com> Message-ID: <20081008165835.C16723@sola.nimnet.asn.au> On Wed, 8 Oct 2008, lhmwzy wrote: > The fllow is better? > #!/bin/sh > find $1 -type f -exec ls -lh {} \; | awk '{j += $5} END {print j"M"}' Review your 'ls -lh' output; what's 100Bananas + 10Kiwifruit + 1Melon? $ find . -type f -exec ls -lh {} \; | awk '{j += $5} END {print j"M"}' 1.15975e+06M Took several minutes to come up with the wrong answer :) $ /root/bin/dirsize . 6906276646 Took 2.75 seconds, giving actual total of the file sizes. $ du -d0 . 6781976 . Took 1.5 seconds, and comes to 69447434424, ie bytes allocated for those files. All on a 300MHz Celeron. > 2008/10/7 Andrew Snow : > >> I love ZFS, but I suddenly found out last night that I > >> have lost the ability tto do a 'du' on a directory to work out if it will > >> fit onto a CD or not :-) > > > > I have created a shell script, /usr/local/bin/dirsize : > > > > #!/bin/sh > > find $1 -type f -ls | awk '{j += $7} END {print j}' > > > > Usage: dirsize And very handy it is too, even without compressed ZFS, thanks Andrew. cheers, Ian From koitsu at FreeBSD.org Wed Oct 8 07:04:37 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Wed Oct 8 07:04:45 2008 Subject: stable 7.0 and nslookup help command In-Reply-To: References: <20081007224422.5388D4500F@ptavv.es.net> Message-ID: <20081008070435.GA69493@icarus.home.lan> On Wed, Oct 08, 2008 at 08:36:29AM +0200, xer xernet wrote: > > Yes, thanx to all of you and your answers.. > I'm just a dig user now, but.. > The question now is: > - if i want to implement /usr/share/misc/nslookup.help in nslookup (even if nslookup is evil) how can i do that? > I need to know, i want learn this "fact" i will not use nslookup anymore, but i'm still curios HOW was implemented on older STABLE-5.5 I believe this would be a question for the BIND folks, not for FreeBSD. I'm willing to bet they removed the feature in later versions of nslookup. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From lhmwzy at gmail.com Wed Oct 8 07:20:00 2008 From: lhmwzy at gmail.com (lhmwzy) Date: Wed Oct 8 07:20:07 2008 Subject: zfs quota question In-Reply-To: <20081008165835.C16723@sola.nimnet.asn.au> References: <200810071314.45922.max@love2party.net> <48EB5ADD.2090900@modulus.org> <78fb9d960810072118k47a64097yaa486ef5179efb1@mail.gmail.com> <20081008165835.C16723@sola.nimnet.asn.au> Message-ID: <78fb9d960810080019j3b73e3ffidc189c716fb7a1de@mail.gmail.com> OK.It's my mistake. Improve it again: #!/bin/sh find $1 -type f -ls | awk '{j += $7} END {printf("%.2fM\n",j/1024/1024)}' 2008/10/8 Ian Smith : > On Wed, 8 Oct 2008, lhmwzy wrote: > > The fllow is better? > > #!/bin/sh > > find $1 -type f -exec ls -lh {} \; | awk '{j += $5} END {print j"M"}' > > Review your 'ls -lh' output; what's 100Bananas + 10Kiwifruit + 1Melon? > > $ find . -type f -exec ls -lh {} \; | awk '{j += $5} END {print j"M"}' > 1.15975e+06M > > Took several minutes to come up with the wrong answer :) > > $ /root/bin/dirsize . > 6906276646 > > Took 2.75 seconds, giving actual total of the file sizes. > > $ du -d0 . > 6781976 . > > Took 1.5 seconds, and comes to 69447434424, ie bytes allocated for those > files. All on a 300MHz Celeron. > > > 2008/10/7 Andrew Snow : > > >> I love ZFS, but I suddenly found out last night that I > > >> have lost the ability tto do a 'du' on a directory to work out if it will > > >> fit onto a CD or not :-) > > > > > > I have created a shell script, /usr/local/bin/dirsize : > > > > > > #!/bin/sh > > > find $1 -type f -ls | awk '{j += $7} END {print j}' > > > > > > Usage: dirsize > > And very handy it is too, even without compressed ZFS, thanks Andrew. > > cheers, Ian > From xernet at hotmail.it Wed Oct 8 07:41:46 2008 From: xernet at hotmail.it (xer xernet) Date: Wed Oct 8 07:41:53 2008 Subject: stable 7.0 and nslookup help command In-Reply-To: <20081008070435.GA69493@icarus.home.lan> References: <20081007224422.5388D4500F@ptavv.es.net> <20081008070435.GA69493@icarus.home.lan> Message-ID: Ok ok guys :-) I'm satisfied. > Date: Wed, 8 Oct 2008 00:04:35 -0700 > From: koitsu@FreeBSD.org > To: xernet@hotmail.it > CC: oberman@es.net; rwatson@freebsd.org; freebsd-stable@freebsd.org > Subject: Re: stable 7.0 and nslookup help command > > On Wed, Oct 08, 2008 at 08:36:29AM +0200, xer xernet wrote: > > > > Yes, thanx to all of you and your answers.. > > I'm just a dig user now, but.. > > The question now is: > > - if i want to implement /usr/share/misc/nslookup.help in nslookup (even if nslookup is evil) how can i do that? > > I need to know, i want learn this "fact" i will not use nslookup anymore, but i'm still curios HOW was implemented on older STABLE-5.5 > > I believe this would be a question for the BIND folks, not for FreeBSD. > I'm willing to bet they removed the feature in later versions of > nslookup. > > -- > | Jeremy Chadwick jdc at parodius.com | > | Parodius Networking http://www.parodius.com/ | > | UNIX Systems Administrator Mountain View, CA, USA | > | Making life hard for others since 1977. PGP: 4BD6C0CB | > _________________________________________________________________ Screensaver e sfondi? Scaricali dallo Spaces di Doretta! https://cid-97b0d995232b954a.skydrive.live.com/home.aspx From smithi at nimnet.asn.au Wed Oct 8 07:42:54 2008 From: smithi at nimnet.asn.au (Ian Smith) Date: Wed Oct 8 07:43:02 2008 Subject: zfs quota question In-Reply-To: <78fb9d960810080019j3b73e3ffidc189c716fb7a1de@mail.gmail.com> References: <200810071314.45922.max@love2party.net> <48EB5ADD.2090900@modulus.org> <78fb9d960810072118k47a64097yaa486ef5179efb1@mail.gmail.com> <20081008165835.C16723@sola.nimnet.asn.au> <78fb9d960810080019j3b73e3ffidc189c716fb7a1de@mail.gmail.com> Message-ID: <20081008183552.W16723@sola.nimnet.asn.au> On Wed, 8 Oct 2008, lhmwzy wrote: > OK.It's my mistake. > Improve it again: > > #!/bin/sh > find $1 -type f -ls | awk '{j += $7} END {printf("%.2fM\n",j/1024/1024)}' Sure. Here it runs about 7% faster precalculating one division: $ time find . -type f -ls | awk '{j += $7} END {printf("%.2fM\n",j/1048576)}' 2.69 real 0.64 user 1.21 sys 6586.34M > > $ du -d0 . > > 6781976 . > > > > Took 1.5 seconds, and comes to 69447434424, ie bytes allocated for those And my mistake, transcribing from the calculator: should be 6944743424. cheers, Ian From david at esn.org.za Wed Oct 8 08:46:41 2008 From: david at esn.org.za (David Peall) Date: Wed Oct 8 08:46:49 2008 Subject: Problem with dump stalling Message-ID: Hi If I have the wrong list please feel free to redirect me. I'm running 7.0-RELEASE-p4 and trying to backup to an external USB drive. I'm using the following command dump -a0Lf /backup/diskimages/root /dev/mfid0s1a Where df: Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/mfid0s1a 507630 208436 258584 45% / /dev/da1s1d 709513458 9853800 642898582 2% /backup The following processes start 75399 p0 I+ 0:00.04 dump -a0Lf /backup/diskimages/root /dev/mfid0s1a (dump) 75402 p0 S+ 0:00.71 dump: /dev/mfid0s1a: pass 4: 77.05% done, finished in 0:00 at Wed Oct 8 08:25:06 2008 (dump) 75403 p0 S+ 0:00.85 dump -a0Lf /backup/diskimages/root /dev/mfid0s1a (dump) 75404 p0 S+ 0:00.96 dump -a0Lf /backup/diskimages/root /dev/mfid0s1a (dump) 75405 p0 S+ 0:00.86 dump -a0Lf /backup/diskimages/root /dev/mfid0s1a (dump) But it just stops at a random percentage, the system continues to run and the processes are killable? Perhaps I'm using dump incorrectly if anyone could help would be greatly appreciated. Regards -- David Peall :: IT Manager e-Schools' Network :: http://www.esn.org.za/ Phone +27 (021) 674-9140 From koitsu at FreeBSD.org Wed Oct 8 08:54:14 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Wed Oct 8 08:54:21 2008 Subject: Problem with dump stalling In-Reply-To: References: Message-ID: <20081008085412.GA71654@icarus.home.lan> On Wed, Oct 08, 2008 at 10:29:00AM +0200, David Peall wrote: > Hi > > If I have the wrong list please feel free to redirect me. > > I'm running 7.0-RELEASE-p4 and trying to backup to an external USB > drive. > > I'm using the following command > > dump -a0Lf /backup/diskimages/root /dev/mfid0s1a > > Where df: > > Filesystem 1K-blocks Used Avail Capacity Mounted on > /dev/mfid0s1a 507630 208436 258584 45% / > /dev/da1s1d 709513458 9853800 642898582 2% /backup > > The following processes start > > 75399 p0 I+ 0:00.04 dump -a0Lf /backup/diskimages/root /dev/mfid0s1a (dump) > 75402 p0 S+ 0:00.71 dump: /dev/mfid0s1a: pass 4: 77.05% done, finished in 0:00 at Wed Oct 8 08:25:06 2008 (dump) > 75403 p0 S+ 0:00.85 dump -a0Lf /backup/diskimages/root /dev/mfid0s1a (dump) > 75404 p0 S+ 0:00.96 dump -a0Lf /backup/diskimages/root /dev/mfid0s1a (dump) > 75405 p0 S+ 0:00.86 dump -a0Lf /backup/diskimages/root /dev/mfid0s1a (dump) > > But it just stops at a random percentage, the system continues to run > and the processes are killable? > > Perhaps I'm using dump incorrectly if anyone could help would be greatly > appreciated. This is a known problem with dump on UFS2 filesystems. See "dump/restore" here: http://wiki.freebsd.org/JeremyChadwick/Commonly_reported_issues There is no fix, AFAIK. My recommendation is to use something else. I'm particularly fond of rsnapshot, but be aware that rsync will cause file atimes to be lost (on the source) when copying; this can impact classic UNIX mail spools (mbox), where people use clients like mutt/pine which utilise atimes to determine if there's new mail or not. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From peterjeremy at optushome.com.au Wed Oct 8 09:09:30 2008 From: peterjeremy at optushome.com.au (Peter Jeremy) Date: Wed Oct 8 09:09:37 2008 Subject: Help me to develop a FreeBSD patch for gcc-4.2.1 In-Reply-To: <579024.2364.qm@web57007.mail.re3.yahoo.com> References: <20081006180353.GF18237@server.vk2pj.dyndns.org> <579024.2364.qm@web57007.mail.re3.yahoo.com> Message-ID: <20081008090922.GJ18237@server.vk2pj.dyndns.org> On 2008-Oct-07 02:06:03 -0700, Unga wrote: >Now I unpacked the gcc-4.2.1.tar.bz2 into some other directory and applied this FreeBSD-gcc.patch. Ran configure and compiled. It develop following error: >../../gcc-4.2.1/gcc/c-format.c:1780: error: 'flag_format_extensions' undeclared (first use in this function) >../../gcc-4.2.1/gcc/c-format.c:1780: error: (Each undeclared identifier is reported only once >../../gcc-4.2.1/gcc/c-format.c:1780: error: for each function it appears in.) >gmake[2]: *** [c-format.o] Error 1 Note that the FreeBSD gcc is not built using the gcc configure script. Instead, all the target-specific configuration is under /usr/src/gnu/usr.bin/cc -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20081008/84af859e/attachment.pgp From fernan at iib.unsam.edu.ar Wed Oct 8 10:15:42 2008 From: fernan at iib.unsam.edu.ar (Fernan Aguero) Date: Wed Oct 8 10:15:50 2008 Subject: [FreeBSD] Fix for ServerWorks HT1000 in upcoming 7.1? In-Reply-To: <48EBDE69.1030609@delphij.net> References: <520894aa0809301434h68b94628x54ec08fd48785feb@mail.gmail.com> <200810011134.49795.jhb@freebsd.org> <48EBDE69.1030609@delphij.net> Message-ID: <20081008101515.GA59675@iib.unsam.edu.ar> > Did anyone who can trigger the data corruption has tried John's patch > and let us know if it worked? Not yet. My problem is that it's not that easy ... (at least for me, but maybe I'm missing something). The main issue for me is that I don't have a spare box running 7.x. All my FreeBSD boxes are running 6.x I've tried to make a new 7.1-BETA bootable ISO from the patched sources (make release), but failed ... this is the first time I've ever attempted this, and it seems that you cannot do that from a 6.x box (I have a full CVS mirror of FreeBSD, and a fresh checkout of RELENG_7). The next thing to do (which I already tried once, and that was also not an painless path) is to boot the box with FreeBSD-6.1 (amd64, no data corruption here) and upgrade to 7.x patching the sources along the way. I need to find a free afternoon in my agenda to fit this ... I will get back with info as soon as I have done it. Fernan From lhmwzy at gmail.com Wed Oct 8 14:58:42 2008 From: lhmwzy at gmail.com (lhmwzy) Date: Wed Oct 8 14:58:48 2008 Subject: What's the Scheduler SCHED_core development now? Message-ID: <78fb9d960810080758p627e0d08x99f18fa618023812@mail.gmail.com> Is it still alive? Is it replaced by SCHED_ULE? From bms at incunabulum.net Wed Oct 8 16:55:46 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Wed Oct 8 16:55:53 2008 Subject: 7.0-RELEASE panics when loading USB modules x2 Message-ID: <48ECE60F.3060804@incunabulum.net> Hi, I just had 7.0-RELEASE crash again, whilst kldloading the uplcom.ko module in multi-user mode with X running, and no USB serial devices plugged in. The T43 immediately resets, I don't get a chance to drop into a debugger. This seems like a pretty serious USB regression. Is anyone looking into it? Are these things a thing of the past with the "new" USB code? thanks BMS From oberman at es.net Wed Oct 8 17:01:42 2008 From: oberman at es.net (Kevin Oberman) Date: Wed Oct 8 17:01:49 2008 Subject: Problem with dump stalling In-Reply-To: Your message of "Wed, 08 Oct 2008 01:54:12 PDT." <20081008085412.GA71654@icarus.home.lan> Message-ID: <20081008170141.34C264500F@ptavv.es.net> > Date: Wed, 8 Oct 2008 01:54:12 -0700 > From: Jeremy Chadwick > Sender: owner-freebsd-stable@freebsd.org > > On Wed, Oct 08, 2008 at 10:29:00AM +0200, David Peall wrote: > > Hi > > > > If I have the wrong list please feel free to redirect me. > > > > I'm running 7.0-RELEASE-p4 and trying to backup to an external USB > > drive. > > > > I'm using the following command > > > > dump -a0Lf /backup/diskimages/root /dev/mfid0s1a > > > > Where df: > > > > Filesystem 1K-blocks Used Avail Capacity Mounted on > > /dev/mfid0s1a 507630 208436 258584 45% / > > /dev/da1s1d 709513458 9853800 642898582 2% /backup > > > > The following processes start > > > > 75399 p0 I+ 0:00.04 dump -a0Lf /backup/diskimages/root /dev/mfid0s1a (dump) > > 75402 p0 S+ 0:00.71 dump: /dev/mfid0s1a: pass 4: 77.05% done, finished in 0:00 at Wed Oct 8 08:25:06 2008 (dump) > > 75403 p0 S+ 0:00.85 dump -a0Lf /backup/diskimages/root /dev/mfid0s1a (dump) > > 75404 p0 S+ 0:00.96 dump -a0Lf /backup/diskimages/root /dev/mfid0s1a (dump) > > 75405 p0 S+ 0:00.86 dump -a0Lf /backup/diskimages/root /dev/mfid0s1a (dump) > > > > But it just stops at a random percentage, the system continues to run > > and the processes are killable? > > > > Perhaps I'm using dump incorrectly if anyone could help would be greatly > > appreciated. > > This is a known problem with dump on UFS2 filesystems. See > "dump/restore" here: > > http://wiki.freebsd.org/JeremyChadwick/Commonly_reported_issues > > There is no fix, AFAIK. > > My recommendation is to use something else. I'm particularly fond of > rsnapshot, but be aware that rsync will cause file atimes to be lost > (on the source) when copying; this can impact classic UNIX mail > spools (mbox), where people use clients like mutt/pine which utilise > atimes to determine if there's new mail or not. I had a system that was showing these exact symptoms David described. It did this both with -L and without. I went for about 3 months without a successful dump. I did at least two full system re-installs to no avail. Then, about 3 weeks ago, when I was about to start some serious debugging, it started working again. Nothing was touched between the last failure and the first success. I'm completely baffled! -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 224 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20081008/c68bd5e3/attachment.pgp From bf2006a at yahoo.com Wed Oct 8 17:46:28 2008 From: bf2006a at yahoo.com (bf) Date: Wed Oct 8 17:47:01 2008 Subject: Recent Problems with RELENG_7 i386 Message-ID: <104852.27020.qm@web39102.mail.mud.yahoo.com> After updating to RELENG_7 i386 of this weekend, I have been having problems with my machine. When booting normally, the system slows or hangs at the login prompt. If I am able to continue past the prompt, I sometimes experience erratic mouse behavior, and a subsequent hang, after varying lengths of time, even under light workloads. The same problem does not seem to occur in single-user mode, and did not occur with the RELENG_7 i386 of just over a week ago. I have been unable to obtain crashdumps so far, and the only log messages I can find that weren't present before are notices like those recorded below: Oct 8 11:00:40 myhost kernel: t_delta 15.fd80bdcb75b60200 too short Oct 8 11:11:36 myhost kernel: t_delta 15.fd80c27b52e73380 too short Oct 8 06:00:38 myhost kernel: t_delta 15.fd809cfc695da780 too short Oct 8 06:11:18 myhost kernel: t_delta 15.fd80bdcb75b60200 too short Oct 8 06:22:14 myhost kernel: t_delta 15.fd80b91b9884d080 too short Oct 8 02:31:34 myhost kernel: t_delta 15.fd80bdcb75b60200 too short Oct 8 02:56:46 myhost kernel: t_delta 15.fd80bdcb75b60200 too short Oct 8 02:59:54 myhost kernel: t_delta 15.fd80c27b52e73380 too short Oct 8 03:08:42 myhost kernel: t_delta 15.fd80e34a5f3f8e00 too short Oct 8 03:19:38 myhost kernel: t_delta 15.fd80c27b52e73380 too short Oct 8 03:30:34 myhost kernel: t_delta 15.fd80bdcb75b60200 too short Oct 8 03:41:14 myhost kernel: t_delta 15.fd8116d8e05cae80 too short Oct 8 03:52:10 myhost kernel: t_delta 15.fd80b46bbb539f00 too short Oct 8 04:03:06 myhost kernel: t_delta 15.fd8104196b97e880 too short Oct 8 04:13:46 myhost kernel: t_delta 15.fd80d9eaa4dd2b00 too short Oct 8 04:24:42 myhost kernel: t_delta 15.fd80600e2dde2400 too short Oct 8 04:35:38 myhost kernel: t_delta 15.fd80b91b9884d080 too short Oct 8 04:46:18 myhost kernel: t_delta 15.fd80d9eaa4dd2b00 too short Oct 8 04:57:14 myhost kernel: t_delta 15.fd80c72b30186500 too short Oct 8 05:08:10 myhost kernel: t_delta 15.fd80c27b52e73380 too short Oct 8 05:18:50 myhost kernel: t_delta 15.fd8116d8e05cae80 too short Oct 8 05:29:46 myhost kernel: t_delta 15.fd80c72b30186500 too short Oct 8 05:40:26 myhost kernel: t_delta 15.fd8120389abf1180 too short Oct 8 05:51:22 myhost kernel: t_delta 15.fd80cbdb0d499680 too short Oct 8 06:02:18 myhost kernel: t_delta 15.fd810d7925fa4b80 too short Oct 8 06:12:58 myhost kernel: t_delta 15.fd80c72b30186500 too short Oct 8 06:23:54 myhost kernel: t_delta 15.fd8161d6b36fc680 too short Oct 8 06:34:50 myhost kernel: t_delta 15.fd8019c037fc3d80 too short Oct 8 06:45:30 myhost kernel: t_delta 15.fd80afbbde226d80 too short Oct 8 06:56:26 myhost kernel: t_delta 15.fd80bdcb75b60200 too short Oct 8 07:07:22 myhost kernel: t_delta 15.fd80ab0c00f13c00 too short Oct 8 07:18:02 myhost kernel: t_delta 15.fd808eecd1ca1300 too short Oct 8 07:28:58 myhost kernel: t_delta 15.fd804d4eb9195e00 too short Oct 8 07:39:54 myhost kernel: t_delta 15.fd80f159f6d32280 too short Oct 8 07:50:34 myhost kernel: t_delta 15.fd80bdcb75b60200 too short Oct 8 08:01:30 myhost kernel: t_delta 15.fd80cbdb0d499680 too short Oct 8 08:12:26 myhost kernel: t_delta 15.fd80b91b9884d080 too short Oct 8 08:23:06 myhost kernel: t_delta 15.fd80c72b30186500 too short Oct 8 08:34:02 myhost kernel: t_delta 15.fd80bdcb75b60200 too short Oct 8 08:44:58 myhost kernel: t_delta 15.fd80b46bbb539f00 too short Oct 8 08:55:38 myhost kernel: t_delta 15.fd80c27b52e73380 too short Oct 8 09:06:34 myhost kernel: t_delta 15.fd80c72b30186500 too short Oct 8 09:17:30 myhost kernel: t_delta 15.fd80c27b52e73380 too short Oct 8 09:28:10 myhost kernel: t_delta 15.fd8187559cf95280 too short Oct 8 09:39:06 myhost kernel: t_delta 15.fd80d08aea7ac800 too short Oct 8 09:49:46 myhost kernel: t_delta 15.fd80c72b30186500 too short Oct 7 08:37:07 myhost kernel: t_delta 15.fd80bdcb75b60200 too short I'm not sure if these problems are due to a hardware failure (my memory doesn't show any problems with memtest, and smartmontools doesn't reveal any disk problems), or with recent changes to RELENG-7. Can anyone advise me on how to diagnose the problem? Below are my kernel configuration, my loader configuration, and a verbose boot listing. Thanks, b. cpu I686_CPU ident NEWKERNEL7B makeoptions DEBUG=-g options KDB options KDB_TRACE options KTRACE options STACK options DDB options DDB_NUMSYM options VERBOSE_SYSINIT options INCLUDE_CONFIG_FILE options SCHED_ULE options PREEMPTION options INET device crypto device cryptodev options IPSEC options IPSEC_FILTERTUNNEL options IPSTEALTH options TCP_SIGNATURE options ZERO_COPY_SOCKETS options DIRECTIO options FFS options SOFTUPDATES options UFS_ACL options UFS_DIRHASH options UFS_GJOURNAL options COMPAT_43TTY options COMPAT_FREEBSD4 options COMPAT_FREEBSD5 options COMPAT_FREEBSD6 options SCSI_DELAY=5000 options SYSVSHM options SYSVMSG options SYSVSEM options _KPOSIX_PRIORITY_SCHEDULING options KBD_INSTALL_CDEV options ADAPTIVE_GIANT options AUDIT device apic options STOP_NMI options HZ=1000 options DEVICE_POLLING options SW_WATCHDOG device cpufreq options HWPMC_HOOKS device eisa device pci device ata device atadisk options ATA_STATIC_ID device atkbdc device atkbd device psm device kbdmux device vga options VGA_WIDTH90 device splash device green_saver options FB_INSTALL_CDEV device sc device agp device pmtimer device loop device random device ether device tun device pty device bpf options BPF_JITTER verbose_loading="YES" screensave_name="green_saver" acpi_dsdt_load="YES" acpi_dsdt_type="acpi_dsdt" acpi_dsdt_name="/boot/acpi_dsdt.aml" hw.acpi.osname="Microsoft Windows" hw.acpi.suspend_state=S1 zpool_cache_load="NO" debug.cpufreq.verbose=1 tmpfs_load="YES" kern.hz=100 net.inet.udp.soreceive_dgram_enabled=1 Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.1-PRERELEASE #0: Wed Oct 8 09:35:58 EDT 2008 toor@myhost:/usr/obj/usr/src/sys/NEWKERNEL7 subsystem 900000 mtx_pool_setup_static(0)... done. subsystem 1000000 vm_mem_init(0)... done. subsystem 1800000 kmeminit(0)... done. malloc_init(0xc06c5440)... done. malloc_init(0xc06c53e0)... done. malloc_init(0xc06c5380)... done. malloc_init(0xc06c5320)... done. malloc_init(0xc06c52c0)... done. malloc_init(0xc06c57c0)... done. malloc_init(0xc06bcf20)... done. malloc_init(0xc06c7040)... done. malloc_init(0xc06bf3a0)... done. malloc_init(0xc06c70c0)... done. malloc_init(0xc06bfba0)... done. malloc_init(0xc06c77e0)... done. malloc_init(0xc06c7840)... done. malloc_init(0xc06c7780)... done. malloc_init(0xc06c7720)... done. malloc_init(0xc06c7fc0)... done. malloc_init(0xc06c8180)... done. malloc_init(0xc06c81e0)... done. malloc_init(0xc06b9420)... done. malloc_init(0xc06c8bc0)... done. malloc_init(0xc06c8c20)... done. malloc_init(0xc06c8c80)... done. malloc_init(0xc06c98c0)... done. malloc_init(0xc06c9b80)... done. malloc_init(0xc06ca4e0)... done. malloc_init(0xc06baf80)... done. malloc_init(0xc06ca580)... done. malloc_init(0xc06ca5e0)... done. malloc_init(0xc06ca9a0)... done. malloc_init(0xc06cac20)... done. malloc_init(0xc06cae80)... done. malloc_init(0xc06bb0c0)... done. malloc_init(0xc06bb360)... done. malloc_init(0xc06cb1e0)... done. malloc_init(0xc06b8980)... done. malloc_init(0xc06cb300)... done. malloc_init(0xc06bb760)... done. malloc_init(0xc06c3b20)... done. malloc_init(0xc06cb520)... done. malloc_init(0xc06cb5a0)... done. malloc_init(0xc06cb680)... done. malloc_init(0xc06cb720)... done. malloc_init(0xc06cb780)... done. malloc_init(0xc06cb7e0)... done. malloc_init(0xc06cbb20)... done. malloc_init(0xc06cc080)... done. malloc_init(0xc06cc620)... done. malloc_init(0xc06ccb60)... done. malloc_init(0xc06cd160)... done. malloc_init(0xc06cd3a0)... done. malloc_init(0xc06cd680)... done. malloc_init(0xc06be1c0)... done. malloc_init(0xc06cd840)... done. malloc_init(0xc06cd7e0)... done. malloc_init(0xc06ce080)... done. malloc_init(0xc06ce7c0)... done. malloc_init(0xc06cf040)... done. malloc_init(0xc06cf220)... done. malloc_init(0xc06cf2a0)... done. malloc_init(0xc06cf320)... done. malloc_init(0xc06cf440)... done. malloc_init(0xc06cf3e0)... done. malloc_init(0xc06be7a0)... done. malloc_init(0xc06cfba0)... done. malloc_init(0xc06d0160)... done. malloc_init(0xc06d03c0)... done. malloc_init(0xc06d05a0)... done. malloc_init(0xc06d0540)... done. malloc_init(0xc06d04e0)... done. malloc_init(0xc06d07e0)... done. malloc_init(0xc06d0860)... done. malloc_init(0xc06d0a00)... done. malloc_init(0xc06c3de0)... done. malloc_init(0xc06d0be0)... done. malloc_init(0xc06c3e40)... done. malloc_init(0xc06c3ea0)... done. malloc_init(0xc06c4140)... done. malloc_init(0xc06d1280)... done. malloc_init(0xc06d1a20)... done. malloc_init(0xc06d1b60)... done. malloc_init(0xc06d1bc0)... done. malloc_init(0xc06d1c20)... done. malloc_init(0xc06d2940)... done. malloc_init(0xc06d3360)... done. malloc_init(0xc06c41e0)... done. malloc_init(0xc06d3e00)... done. malloc_init(0xc06d4360)... done. malloc_init(0xc06d4de0)... done. malloc_init(0xc06d53e0)... done. malloc_init(0xc06d5380)... done. malloc_init(0xc06d5320)... done. malloc_init(0xc06d52c0)... done. malloc_init(0xc06d5260)... done. malloc_init(0xc06d5200)... done. malloc_init(0xc06d51a0)... done. malloc_init(0xc06d5d60)... done. malloc_init(0xc06d61a0)... done. malloc_init(0xc06d6460)... done. malloc_init(0xc06d66c0)... done. malloc_init(0xc06d6660)... done. malloc_init(0xc06d6600)... done. malloc_init(0xc06d67e0)... done. malloc_init(0xc06d6840)... done. malloc_init(0xc06d68c0)... done. malloc_init(0xc06d6940)... done. malloc_init(0xc06d69a0)... done. malloc_init(0xc06d6a00)... done. malloc_init(0xc06d6b60)... done. malloc_init(0xc06d70e0)... done. malloc_init(0xc06d7140)... done. malloc_init(0xc06d71a0)... done. malloc_init(0xc06d7200)... done. malloc_init(0xc06d7260)... done. malloc_init(0xc06d72c0)... done. malloc_init(0xc06d7320)... done. malloc_init(0xc06d7380)... done. malloc_init(0xc06d73e0)... done. malloc_init(0xc06d7440)... done. malloc_init(0xc06d74a0)... done. malloc_init(0xc06d7500)... done. malloc_init(0xc06d7560)... done. malloc_init(0xc06d75c0)... done. malloc_init(0xc06d7620)... done. malloc_init(0xc06d8520)... done. malloc_init(0xc06d8720)... done. malloc_init(0xc06d87e0)... done. malloc_init(0xc06d8ca0)... done. malloc_init(0xc06c4400)... done. malloc_init(0xc06c4580)... done. malloc_init(0xc06be800)... done. malloc_init(0xc06da4c0)... done. malloc_init(0xc06c46c0)... done. malloc_init(0xc06dc000)... done. malloc_init(0xc06c4820)... done. malloc_init(0xc06be860)... done. malloc_init(0xc06beaa0)... done. malloc_init(0xc06c4b60)... done. malloc_init(0xc06beb40)... done. malloc_init(0xc06df480)... done. malloc_init(0xc06df680)... done. malloc_init(0xc06c4cc0)... done. malloc_init(0xc06dfba0)... done. malloc_init(0xc06dfc40)... done. malloc_init(0xc06e0000)... done. malloc_init(0xc06e0080)... done. malloc_init(0xc06c5240)... done. malloc_init(0xc06c5760)... done. malloc_init(0xc06e5e80)... done. malloc_init(0xc06bec60)... done. init_dynamic_kenv(0)... done. vid_malloc_init(0)... done. sysctl_register_all(0)... done. scmeminit(0)... done. subsystem 1a00000 vmmapentry_rsrc_init(0)... done. subsystem 1ac0000 mtx_pool_setup_dynamic(0)... done. subsystem 1b00000 selectinit(0)... done. filelistinit(0)... done. lf_init(0)... done. mtx_sysinit(0xc06bef20)... done. mtx_sysinit(0xc06c43cc)... done. mtx_sysinit(0xc06c43d8)... done. mtx_sysinit(0xc06cce0c)... done. mtx_sysinit(0xc06c702c)... done. mtx_sysinit(0xc06cd2f4)... done. mtx_sysinit(0xc06c43e4)... done. sx_sysinit(0xc06bef2c)... done. mtx_sysinit(0xc06cd4ac)... done. mtx_sysinit(0xc06cd564)... done. mtx_sysinit(0xc06bef34)... done. sx_sysinit(0xc06beb2c)... done. mtx_sysinit(0xc06da48c)... done. mtx_sysinit(0xc06cdb0c)... done. mtx_sysinit(0xc06d1014)... done. mtx_sysinit(0xc06d1184)... done. mtx_sysinit(0xc06cdb18)... done. mtx_sysinit(0xc06c978c)... done. mtx_sysinit(0xc06d1434)... done. sx_sysinit(0xc06c722c)... done. mtx_sysinit(0xc06c99cc)... done. mtx_sysinit(0xc06d7bf8)... done. mtx_sysinit(0xc06d1ce4)... done. mtx_sysinit(0xc06bf088)... done. mtx_sysinit(0xc06cf00c)... done. sx_sysinit(0xc06dfc24)... done. mtx_sysinit(0xc06cb704)... done. mtx_sysinit(0xc06d29c4)... done. mtx_sysinit(0xc06ca4b8)... done. sx_sysinit(0xc06b8b8c)... done. mtx_sysinit(0xc06b918c)... done. mtx_sysinit(0xc06cf54c)... done. mtx_sysinit(0xc06c4b34)... done. sx_sysinit(0xc06c3a4c)... done. init_bounce_pages(0)... done. arc4_init(0)... done. kobj_init_mutex(0)... done. init_turnstile0(0)... done. subsystem 1c00000 eventhandler_init(0)... done. subsystem 1c00001 umtxq_sysinit(0)... done. subsystem 2000000 linker_init(0)... done. module_init(0)... done. link_elf_init(0)... done. linker_preload(0)... Preloaded elf kernel "/boot/kernel/kernel" at 0xc0812000. Preloaded acpi_dsdt "/boot/acpi_dsdt.aml" at 0xc0812160. Preloaded elf module "/boot/kernel/tmpfs.ko" at 0xc08121a8. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc0812254. done. subsystem 1800000 malloc_init(0xc07fa980)... done. malloc_init(0xc07f9d20)... done. malloc_init(0xc07fad00)... done. malloc_init(0xc07fad80)... done. malloc_init(0xc07f9fa0)... done. malloc_init(0xc07fa2a0)... done. malloc_init(0xc07fae20)... done. malloc_init(0xc07f9360)... done. malloc_init(0xc07faf40)... done. malloc_init(0xc07a3bc0)... done. malloc_init(0xc07a3c20)... done. malloc_init(0xc07fb280)... done. acpi_alloc_wakeup_handler(0)... done. subsystem 1b00000 sx_sysinit(0xc07fa074)... done. sx_sysinit(0xc07fab34)... done. mtx_sysinit(0xc07fa140)... done. sx_sysinit(0xc07fa210)... done. sx_sysinit(0xc07fa298)... done. sx_sysinit(0xc07fa374)... done. sx_sysinit(0xc07f9a18)... done. sx_sysinit(0xc07fa478)... done. sx_sysinit(0xc07f9db4)... done. sx_sysinit(0xc07f9a54)... done. sx_sysinit(0xc07f95f4)... done. sx_sysinit(0xc07fa6dc)... done. sx_sysinit(0xc07fa7f4)... done. sx_sysinit(0xc07fa8f0)... done. subsystem 2000000 linker_init_kernel_modules(0)... done. linker_stop_class_add(0)... done. acpi_pm_register(0)... done. subsystem 20fffff mptable_register(0)... done. madt_register(0)... done. subsystem 2100000 cpu_startup(0)... Calibrating clock(s) ... i8254 clock: 1193173 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 906348380 Hz CPU: AMD Athlon(tm) Processor (906.35-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x642 Stepping = 2 Features=0x183f9ff AMD Features=0xc0440800,MMX+,3DNow!+,3DNow!> Data TLB: 24 entries, fully associative Instruction TLB: 16 entries, fully associative L1 data cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L2 internal cache: 256 kbytes, 64 bytes/line, 1 lines/tag, 8-way associative real memory = 536805376 (511 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000000c25000 - 0x000000001f6abfff, 514355200 bytes (125575 pages) avail memory = 515796992 (491 MB) done. apic_init(0)... done. bios32_init(0)... bios32: Found BIOS32 Service Directory header at 0xc00f8140 bios32: Entry = 0xfd6e0 (c00fd6e0) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xfd6e0+0x12c pnpbios: Found PnP BIOS data at 0xc00f8190 pnpbios: Entry = f0000:ac15 Rev = 1.0 Other BIOS signatures found: done. madt_set_ids(0)... done. subsystem 2200000 proc0_init(0)... done. init_prison(0)... done. init_taskqueue_list(0)... done. shutdown_conf(0)... done. subsystem 2300000 vm_init_limits(0xc06fbea0)... done. uma_startup3(0)... done. subsystem 2380000 db_capture_sysinit(0)... done. subsystem 2400000 sched_setup(0)... ULE: setup cpu 0 done. subsystem 2480000 ktrace_init(0)... done. subsystem 24c0000 audit_init(0)... done. subsystem 2500000 create_init(0)... done. subsystem 2600000 idle_setup(0)... done. subsystem 2700000 mbuf_init(0)... done. sf_buf_init(0)... done. subsystem 2800000 intr_init(0)... done. apic_setup_io(0)... done. atpic_init(0)... done. subsystem 2800001 start_netisr(0)... done. start_softintr(0)... done. subsystem 2900000 aclinit(0)... done. subsystem 2f00000 devfs_devs_init(0)... done. devdtr_init(0)... done. subsystem 3000000 if_init(0)... done. module_register_init(0xc06d0970)... done. subsystem 3100000 module_register_init(0xc06bf938)... done. module_register_init(0xc06bfa70)... done. module_register_init(0xc06bf36c)... done. k6_mem_drvinit(0)... done. module_register_init(0xc06d8c4c)... done. module_register_init(0xc06ca8c8)... done. module_register_init(0xc06bf0d0)... done. module_register_init(0xc06bf2a4)... done. module_register_init(0xc06bf7c0)... done. module_register_init(0xc06d1790)... done. module_register_init(0xc06bf7cc)... done. i686_mem_drvinit(0)... done. tcpsignature_attach(0)... done. ata_init(0)... done. module_register_init(0xc06bb1ac)... done. module_register_init(0xc06bdbd0)... done. module_register_init(0xc06bde28)... done. module_register_init(0xc06bdf80)... done. module_register_init(0xc06dff80)... done. module_register_init(0xc06dff8c)... done. bpf_drvinit(0)... done. module_register_init(0xc06e015c)... done. module_register_init(0xc06e0168)... done. module_register_init(0xc06e0174)... done. module_register_init(0xc06be138)... random: done. module_register_init(0xc06bcf0c)... kbd: new array size 4 kbd1 at kbdmux0 done. module_register_init(0xc06e5510)... done. module_register_init(0xc06e551c)... done. module_register_init(0xc06bb330)... done. module_register_init(0xc06e56ac)... done. module_register_init(0xc06e56b8)... done. module_register_init(0xc06e5778)... done. module_register_init(0xc06e57f0)... done. module_register_init(0xc06e57fc)... done. module_register_init(0xc06e594c)... done. module_register_init(0xc06e5958)... done. module_register_init(0xc06e5964)... done. module_register_init(0xc06e5a80)... done. module_register_init(0xc06e5ddc)... done. module_register_init(0xc06e5de8)... done. module_register_init(0xc06e5df4)... done. module_register_init(0xc06bfd5c)... done. module_register_init(0xc06e5f5c)... done. module_register_init(0xc06bfd68)... done. sm_attach_mouse(0)... done. module_register_init(0xc06e601c)... done. cn_drvinit(0)... done. module_register_init(0xc06e6124)... done. module_register_init(0xc06e61f8)... done. module_register_init(0xc06e6338)... done. module_register_init(0xc06e6478)... done. module_register_init(0xc06e65b8)... done. module_register_init(0xc06e6754)... done. module_register_init(0xc06e6898)... done. module_register_init(0xc06e69d8)... done. module_register_init(0xc06e6b18)... done. module_register_init(0xc06e6c70)... done. module_register_init(0xc06d60b0)... crypto: done. ptc_drvinit(0)... done. module_register_init(0xc06bfdc4)... done. module_register_init(0xc06bfe50)... done. ctty_drvinit(0)... done. module_register_init(0xc06bffc8)... done. module_register_init(0xc06be684)... done. module_register_init(0xc07f9600)... done. led_drvinit(0)... done. module_register_init(0xc07f9790)... done. module_register_init(0xc07f9868)... done. module_register_init(0xc07f9a0c)... done. module_register_init(0xc06dbe20)... done. module_register_init(0xc06dbef0)... done. module_register_init(0xc06dbefc)... done. module_register_init(0xc07f9bb4)... done. module_register_init(0xc07f9cfc)... done. module_register_init(0xc06bb34c)... done. module_register_init(0xc06dc4cc)... done. module_register_init(0xc06dc4d8)... done. module_register_init(0xc07f9e38)... done. module_register_init(0xc07f9f48)... done. module_register_init(0xc07fa068)... done. module_register_init(0xc06dc4e4)... done. module_register_init(0xc06bd0b8)... mem: Pentium Pro MTRR support enabled done. audit_pipe_init(0)... done. module_register_init(0xc07fa158)... done. module_register_init(0xc06bd278)... null: done. module_register_init(0xc07fa224)... done. module_register_init(0xc06dc798)... io: done. module_register_init(0xc07fa368)... done. module_register_init(0xc06dc9a0)... done. module_register_init(0xc06dca6c)... done. module_register_init(0xc07fa46c)... done. module_register_init(0xc06de95c)... done. module_register_init(0xc07fa6b8)... done. module_register_init(0xc06dea20)... done. module_register_init(0xc06dec60)... done. module_register_init(0xc06ded60)... done. module_register_init(0xc06dee48)... done. module_register_init(0xc07fa7e8)... done. log_drvinit(0)... done. module_register_init(0xc07fa8e4)... done. module_register_init(0xc06bd3a0)... done. audit_trigger_cdev_init(0)... done. module_register_init(0xc07faa24)... done. module_register_init(0xc07fab28)... done. module_register_init(0xc06bd468)... done. module_register_init(0xc07fabe0)... done. module_register_init(0xc06bd4e0)... done. module_register_init(0xc06bd600)... done. module_register_init(0xc06df60c)... done. module_register_init(0xc06df618)... done. module_register_init(0xc06bd680)... done. module_register_init(0xc06bb034)... done. module_register_init(0xc06bb4a0)... done. module_register_init(0xc06df724)... done. module_register_init(0xc06df730)... done. module_register_init(0xc06bb5d4)... done. module_register_init(0xc06c3d1c)... done. fildesc_drvinit(0)... done. module_register_init(0xc06bb5e0)... done. module_register_init(0xc06bb5ec)... done. subsystem 3800000 configure_first(0)... done. taskqueue_define_thread(0)... done. taskqueue_define_acpi(0)... done. taskqueue_define_swi_giant(0)... done. taskqueue_define_swi(0)... done. taskqueue_define_kqueue(0)... done. module_register_init(0xc06b9690)... done. taskqueue_define_fast(0)... done. configure(0)... ACPI: RSDP @ 0x0xf8170/0x0014 (v 0 PTLTD ) ACPI: RSDT @ 0x0x1fffd352/0x002C (v 1 PTLTD RSDT 0x06040000 LTP 0x00000000) ACPI: FACP @ 0x0x1ffffb65/0x0074 (v 1 HP Pandora 0x06040000 PTL 0x00000001) ACPI: DSDT @ 0x0x1fffd37e/0x27E7 (v 1 HPHPD Pandora 0x06040000 MSFT 0x0100000B) ACPI: FACS @ 0x0x1fffffc0/0x0040 ACPI: BOOT @ 0x0x1ffffbd9/0x0027 (v 1 PTLTD $SBFTBL$ 0x06040000 LTP 0x00000001) npx0: INT 16 interface cryptosoft0: on motherboard crypto: assign cryptosoft0 driver id 0, flags 100663296 crypto: cryptosoft0 registers alg 1 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 2 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 3 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 4 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 5 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 16 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 6 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 7 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 18 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 19 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 20 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 8 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 15 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 9 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 10 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 13 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 14 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 11 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 21 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 17 flags 0 maxoplen 0 acpi0: on motherboard ACPI: Overriding _OS definition with "Microsoft Windows" ACPI: Table DSDT replaced by host OS ACPI: DSDT @ 0x0/0x25DB (v 1 HPHPD Pandora 0x06040000 INTL 0x20070320) acpi0: [MPSAFE] acpi0: [ITHREAD] pci_open(1): mode 1 addr port (0x0cf8) is 0x80002104 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=80] is there (id=7xxxxxxx) pcibios: BIOS version 2.10 AcpiOsDerivePciId: \\_SB_.PCI0.PIB_.REGS -> bus 0 dev 4 func 0 AcpiOsDerivePciId: \\_SB_.PCI0.SLT1.REGS -> bus 0 dev 13 func 0 AcpiOsDerivePciId: \\_SB_.PCI0.SLT2.REGS -> bus 0 dev 14 func 0 AcpiOsDerivePciId: \\_SB_.PCI0.SLT3.REGS -> bus 0 dev 15 func 0 AcpiOsDerivePciId: \\_SB_.PCI0.SLT4.REGS -> bus 0 dev 16 func 0 AcpiOsDerivePciId: \\_SB_.PCI0.SLT5.REGS -> bus 0 dev 17 func 0 acpi0: Power Button (fixed) acpi0: wakeup code va 0xccdd7000 pa 0x1000 AcpiOsDerivePciId: \\_SB_.PCI0.REGS -> bus 0 dev 0 func 0 ACPI Error (dsopcode-0671): Field [ALB2] at 120 exceeds Buffer [CRSA] size 104 (bits) [20070320] ACPI Error (psparse-0626): Method parse/execution failed [\\_SB_.PCI0.PIB_.SIO0.LPT_._CRS] (Node 0xc29fc960), AE_AML_BUFFER_LIMIT ACPI Error (uteval-0309): Method execution failed [\\_SB_.PCI0.PIB_.SIO0.LPT_._CRS] (Node 0xc29fc960), AE_AML_BUFFER_LIMIT can't fetch resources for \\_SB_.PCI0.PIB_.SIO0.LPT_ - AE_AML_BUFFER_LIMIT ACPI timer: 0/6 0/4 0/4 0/4 0/6 0/4 0/5 0/5 0/6 1/1 -> 1 Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x8008-0x800b on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 6 7 9 10 11 14 15 Validation 0 11 N 0 3 4 6 7 9 10 11 14 15 After Disable 0 255 N 0 3 4 6 7 9 10 11 14 15 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 3 4 6 7 9 10 11 14 15 Validation 0 10 N 0 3 4 6 7 9 10 11 14 15 After Disable 0 255 N 0 3 4 6 7 9 10 11 14 15 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 9 N 0 3 4 6 7 9 10 11 14 15 Validation 0 9 N 0 3 4 6 7 9 10 11 14 15 After Disable 0 255 N 0 3 4 6 7 9 10 11 14 15 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 6 7 9 10 11 14 15 Validation 0 255 N 0 3 4 6 7 9 10 11 14 15 After Disable 0 255 N 0 3 4 6 7 9 10 11 14 15 pcib0: port 0xcf8-0xcff on acpi0 ACPI: Found matching pin for 0.4.INTD at func 2: 9 ACPI: Found matching pin for 0.14.INTA at func 0: 10 ACPI: Found matching pin for 0.15.INTA at func 0: 9 pci0: on pcib0 pci0: domain=0, physical bus=0 found-> vendor=0x1022, dev=0x7006, revid=0x25 domain=0, bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x2210, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[10]: type Prefetchable Memory, range 32, base 0xf8000000, size 26, enabled map[14]: type Prefetchable Memory, range 32, base 0xf4012000, size 12, enabled map[18]: type I/O Port, range 32, base 0x1470, size 2, port disabled found-> vendor=0x1022, dev=0x7007, revid=0x01 domain=0, bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0220, cachelnsz=0 (dwords) lattimer=0x63 (2970 ns), mingnt=0x0c (3000 ns), maxlat=0x00 (0 ns) found-> vendor=0x1106, dev=0x0686, revid=0x22 domain=0, bus=0, slot=4, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x008f, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1106, dev=0x0571, revid=0x10 domain=0, bus=0, slot=4, func=1 class=01-01-8a, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 map[20]: type I/O Port, range 32, base 0x1460, size 4, enabled found-> vendor=0x1106, dev=0x3038, revid=0x10 domain=0, bus=0, slot=4, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0017, statreg=0x0210, cachelnsz=16 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=9 powerspec 2 supports D0 D3 current D0 map[20]: type I/O Port, range 32, base 0x1440, size 5, enabled pcib0: matched entry for 0.4.INTD (src \\_SB_.PCI0.PIB_.LNKD:0) pcib0: slot 4 INTD routed to irq 9 via \\_SB_.PCI0.PIB_.LNKD found-> vendor=0x1106, dev=0x3038, revid=0x10 domain=0, bus=0, slot=4, func=3 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0015, statreg=0x0210, cachelnsz=16 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=255 powerspec 2 supports D0 D3 current D0 map[20]: type I/O Port, range 32, base 0xfce0, size 5, enabled found-> vendor=0x1106, dev=0x3057, revid=0x30 domain=0, bus=0, slot=4, func=4 class=0c-05-00, hdrtype=0x00, mfdev=0 cmdreg=0x0000, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 found-> vendor=0x127a, dev=0x4310, revid=0x00 domain=0, bus=0, slot=14, func=0 class=04-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0003, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 1 supports D0 D1 D3 current D0 map[10]: type I/O Port, range 32, base 0x1400, size 6, enabled pcib0: matched entry for 0.14.INTA (src \\_SB_.PCI0.PIB_.LNKB:0) pcib0: slot 14 INTA routed to irq 10 via \\_SB_.PCI0.PIB_.LNKB found-> vendor=0x127a, dev=0x4311, revid=0x00 domain=0, bus=0, slot=14, func=1 class=07-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0003, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 1 supports D0 D2 D3 current D0 map[10]: type Memory, range 32, base 0xf4000000, size 16, enabled pcib0: matched entry for 0.14.INTA (src \\_SB_.PCI0.PIB_.LNKB:0) pcib0: slot 14 INTA routed to irq 10 via \\_SB_.PCI0.PIB_.LNKB found-> vendor=0x127a, dev=0x4312, revid=0x00 domain=0, bus=0, slot=14, func=2 class=09-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0003, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 1 supports D0 D2 D3 current D0 map[10]: type Memory, range 32, base 0xf4010000, size 12, enabled found-> vendor=0x1113, dev=0x1211, revid=0x10 domain=0, bus=0, slot=15, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0003, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x20 (8000 ns), maxlat=0x40 (16000 ns) intpin=a, irq=9 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type I/O Port, range 32, base 0x1000, size 8, enabled map[14]: type Memory, range 32, base 0xf4011000, size 8, enabled pcib0: matched entry for 0.15.INTA (src \\_SB_.PCI0.PIB_.LNKC:0) pcib0: slot 15 INTA routed to irq 9 via \\_SB_.PCI0.PIB_.LNKC agp0: on hostb0 hostb0: Reserved 0x4000000 bytes for rid 0x10 type 3 at 0xf8000000 hostb0: Reserved 0x1000 bytes for rid 0x14 type 3 at 0xf4012000 agp0: allocating GATT for aperture of size 64M agp0: gatt -> ag_pdir 0x1064000 agp0: allocating GATT for 16384 AGP page entries pcib1: at device 1.0 on pci0 pcib1: domain 0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0xf000-0xfff pcib1: memory decode 0xf5000000-0xf5ffffff pcib1: prefetched decode 0xfc000000-0xfdffffff ACPI: Found matching pin for 1.5.INTA at func 0: 11 pci1: on pcib1 pci1: domain=0, physical bus=1 found-> vendor=0x10de, dev=0x002c, revid=0x15 domain=0, bus=1, slot=5, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x02b0, cachelnsz=0 (dwords) lattimer=0x28 (1200 ns), mingnt=0x05 (1250 ns), maxlat=0x01 (250 ns) intpin=a, irq=11 powerspec 1 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xf5000000, size 24, enabled pcib1: requested memory range 0xf5000000-0xf5ffffff: good map[14]: type Prefetchable Memory, range 32, base 0xfc000000, size 25, enabled pcib1: requested memory range 0xfc000000-0xfdffffff: good pcib1: matched entry for 1.5.INTA (src \\_SB_.PCI0.PIB_.LNKA:0) pcib1: slot 5 INTA routed to irq 11 via \\_SB_.PCI0.PIB_.LNKA vgapci0: mem 0xf5000000-0xf5ffffff,0xfc000000-0xfdffffff irq 11 at device 5.0 on pci1 isab0: at device 4.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1460-0x146f at device 4.1 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0x1460 ata0: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=03 ostat0=50 ostat1=00 ata0: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata0: stat1=0x00 err=0x01 lsb=0x00 msb=0x00 ata0: reset tp2 stat0=50 stat1=00 devices=0x1 ata0: [MPSAFE] ata0: [ITHREAD] ata1: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 ata1: reset tp1 mask=03 ostat0=50 ostat1=00 ata1: stat0=0xd0 err=0x00 lsb=0x00 msb=0x00 ata1: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb ata1: stat1=0x00 err=0x00 lsb=0xff msb=0xff ata1: reset tp2 stat0=00 stat1=00 devices=0x4 ata1: [MPSAFE] ata1: [ITHREAD] pci0: at device 4.2 (no driver attached) pci0: at device 4.3 (no driver attached) pci0: at device 4.4 (no driver attached) pci0: at device 14.0 (no driver attached) pci0: at device 14.1 (no driver attached) pci0: at device 14.2 (no driver attached) pci0: at device 15.0 (no driver attached) acpi_button0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0047 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: unable to allocate IRQ psmcpnp0: irq 12 on acpi0 psm0: current command byte:0047 psm0: strange result for test aux port (250). psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model IntelliMouse, device ID 3-00, 3 buttons psm0: config:00000000, flags:00000008, packet size:4 psm0: syncmask:08, syncbits:00 cpu0: on acpi0 cpu0: switching to generic Cx mode ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it atkbdc: atkbdc0 already exists; skipping it sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it pnp_identify: Trying Read_Port at 203 pnp_identify: Trying Read_Port at 243 pnp_identify: Trying Read_Port at 283 pnp_identify: Trying Read_Port at 2c3 pnp_identify: Trying Read_Port at 303 pnp_identify: Trying Read_Port at 343 pnp_identify: Trying Read_Port at 383 pnp_identify: Trying Read_Port at 3c3 PNP Identify complete isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices pmtimer0 on isa0 orm0: at iomem 0xc0000-0xca7ff,0xd0000-0xd3fff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd1, terminal emulator: sc (syscons terminal) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 fb0 at vga0 adv0: not probed (disabled) aha0: not probed (disabled) aic0: not probed (disabled) bt0: not probed (disabled) cs0: not probed (disabled) ed0: not probed (disabled) fdc0 failed to probe at port 0x3f0 irq 6 drq 2 on isa0 fe0: not probed (disabled) ie0: not probed (disabled) le0: not probed (disabled) ppc0 failed to probe at irq 7 on isa0 sio0 failed to probe at port 0x3f8 irq 4 on isa0 sio1 failed to probe at port 0x2f8 irq 3 on isa0 sio2: not probed (disabled) sio3: not probed (disabled) sn0: not probed (disabled) vt0: not probed (disabled) isa_probe_children: probing PnP devices done. configure_final(0)... Device configuration finished. done. cpufreq_post_change_evh_init(0)... done. subsystem 4000000 vntblinit(0)... done. nchinit(0)... done. vfs_hashinit(0)... done. nameiinit(0)... done. module_register_init(0xc06bebc4)... done. module_register_init(0xc07a3d40)... done. module_register_init(0xc06d8000)... done. pipeinit(0)... done. vfs_event_init(0)... done. subsystem 4800000 initclocks(0)... Timecounter "TSC" frequency 906348380 Hz quality 800 done. inittimecounter(0)... Timecounters tick every 10.000 msec done. sched_initticks(0)... done. init_device_poll(0)... done. ntp_init(0)... done. subsystem 5800000 clist_init(0)... done. subsystem 6400000 module_register_init(0xc06cc950)... done. subsystem 6800000 module_register_init(0xc06cc450)... done. subsystem 6c00000 module_register_init(0xc06cbe20)... done. subsystem 6e00000 p31binit(0)... done. sigqueue_start(0)... done. itimer_start(0)... done. p31b_set_standard(0)... done. subsystem 7000000 module_register_init(0xc06be280)... splash: image decoder found: green_saver done. module_register_init(0xc06dc610)... done. module_register_init(0xc06d6008)... crypto: done. knote_init(0)... done. module_register_init(0xc06d0dcc)... done. subsystem 7400000 module_register_init(0xc06c03e8)... done. module_register_init(0xc06c03ac)... done. elf32_insert_brand_entry(0xc06df180)... done. elf32_insert_brand_entry(0xc06df1a0)... done. subsystem 8400000 if_check(0)... done. subsystem 8800000 ipsec_attach(0)... done. domaininit(0)... done. net_add_domain(0xc06d1400)... done. net_add_domain(0xc06d2520)... done. net_add_domain(0xc06d5900)... IPsec: Initialized Security Association Processing. done. net_add_domain(0xc06cdc80)... done. route_init(0)... done. rts_init(0)... done. esp_attach(0)... done. ipcomp_attach(0)... done. ipe4_attach(0)... done. ah_attach(0)... done. arp_init(0)... done. subsystem 8800001 domainfinalize(0)... done. if_attachdomain(0)... done. module_register_init(0xc06d0a84)... lo0: bpf attached done. subsystem 9000000 tcov_init(0)... done. subsystem a000000 synch_setup(0)... done. subsystem a800000 run_interrupt_driven_config_hooks(0)... ata0-master: pio=PIO4 wdma=WDMA2 udma=UDMA66 cable=80 wire ad0: setting PIO4 on 82C686A chip ad0: setting UDMA66 on 82C686A chip ad0: 43967MB at ata0-master UDMA66 ad0: 90045648 sectors [95286C/15H/63S] 16 sectors/interrupt 1 depth queue GEOM: new disk ad0 ata1-master: pio=PIO4 wdma=WDMA2 udma=UDMA33 cable=40 wire done. subsystem d000000 proc0_post(0)... done. subsystem d800000 module_register_init(0xc06cc45c)... done. module_register_init(0xc06cc468)... done. module_register_init(0xc06cc474)... done. module_register_init(0xc06cc480)... done. module_register_init(0xc06cbe44)... done. module_register_init(0xc06cbe50)... done. module_register_init(0xc06cc95c)... done. module_register_init(0xc06cc968)... done. module_register_init(0xc06cc974)... done. module_register_init(0xc06cc980)... done. module_register_init(0xc06cc98c)... done. module_register_init(0xc06cbe5c)... done. module_register_init(0xc06cbe2c)... done. module_register_init(0xc06cbe38)... done. subsystem e000000 kick_init(0)... done. subsystem e400000 kproc_start(0xc06da4a4)... done. subsystem e800000 kproc_start(0xc06da498)... done. kproc_start(0xc06c76ac)... done. pagezero_start(0)... done. subsystem ea00000 kproc_start(0xc06ce7ac)... done. subsystem ec00000 kproc_start(0xc06cfb7c)... done. kproc_start(0xc06cfb88)... done. kproc_start(0xc06d7bec)... done. subsystem ee00000 acpi_acad_ac_only(0)... done. subsystem f000000 cpuset_init(0)... done. subsystem fffffff scheduler(0)... Trying to mount root from ufs:/dev/ad0s1a start_init: trying /sbin/init Loading configuration files. /etc/rc: DEBUG: run_rc_command: doit: dumpon_start kernel dumps on /dev/ad0s1b /etc/rc: DEBUG: checkyesno: ddb_enable is set to YES. /etc/rc: DEBUG: run_rc_command: start_precmd: ddb_prestart Starting ddb. /etc/rc: DEBUG: run_rc_command: doit: /sbin/ddb /etc/ddb.conf /etc/rc: DEBUG: run_rc_command: doit: initrandom_start Entropy harvesting: /etc/rc: DEBUG: checkyesno: harvest_interrupt is set to YES. interrupts /etc/rc: DEBUG: checkyesno: harvest_ethernet is set to YES. ethernet /etc/rc: DEBUG: checkyesno: harvest_p_to_p is set to YES. point_to_point kickstart . /etc/rc: DEBUG: run_rc_command: start_precmd: [ -n "$(geli_make_list)" ] /etc/rc: DEBUG: run_rc_command: start_precmd: find_gbde_devices start /etc/rc: DEBUG: run_rc_command: doit: gbde_start /etc/rc: DEBUG: run_rc_command: doit: encswap_attach /etc/rc: DEBUG: run_rc_command: doit: ccd_start /etc/rc: DEBUG: run_rc_command: doit: swapon -a swapon: adding /dev/ad0s1b as swap device /etc/rc: DEBUG: run_rc_command: doit: fsck_start Starting file system checks: /etc/rc: DEBUG: checkyesno: background_fsck is set to YES. /dev/ad0s1a: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ad0s1a: clean, 21687 free (1695 frags, 2499 blocks, 2.3% fragmentation) /dev/ad0s1g: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ad0s1g: clean, 187317 free (1677 frags, 23205 blocks, 0.1% fragmentation) /dev/ad0s1f: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ad0s1f: clean, 1318966 free (441878 frags, 109636 blocks, 2.2% fragmentation) /dev/ad0s1d: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ad0s1d: clean, 18286 free (3886 frags, 1800 blocks, 5.2% fragmentation) /dev/ad0s1e: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ad0s1e: clean, 2799 free (231 frags, 321 blocks, 2.4% fragmentation) /etc/rc: DEBUG: run_rc_command: doit: root_start /etc/rc: DEBUG: checkyesno: hostid_enable is set to NO. /etc/rc: DEBUG: run_rc_command: start_precmd: [ -n "${_mdconfig_list}" ] /etc/rc: DEBUG: run_rc_command: doit: mountcritlocal_start Mounting local file systems: WARNING: TMPFS is considered to be a highly experimental feature in FreeBSD. . /etc/rc: DEBUG: checkyesno: zfs_enable is set to NO. /etc/rc: DEBUG: checkyesno: cleanvar_enable is set to YES. /etc/rc: DEBUG: run_rc_command: start_precmd: cleanvar_prestart /etc/rc: DEBUG: run_rc_command: doit: cleanvar_start /etc/rc: DEBUG: run_rc_command: doit: random_start /etc/rc: DEBUG: run_rc_command: doit: adjkerntz -i /etc/rc: DEBUG: checkyesno: atm_enable is set to NO. /etc/rc: DEBUG: run_rc_command: doit: hostname_start Setting hostname: myhost. /etc/rc: DEBUG: checkyesno: ipfilter_enable is set to NO. /etc/rc: DEBUG: checkyesno: ipnat_enable is set to NO. /etc/rc: DEBUG: checkyesno: ipfs_enable is set to NO. /etc/rc: DEBUG: checkyesno: kldxref_enable is set to NO. /etc/rc: DEBUG: run_rc_command: doit: sppp_start /etc/rc: DEBUG: run_rc_command: doit: addswap_start /etc/rc: DEBUG: run_rc_command: doit: auto_linklocal_start /etc/rc: DEBUG: checkyesno: ipv6_enable is set to NO. /etc/rc: DEBUG: run_rc_command: doit: sysctl_start security.bsd.see_other_uids: 1 -> 0 security.bsd.see_other_gids: 1 -> 0 security.bsd.hardlink_check_uid: 0 -> 1 security.bsd.hardlink_check_gid: 0 -> 1 security.bsd.unprivileged_proc_debug: 1 -> 0 security.bsd.unprivileged_read_msgbuf: 1 -> 0 net.inet.ip.stealth: 0 -> 1 net.inet.tcp.syncookies: 1 -> 0 net.inet.ip.check_interface: 0 -> 1 net.inet.tcp.sendspace: 32768 -> 65535 net.inet.tcp.recvspace: 65536 -> 65535 net.inet.udp.recvspace: 41600 -> 65535 net.inet.udp.maxdgram: 9216 -> 57344 net.local.stream.recvspace: 8192 -> 65535 net.local.stream.sendspace: 8192 -> 65535 net.inet.ip.redirect: 1 -> 0 net.inet.ip.random_id: 0 -> 1 kern.ipc.somaxconn: 128 -> 1024 kern.ipc.maxsockbuf: 262144 -> 2097152 kern.randompid: 0 -> 348 net.inet.tcp.blackhole: 0 -> 2 net.inet.udp.blackhole: 0 -> 1 kern.ipc.shmmax: 33554432 -> 67108864 kern.ipc.shmall: 8192 -> 32768 /etc/rc: DEBUG: run_rc_command: doit: network_start /etc/rc: DEBUG: Cloned: lo0: flags=8049 metric 0 mtu 16384 inet 127.0.0.1 netmask 0xff000000 /etc/rc: DEBUG: The following interfaces were not configured: /etc/rc.d/ipfilter: DEBUG: checkyesno: ipfilter_enable is set to NO. /etc/rc: DEBUG: checkyesno: ip6addrctl_enable is set to YES. /etc/rc: DEBUG: run_rc_command: doit: ip6addrctl_start /etc/rc: DEBUG: checkyesno: atm_enable is set to NO. /etc/rc: DEBUG: checkyesno: pfsync_enable is set to NO. /etc/rc: DEBUG: checkyesno: pflog_enable is set to NO. /etc/rc: DEBUG: checkyesno: pf_enable is set to NO. /etc/rc: DEBUG: checkyesno: isdn_enable is set to NO. /etc/rc: DEBUG: checkyesno: ppp_enable is set to NO. /etc/rc: DEBUG: run_rc_command: doit: routing_start route: writing to routing socket : Network is unreachable add net default: gateway 192.168.5.1: Network is unreachable Additional routing options: ignore ICMP redirect=YES log ICMP redirect=YES . /etc/rc: DEBUG: checkyesno: ipv6_firewall_enable is set to NO. /etc/rc: DEBUG: checkyesno: ipv6_enable is set to NO. /etc/rc: DEBUG: checkyesno: devd_enable is set to YES. Starting devd. /etc/rc: DEBUG: run_rc_command: doit: /sbin/devd /etc/pccard_ether: DEBUG: run_rc_command: start_precmd: checkauto /etc/pccard_ether: DEBUG: run_rc_command: doit: pccard_ether_start hw.acpi.cpu.cx_lowest: C1 -> C1 /etc/rc: DEBUG: checkyesno: devd_enable is set to YES. /etc/rc: DEBUG: checkyesno: ipsec_enable is set to NO. /etc/rc: DEBUG: checkyesno: firewall_enable is set to YES. /etc/rc: DEBUG: run_rc_command: start_precmd: ipfw_prestart /etc/rc: DEBUG: checkyesno: dummynet_enable is set to NO. ipfw2 initialized, divert loadable, nat loadable, rule-based forwarding disabled, default to deny, logging disabled /etc/rc: INFO: ipfw kernel module loaded. /etc/rc: DEBUG: run_rc_command: doit: ipfw_start /etc/rc.d/natd: DEBUG: checkyesno: natd_enable is set to NO. Flushed all rules. 00100 allow ip from any to any via lo0 00200 deny log ip from any to 127.0.0.0/8 00300 deny log ip from 127.0.0.0/8 to any 00400 deny log ip from 192.168.5.1 to any out via rl0 00500 deny log ip from 192.168.5.2 to any in via rl0 00800 deny log ip from any to any not antispoof in 00900 allow ip from 192.168.5.2 to 192.168.5.1 01000 allow ip from 192.168.5.1 to 192.168.5.2 01100 deny log ip from 10.0.0.0/8 to any 01200 deny log ip from 172.16.0.0/12 to any 01300 deny log ip from table(1) to any 01400 deny log ip from any to 10.0.0.0/8 01500 deny log ip from any to 172.16.0.0/12 01600 deny log ip from any to table(1) 01700 deny log ip from 0.0.0.0/8 to any 01800 deny log ip from 169.254.0.0/16 to any 01900 deny log ip from 192.0.2.0/24 to any 02000 deny log ip from 224.0.0.0/4 to any 02100 deny log ip from 240.0.0.0/4 to any 02200 deny log ip from any to 0.0.0.0/8 02300 deny log ip from any to 169.254.0.0/16 02400 deny log ip from any to 192.0.2.0/24 02500 deny log ip from any to 224.0.0.0/4 02600 deny log ip from any to 240.0.0.0/4 02699 deny log icmp from any to any in via rl0 icmptypes 5,8,9,10,13,15,17 02700 check-state 02800 deny log tcp from me to any established 02801 deny log tcp from any to me established 03200 allow tcp from me to any out setup keep-state 03300 deny log tcp from any to any setup 03301 allow icmp from me to any out via rl0 icmptypes 8 keep-state 03500 allow udp from me to any dst-port 123 keep-state 03600 deny log logamount 500 ip from any to any Firewall rules loaded. /etc/rc: DEBUG: checkyesno: firewall_logging is set to YES. Firewall logging enabled. net.inet.ip.fw.enable: 1 -> 1 /etc/rc: DEBUG: run_rc_command: doit: nsswitch_start /etc/rc: DEBUG: checkyesno: mroute6d_enable is set to NO. /etc/rc: DEBUG: checkyesno: ipv6_router_enable is set to NO. /etc/rc: DEBUG: checkyesno: mrouted_enable is set to NO. /etc/rc: DEBUG: checkyesno: router_enable is set to NO. Additional IP options: log_in_vain=1 tcp extensions=NO drop SYN+FIN packets=YES . /etc/rc: DEBUG: run_rc_command: start_precmd: mountcritremote_precmd /etc/rc: DEBUG: run_rc_command: doit: mountcritremote_start Mounting NFS file systems: . /etc/rc.d/cleanvar: DEBUG: checkyesno: cleanvar_enable is set to YES. /etc/rc.d/cleanvar: DEBUG: run_rc_command: doit: cleanvar_start /etc/rc: DEBUG: run_rc_command: doit: ldconfig_start /etc/rc: DEBUG: checkyesno: ldconfig_insecure is set to NO. ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib /usr/local/lib/compat /usr/local/lib/expect5.44.1.7 /usr/local/lib/gcc-4.2.5 /usr/local/lib/graphviz /usr/local/lib/nss /usr/local/lib/qt4 a.out ldconfig path: /usr/lib/aout /usr/lib/compat/aout /etc/rc: DEBUG: run_rc_command: doit: cleartmp_start /etc/rc: DEBUG: checkyesno: clear_tmp_enable is set to YES. Clearing /tmp. /etc/rc: DEBUG: checkyesno: clear_tmp_X is set to YES. /etc/rc: DEBUG: checkyesno: xfs_enable is set to NO. /etc/rc: DEBUG: run_rc_command: doit: devfs_start /etc/rc: DEBUG: checkyesno: ipmon_enable is set to NO. /etc/rc: DEBUG: run_rc_command: start_precmd: [ -n "${_mdconfig2_list}" ] /etc/rc: DEBUG: checkyesno: newsyslog_enable is set to YES. /etc/rc: DEBUG: run_rc_command: doit: newsyslog_start Creating and/or trimming log files: . /etc/rc: DEBUG: checkyesno: syslogd_enable is set to YES. /etc/rc: DEBUG: pid file (/var/run/syslog.pid): not readable. /etc/rc: DEBUG: run_rc_command: start_precmd: syslogd_precmd /etc/rc: DEBUG: checkyesno: named_enable is set to NO. Starting syslogd. /etc/rc: DEBUG: run_rc_command: doit: /usr/sbin/syslogd -ss /etc/rc: DEBUG: run_rc_command: start_precmd: savecore_prestart /etc/rc: DEBUG: run_rc_command: doit: savecore_start Checking for core dump on /dev/ad0s1b... savecore: no dumps found /etc/rc: DEBUG: run_rc_command: doit: archdep_start Initial i386 initialization: /etc/rc: DEBUG: checkyesno: ibcs2_enable is set to NO. . /etc/rc: DEBUG: run_rc_command: doit: abi_start Additional ABI support: /etc/rc: DEBUG: checkyesno: sysvipc_enable is set to NO. /etc/rc: DEBUG: checkyesno: linux_enable is set to NO. /etc/rc: DEBUG: checkyesno: svr4_enable is set to NO. . /etc/rc: DEBUG: checkyesno: tor_enable is set to NO. /etc/rc: DEBUG: checkyesno: accounting_enable is set to NO. /etc/rc: DEBUG: checkyesno: named_enable is set to NO. /etc/rc: DEBUG: checkyesno: ntpdate_enable is set to NO. /etc/rc: DEBUG: checkyesno: rpcbind_enable is set to NO. /etc/rc: DEBUG: checkyesno: nfs_client_enable is set to NO. /etc/rc: DEBUG: run_rc_command: doit: nisdomain_start /etc/rc: DEBUG: checkyesno: nis_server_enable is set to NO. /etc/rc: DEBUG: checkyesno: nis_client_enable is set to NO. /etc/rc: DEBUG: checkyesno: amd_enable is set to NO. /etc/rc: DEBUG: checkyesno: atm_enable is set to NO. /etc/rc: DEBUG: checkyesno: auditd_enable is set to NO. /etc/rc: DEBUG: checkyesno: dmesg_enable is set to YES. /etc/rc: DEBUG: run_rc_command: doit: do_dmesg /etc/rc: DEBUG: checkyesno: ipxrouted_enable is set to NO. /etc/rc: DEBUG: checkyesno: kerberos5_server_enable is set to NO. /etc/rc: DEBUG: checkyesno: kadmind5_server_enable is set to NO. /etc/rc: DEBUG: checkyesno: keyserv_enable is set to NO. /etc/rc: DEBUG: checkyesno: kpasswdd_server_enable is set to NO. /etc/rc: DEBUG: checkyesno: enable_quotas is set to NO. /etc/rc: DEBUG: checkyesno: nfs_server_enable is set to NO. /etc/rc: DEBUG: checkyesno: mountd_enable is set to NO. /etc/rc: DEBUG: checkyesno: nfs_server_enable is set to NO. /etc/rc: DEBUG: checkyesno: rpc_statd_enable is set to NO. /etc/rc: DEBUG: checkyesno: rpc_lockd_enable is set to NO. /etc/rc: DEBUG: checkyesno: pppoed_enable is set to NO. /etc/rc: DEBUG: run_rc_command: doit: pwcheck_start /etc/rc: DEBUG: checkyesno: virecover_enable is set to YES. /etc/rc: DEBUG: run_rc_command: doit: virecover_start /etc/rc: DEBUG: checkyesno: svnserve_enable is set to NO. /etc/rc: DEBUG: checkyesno: smartd_enable is set to YES. /etc/rc: DEBUG: pid file (/var/run/smartd.pid): not readable. Starting smartd. /etc/rc: DEBUG: run_rc_command: doit: /usr/local/sbin/smartd -p /var/run/smartd.pid -c /usr/local/etc/smartd.conf Oct 8 10:54:45 myhost smartd[9950]: Device: /dev/ad0, no ATA CHECK POWER STATUS support, ignoring -n Directive /etc/rc: DEBUG: checkyesno: privoxy_enable is set to NO. /etc/rc: DEBUG: checkyesno: dbus_enable is set to NO. /etc/rc: DEBUG: checkyesno: hald_enable is set to NO. /etc/rc: DEBUG: checkyesno: git_daemon_enable is set to NO. /etc/rc: DEBUG: checkyesno: apm_enable is set to NO. /etc/rc: DEBUG: checkyesno: apmd_enable is set to NO. /etc/rc: DEBUG: checkyesno: bootparamd_enable is set to NO. /etc/rc: DEBUG: checkyesno: hcsecd_enable is set to NO. /etc/rc: DEBUG: checkyesno: bthidd_enable is set to NO. /etc/rc: DEBUG: run_rc_command: doit: local_start Starting local daemons: . /etc/rc: DEBUG: checkyesno: lpd_enable is set to NO. /etc/rc: DEBUG: checkyesno: update_motd is set to NO. /etc/rc: DEBUG: run_rc_command: doit: mountlate_start Mounting late file systems: . /etc/rc: DEBUG: checkyesno: nscd_enable is set to NO. /etc/rc: DEBUG: checkyesno: ntpd_enable is set to NO. /etc/rc: DEBUG: checkyesno: powerd_enable is set to NO. /etc/rc: DEBUG: checkyesno: rarpd_enable is set to NO. /etc/rc: DEBUG: checkyesno: sdpd_enable is set to NO. /etc/rc: DEBUG: checkyesno: rfcomm_pppd_server_enable is set to NO. /etc/rc: DEBUG: checkyesno: rtadvd_enable is set to NO. /etc/rc: DEBUG: checkyesno: rwhod_enable is set to NO. /etc/rc: DEBUG: checkyesno: timed_enable is set to NO. /etc/rc: DEBUG: checkyesno: ugidfw_enable is set to NO. /etc/rc: DEBUG: checkyesno: nis_yppasswdd_enable is set to NO. /etc/rc: DEBUG: checkyesno: ataidle_enable is set to NO. /etc/rc: DEBUG: checkyesno: cvsyncd_enable is set to NO. /etc/rc: DEBUG: checkyesno: clamav_clamd_enable is set to NO. /etc/rc: DEBUG: checkyesno: clamav_milter_enable is set to NO. /etc/rc: DEBUG: checkyesno: clamav_freshclam_enable is set to NO. /etc/rc: DEBUG: checkyesno: avahi_daemon_enable is set to NO. /etc/rc: DEBUG: checkyesno: avahi_dnsconfd_enable is set to NO. /etc/rc: DEBUG: checkyesno: nis_ypxfrd_enable is set to NO. /etc/rc: DEBUG: checkyesno: rpc_ypupdated_enable is set to NO. /etc/rc: DEBUG: checkyesno: nis_ypset_enable is set to NO. /etc/rc: DEBUG: checkyesno: watchdogd_enable is set to NO. /etc/rc: DEBUG: run_rc_command: start_precmd: syscons_precmd /etc/rc: DEBUG: run_rc_command: doit: syscons_start Configuring syscons: keymap scrnmap font8x16 font8x14 font8x8 blanktime screensaver /etc/rc: DEBUG: load_kld: green_saver kernel module already loaded. . /etc/rc: DEBUG: checkyesno: sshd_enable is set to NO. /etc/rc: DEBUG: checkyesno: sendmail_enable is set to NO. /etc/rc: DEBUG: checkyesno: sendmail_submit_enable is set to NO. /etc/rc: DEBUG: checkyesno: sendmail_enable is set to NO. /etc/rc: DEBUG: checkyesno: sendmail_submit_enable is set to NO. /etc/rc: DEBUG: checkyesno: sendmail_outbound_enable is set to NO. /etc/rc: DEBUG: checkyesno: sendmail_msp_queue_enable is set to YES. /etc/rc: DEBUG: pid file (/var/spool/clientmqueue/sm-client.pid): not readable. /etc/rc: DEBUG: run_rc_command: start_precmd: sendmail_precmd /etc/rc: DEBUG: checkyesno: sendmail_msp_queue_enable is set to YES. /etc/rc: DEBUG: checkyesno: sendmail_rebuild_aliases is set to NO. /etc/rc: DEBUG: run_rc_command: doit: /usr/sbin/sendmail -L sm-msp-queue -Ac -q30m /etc/rc: DEBUG: checkyesno: cron_dst is set to YES. /etc/rc: DEBUG: checkyesno: cron_enable is set to YES. /etc/rc: DEBUG: pid file (/var/run/cron.pid): not readable. Starting cron. /etc/rc: DEBUG: run_rc_command: doit: /usr/sbin/cron -s /etc/rc: DEBUG: checkyesno: jail_enable is set to NO. /etc/rc: DEBUG: run_rc_command: doit: pkg_start Local package initialization: . /etc/rc.d/sysctl: DEBUG: run_rc_command: doit: sysctl_start last net.inet.ip.fw.verbose_limit: 0 -> 500 net.inet.ip.fw.dyn_ack_lifetime: 300 -> 120 /etc/rc: DEBUG: checkyesno: kern_securelevel_enable is set to NO. /etc/rc: DEBUG: checkyesno: moused_enable is set to YES. /etc/rc: DEBUG: pid file (/var/run/moused.pid): not readable. /etc/rc: DEBUG: run_rc_command: doit: moused_start Starting default moused: mousechar_start . /etc/rc: DEBUG: checkyesno: mixer_enable is set to NO. /etc/rc: DEBUG: checkyesno: inetd_enable is set to NO. /etc/rc: DEBUG: checkyesno: idmapd_enable is set to NO. /etc/rc: DEBUG: checkyesno: hostapd_enable is set to NO. /etc/rc: DEBUG: run_rc_command: doit: geli2_start /etc/rc: DEBUG: checkyesno: ftpd_enable is set to NO. /etc/rc: DEBUG: checkyesno: ftpproxy_enable is set to NO. /etc/rc: DEBUG: checkyesno: bsnmpd_enable is set to NO. /etc/rc: DEBUG: run_rc_command: doit: bridge_start /etc/rc: DEBUG: checkyesno: background_fsck is set to YES. /etc/rc: DEBUG: run_rc_command: doit: bgfsck_start Starting background file system checks in 1200 seconds. Wed Oct 8 10:54:49 EDT 2008 TCP: [127.0.0.1]:51084 to [127.0.0.1]:25 tcpflags 0x2; tcp_input: Connection attempt to closed port TCP: [127.0.0.1]:51084 to [127.0.0.1]:25 tcpflags 0x2; tcp_input: Connection attempt to closed port TCP: [127.0.0.1]:51084 to [127.0.0.1]:25 tcpflags 0x2; tcp_input: Connection attempt to closed port TCP: [127.0.0.1]:51084 to [127.0.0.1]:25 tcpflags 0x2; tcp_input: Connection attempt to closed port TCP: [127.0.0.1]:51084 to [127.0.0.1]:25 tcpflags 0x2; tcp_input: Connection attempt to closed port TCP: [127.0.0.1]:51084 to [127.0.0.1]:25 tcpflags 0x2; tcp_input: Connection attempt to closed port TCP: [127.0.0.1]:51084 to [127.0.0.1]:25 tcpflags 0x2; tcp_input: Connection attempt to closed port TCP: [127.0.0.1]:51084 to [127.0.0.1]:25 tcpflags 0x2; tcp_input: Connection attempt to closed port TCP: [127.0.0.1]:51084 to [127.0.0.1]:25 tcpflags 0x2; tcp_input: Connection attempt to closed port Oct 8 11:00:15 myhost login: ROOT LOGIN (toor) ON ttyv0 t_delta 15.fd80bdcb75b60200 too short Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `bufdaemon' to stop...done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining...0 0 done All buffers synced. Uptime: 31m7s Rebooting... Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.1-PRERELEASE #0: Tue Oct 7 20:06:38 EDT 2008 root@myhost:/usr/obj/usr/src/sys/NEWKERNEL7 Preloaded elf kernel "/boot/kernel/kernel" at 0xc0812000. Preloaded acpi_dsdt "/boot/acpi_dsdt.aml" at 0xc0812160. Preloaded elf module "/boot/kernel/tmpfs.ko" at 0xc08121a8. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc0812254. Calibrating clock(s) ... i8254 clock: 1193133 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 906348035 Hz CPU: AMD Athlon(tm) Processor (906.35-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x642 Stepping = 2 Features=0x183f9ff AMD Features=0xc0440800,MMX+,3DNow!+,3DNow!> Data TLB: 24 entries, fully associative Instruction TLB: 16 entries, fully associative L1 data cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L2 internal cache: 256 kbytes, 64 bytes/line, 1 lines/tag, 8-way associative real memory = 536805376 (511 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000000c25000 - 0x000000001f6abfff, 514355200 bytes (125575 pages) avail memory = 515796992 (491 MB) bios32: Found BIOS32 Service Directory header at 0xc00f8140 bios32: Entry = 0xfd6e0 (c00fd6e0) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xfd6e0+0x12c pnpbios: Found PnP BIOS data at 0xc00f8190 pnpbios: Entry = f0000:ac15 Rev = 1.0 Other BIOS signatures found: ULE: setup cpu 0 random: kbd: new array size 4 kbd1 at kbdmux0 crypto: mem: Pentium Pro MTRR support enabled null: io: ACPI: RSDP @ 0x0xf8170/0x0014 (v 0 PTLTD ) ACPI: RSDT @ 0x0x1fffd352/0x002C (v 1 PTLTD RSDT 0x06040000 LTP 0x00000000) ACPI: FACP @ 0x0x1ffffb65/0x0074 (v 1 HP Pandora 0x06040000 PTL 0x00000001) ACPI: DSDT @ 0x0x1fffd37e/0x27E7 (v 1 HPHPD Pandora 0x06040000 MSFT 0x0100000B) ACPI: FACS @ 0x0x1fffffc0/0x0040 ACPI: BOOT @ 0x0x1ffffbd9/0x0027 (v 1 PTLTD $SBFTBL$ 0x06040000 LTP 0x00000001) npx0: INT 16 interface cryptosoft0: on motherboard crypto: assign cryptosoft0 driver id 0, flags 100663296 crypto: cryptosoft0 registers alg 1 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 2 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 3 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 4 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 5 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 16 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 6 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 7 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 18 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 19 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 20 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 8 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 15 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 9 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 10 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 13 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 14 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 11 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 21 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 17 flags 0 maxoplen 0 acpi0: on motherboard ACPI: Overriding _OS definition with "Microsoft Windows" ACPI: Table DSDT replaced by host OS ACPI: DSDT @ 0x0/0x25DB (v 1 HPHPD Pandora 0x06040000 INTL 0x20070320) acpi0: [MPSAFE] acpi0: [ITHREAD] pci_open(1): mode 1 addr port (0x0cf8) is 0x80002104 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=80] is there (id=70061022) pcibios: BIOS version 2.10 AcpiOsDerivePciId: \\_SB_.PCI0.PIB_.REGS -> bus 0 dev 4 func 0 AcpiOsDerivePciId: \\_SB_.PCI0.SLT1.REGS -> bus 0 dev 13 func 0 AcpiOsDerivePciId: \\_SB_.PCI0.SLT2.REGS -> bus 0 dev 14 func 0 AcpiOsDerivePciId: \\_SB_.PCI0.SLT3.REGS -> bus 0 dev 15 func 0 AcpiOsDerivePciId: \\_SB_.PCI0.SLT4.REGS -> bus 0 dev 16 func 0 AcpiOsDerivePciId: \\_SB_.PCI0.SLT5.REGS -> bus 0 dev 17 func 0 acpi0: Power Button (fixed) acpi0: wakeup code va 0xccdd7000 pa 0x1000 AcpiOsDerivePciId: \\_SB_.PCI0.REGS -> bus 0 dev 0 func 0 ACPI Error (dsopcode-0671): Field [ALB2] at 120 exceeds Buffer [CRSA] size 104 (bits) [20070320] ACPI Error (psparse-0626): Method parse/execution failed [\\_SB_.PCI0.PIB_.SIO0.LPT_._CRS] (Node 0xc29fc980), AE_AML_BUFFER_LIMIT ACPI Error (uteval-0309): Method execution failed [\\_SB_.PCI0.PIB_.SIO0.LPT_._CRS] (Node 0xc29fc980), AE_AML_BUFFER_LIMIT can't fetch resources for \\_SB_.PCI0.PIB_.SIO0.LPT_ - AE_AML_BUFFER_LIMIT ACPI timer: 0/4 0/4 0/6 1/1 0/4 0/6 0/5 0/6 0/4 0/4 -> 1 Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x8008-0x800b on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 6 7 9 10 11 14 15 Validation 0 11 N 0 3 4 6 7 9 10 11 14 15 After Disable 0 255 N 0 3 4 6 7 9 10 11 14 15 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 3 4 6 7 9 10 11 14 15 Validation 0 10 N 0 3 4 6 7 9 10 11 14 15 After Disable 0 255 N 0 3 4 6 7 9 10 11 14 15 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 9 N 0 3 4 6 7 9 10 11 14 15 Validation 0 9 N 0 3 4 6 7 9 10 11 14 15 After Disable 0 255 N 0 3 4 6 7 9 10 11 14 15 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 6 7 9 10 11 14 15 Validation 0 255 N 0 3 4 6 7 9 10 11 14 15 After Disable 0 255 N 0 3 4 6 7 9 10 11 14 15 pcib0: port 0xcf8-0xcff on acpi0 ACPI: Found matching pin for 0.4.INTD at func 2: 9 ACPI: Found matching pin for 0.14.INTA at func 0: 10 ACPI: Found matching pin for 0.15.INTA at func 0: 9 pci0: on pcib0 pci0: domain=0, physical bus=0 found-> vendor=0x1022, dev=0x7006, revid=0x25 domain=0, bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x2210, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[10]: type Prefetchable Memory, range 32, base 0xf8000000, size 26, enabled map[14]: type Prefetchable Memory, range 32, base 0xf4012000, size 12, enabled map[18]: type I/O Port, range 32, base 0x1470, size 2, port disabled found-> vendor=0x1022, dev=0x7007, revid=0x01 domain=0, bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0220, cachelnsz=0 (dwords) lattimer=0x63 (2970 ns), mingnt=0x0c (3000 ns), maxlat=0x00 (0 ns) found-> vendor=0x1106, dev=0x0686, revid=0x22 domain=0, bus=0, slot=4, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x008f, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1106, dev=0x0571, revid=0x10 domain=0, bus=0, slot=4, func=1 class=01-01-8a, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 map[20]: type I/O Port, range 32, base 0x1460, size 4, enabled found-> vendor=0x1106, dev=0x3038, revid=0x10 domain=0, bus=0, slot=4, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0017, statreg=0x0210, cachelnsz=16 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=9 powerspec 2 supports D0 D3 current D0 map[20]: type I/O Port, range 32, base 0x1440, size 5, enabled pcib0: matched entry for 0.4.INTD (src \\_SB_.PCI0.PIB_.LNKD:0) pcib0: slot 4 INTD routed to irq 9 via \\_SB_.PCI0.PIB_.LNKD found-> vendor=0x1106, dev=0x3038, revid=0x10 domain=0, bus=0, slot=4, func=3 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0015, statreg=0x0210, cachelnsz=16 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=255 powerspec 2 supports D0 D3 current D0 map[20]: type I/O Port, range 32, base 0xfce0, size 5, enabled found-> vendor=0x1106, dev=0x3057, revid=0x30 domain=0, bus=0, slot=4, func=4 class=0c-05-00, hdrtype=0x00, mfdev=0 cmdreg=0x0000, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 found-> vendor=0x127a, dev=0x4310, revid=0x00 domain=0, bus=0, slot=14, func=0 class=04-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0003, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 1 supports D0 D1 D3 current D0 map[10]: type I/O Port, range 32, base 0x1400, size 6, enabled pcib0: matched entry for 0.14.INTA (src \\_SB_.PCI0.PIB_.LNKB:0) pcib0: slot 14 INTA routed to irq 10 via \\_SB_.PCI0.PIB_.LNKB found-> vendor=0x127a, dev=0x4311, revid=0x00 domain=0, bus=0, slot=14, func=1 class=07-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0003, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 1 supports D0 D2 D3 current D0 map[10]: type Memory, range 32, base 0xf4000000, size 16, enabled pcib0: matched entry for 0.14.INTA (src \\_SB_.PCI0.PIB_.LNKB:0) pcib0: slot 14 INTA routed to irq 10 via \\_SB_.PCI0.PIB_.LNKB found-> vendor=0x127a, dev=0x4312, revid=0x00 domain=0, bus=0, slot=14, func=2 class=09-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0003, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 1 supports D0 D2 D3 current D0 map[10]: type Memory, range 32, base 0xf4010000, size 12, enabled found-> vendor=0x1113, dev=0x1211, revid=0x10 domain=0, bus=0, slot=15, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0003, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x20 (8000 ns), maxlat=0x40 (16000 ns) intpin=a, irq=9 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type I/O Port, range 32, base 0x1000, size 8, enabled map[14]: type Memory, range 32, base 0xf4011000, size 8, enabled pcib0: matched entry for 0.15.INTA (src \\_SB_.PCI0.PIB_.LNKC:0) pcib0: slot 15 INTA routed to irq 9 via \\_SB_.PCI0.PIB_.LNKC agp0: on hostb0 hostb0: Reserved 0x4000000 bytes for rid 0x10 type 3 at 0xf8000000 hostb0: Reserved 0x1000 bytes for rid 0x14 type 3 at 0xf4012000 agp0: allocating GATT for aperture of size 64M agp0: gatt -> ag_pdir 0x1064000 agp0: allocating GATT for 16384 AGP page entries pcib1: at device 1.0 on pci0 pcib1: domain 0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0xf000-0xfff pcib1: memory decode 0xf5000000-0xf5ffffff pcib1: prefetched decode 0xfc000000-0xfdffffff ACPI: Found matching pin for 1.5.INTA at func 0: 11 pci1: on pcib1 pci1: domain=0, physical bus=1 found-> vendor=0x10de, dev=0x002c, revid=0x15 domain=0, bus=1, slot=5, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x02b0, cachelnsz=0 (dwords) lattimer=0x28 (1200 ns), mingnt=0x05 (1250 ns), maxlat=0x01 (250 ns) intpin=a, irq=11 powerspec 1 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xf5000000, size 24, enabled pcib1: requested memory range 0xf5000000-0xf5ffffff: good map[14]: type Prefetchable Memory, range 32, base 0xfc000000, size 25, enabled pcib1: requested memory range 0xfc000000-0xfdffffff: good pcib1: matched entry for 1.5.INTA (src \\_SB_.PCI0.PIB_.LNKA:0) pcib1: slot 5 INTA routed to irq 11 via \\_SB_.PCI0.PIB_.LNKA vgapci0: mem 0xf5000000-0xf5ffffff,0xfc000000-0xfdffffff irq 11 at device 5.0 on pci1 isab0: at device 4.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1460-0x146f at device 4.1 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0x1460 ata0: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=03 ostat0=50 ostat1=00 ata0: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata0: stat1=0x00 err=0x01 lsb=0x00 msb=0x00 ata0: reset tp2 stat0=50 stat1=00 devices=0x1 ata0: [MPSAFE] ata0: [ITHREAD] ata1: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 ata1: reset tp1 mask=03 ostat0=50 ostat1=00 ata1: stat0=0xd0 err=0x00 lsb=0x00 msb=0x00 ata1: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb ata1: stat1=0x00 err=0x00 lsb=0xff msb=0xff ata1: reset tp2 stat0=00 stat1=00 devices=0x4 ata1: [MPSAFE] ata1: [ITHREAD] pci0: at device 4.2 (no driver attached) pci0: at device 4.3 (no driver attached) pci0: at device 4.4 (no driver attached) pci0: at device 14.0 (no driver attached) pci0: at device 14.1 (no driver attached) pci0: at device 14.2 (no driver attached) pci0: at device 15.0 (no driver attached) acpi_button0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0047 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: unable to allocate IRQ psmcpnp0: irq 12 on acpi0 psm0: current command byte:0047 psm0: strange result for test aux port (250). psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model IntelliMouse, device ID 3-00, 3 buttons psm0: config:00000000, flags:00000008, packet size:4 psm0: syncmask:08, syncbits:00 cpu0: on acpi0 cpu0: switching to generic Cx mode ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it atkbdc: atkbdc0 already exists; skipping it sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it pnp_identify: Trying Read_Port at 203 pnp_identify: Trying Read_Port at 243 pnp_identify: Trying Read_Port at 283 pnp_identify: Trying Read_Port at 2c3 pnp_identify: Trying Read_Port at 303 pnp_identify: Trying Read_Port at 343 pnp_identify: Trying Read_Port at 383 pnp_identify: Trying Read_Port at 3c3 PNP Identify complete isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices pmtimer0 on isa0 orm0: at iomem 0xc0000-0xca7ff,0xd0000-0xd3fff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd1, terminal emulator: sc (syscons terminal) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 fb0 at vga0 adv0: not probed (disabled) aha0: not probed (disabled) aic0: not probed (disabled) bt0: not probed (disabled) cs0: not probed (disabled) ed0: not probed (disabled) fdc0 failed to probe at port 0x3f0 irq 6 drq 2 on isa0 fe0: not probed (disabled) ie0: not probed (disabled) le0: not probed (disabled) ppc0 failed to probe at irq 7 on isa0 sio0 failed to probe at port 0x3f8 irq 4 on isa0 sio1 failed to probe at port 0x2f8 irq 3 on isa0 sio2: not probed (disabled) sio3: not probed (disabled) sn0: not probed (disabled) vt0: not probed (disabled) isa_probe_children: probing PnP devices Device configuration finished. Timecounter "TSC" frequency 906348035 Hz quality 800 Timecounters tick every 10.000 msec splash: image decoder found: green_saver crypto: IPsec: Initialized Security Association Processing. lo0: bpf attached ata0-master: pio=PIO4 wdma=WDMA2 udma=UDMA66 cable=80 wire ad0: setting PIO4 on 82C686A chip ad0: setting UDMA66 on 82C686A chip ad0: 43967MB at ata0-master UDMA66 ad0: 90045648 sectors [95286C/15H/63S] 16 sectors/interrupt 1 depth queue GEOM: new disk ad0ata1-master: pio=PIO4 wdma=WDMA2 udma=UDMA33 cable=40 wire Trying to mount root from ufs:/dev/ad0s1a start_init: trying /sbin/init WARNING: TMPFS is considered to be a highly experimental feature in FreeBSD. ipfw2 initialized, divert loadable, nat loadable, rule-based forwarding disabled, default to deny, logging disabled TCP: [127.0.0.1]:50114 to [127.0.0.1]:25 tcpflags 0x2; tcp_input: Connection attempt to closed port TCP: [127.0.0.1]:50114 to [127.0.0.1]:25 tcpflags 0x2; tcp_input: Connection attempt to closed port TCP: [127.0.0.1]:50114 to [127.0.0.1]:25 tcpflags 0x2; tcp_input: Connection attempt to closed port TCP: [127.0.0.1]:50114 to [127.0.0.1]:25 tcpflags 0x2; tcp_input: Connection attempt to closed port TCP: [127.0.0.1]:50114 to [127.0.0.1]:25 tcpflags 0x2; tcp_input: Connection attempt to closed port TCP: [127.0.0.1]:50114 to [127.0.0.1]:25 tcpflags 0x2; tcp_input: Connection attempt to closed port TCP: [127.0.0.1]:50114 to [127.0.0.1]:25 tcpflags 0x2; tcp_input: Connection attempt to closed port TCP: [127.0.0.1]:50114 to [127.0.0.1]:25 tcpflags 0x2; tcp_input: Connection attempt to closed port TCP: [127.0.0.1]:50114 to [127.0.0.1]:25 tcpflags 0x2; tcp_input: Connection attempt to closed port t_delta 15.fd809cfc695da780 too short From clint.olsen at gmail.com Wed Oct 8 18:13:40 2008 From: clint.olsen at gmail.com (Clint Olsen) Date: Wed Oct 8 18:13:48 2008 Subject: Problem with dump stalling In-Reply-To: <20081008170141.34C264500F@ptavv.es.net> References: <20081008085412.GA71654@icarus.home.lan> <20081008170141.34C264500F@ptavv.es.net> Message-ID: <20081008181332.GE32260@0lsen.net> On Oct 08, Kevin Oberman wrote: > I had a system that was showing these exact symptoms David described. It > did this both with -L and without. I went for about 3 months without a > successful dump. I did at least two full system re-installs to no avail. > Then, about 3 weeks ago, when I was about to start some serious > debugging, it started working again. Nothing was touched between the last > failure and the first success. I'm completely baffled! I had a lengthy discussion with Jeremy about this where he lowered the boom on my expectations with UFS2 and dump. I find the lack of a real incremental backup solution with the default filesystem in FreeBSD to be an alarming problem. Thanks, -Clint -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From oberman at es.net Wed Oct 8 18:20:27 2008 From: oberman at es.net (Kevin Oberman) Date: Wed Oct 8 18:20:34 2008 Subject: Problem with dump stalling In-Reply-To: Your message of "Wed, 08 Oct 2008 11:13:32 PDT." <20081008181332.GE32260@0lsen.net> Message-ID: <20081008182024.890C54501D@ptavv.es.net> > Date: Wed, 8 Oct 2008 11:13:32 -0700 > From: Clint Olsen > Sender: owner-freebsd-stable@freebsd.org > > On Oct 08, Kevin Oberman wrote: > > I had a system that was showing these exact symptoms David described. It > > did this both with -L and without. I went for about 3 months without a > > successful dump. I did at least two full system re-installs to no avail. > > Then, about 3 weeks ago, when I was about to start some serious > > debugging, it started working again. Nothing was touched between the last > > failure and the first success. I'm completely baffled! > > I had a lengthy discussion with Jeremy about this where he lowered the boom > on my expectations with UFS2 and dump. I find the lack of a real > incremental backup solution with the default filesystem in FreeBSD to be an > alarming problem. But it is a fairly unusual issue. We have a LOT of systems doing nightly dumps and only this one had the problem. It lasted for just over two months and simply vanished. I just wish I had some sort of explanation, especially when snapshots (-L) are not used. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 224 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20081008/ab479d9a/attachment.pgp From koitsu at FreeBSD.org Wed Oct 8 18:36:54 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Wed Oct 8 18:37:01 2008 Subject: Recent Problems with RELENG_7 i386 In-Reply-To: <104852.27020.qm@web39102.mail.mud.yahoo.com> References: <104852.27020.qm@web39102.mail.mud.yahoo.com> Message-ID: <20081008183652.GA83351@icarus.home.lan> On Wed, Oct 08, 2008 at 10:19:47AM -0700, bf wrote: > After updating to RELENG_7 i386 of this weekend, I have been having problems > with my machine. When booting normally, the system slows or hangs at the > login prompt. If I am able to continue past the prompt, I sometimes experience > erratic mouse behavior, and a subsequent hang, after varying lengths of time, > even under light workloads. The same problem does not seem to occur in > single-user mode, and did not occur with the RELENG_7 i386 of just over a > week ago. I have been unable to obtain crashdumps so far, and the only > log messages I can find that weren't present before are notices like those > recorded below: > > Oct 8 11:00:40 myhost kernel: t_delta 15.fd80bdcb75b60200 too short This comes from src/sys/kern/kern_tc.c, around line 908. I'm not familiar with the kernel, but two ideas come to mind: 1) If you have Intel SpeedStep (EIST) or AMD Cool'n'Quiet enabled in your BIOS, try disabling it, 2) If you're using powerd, disable it (I don't see it enabled), 3) Try keeping HZ at 1000 (the default). -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From onemda at gmail.com Wed Oct 8 18:55:40 2008 From: onemda at gmail.com (Paul B. Mahol) Date: Wed Oct 8 18:55:47 2008 Subject: 7.0-RELEASE panics when loading USB modules x2 In-Reply-To: <48ECE60F.3060804@incunabulum.net> References: <48ECE60F.3060804@incunabulum.net> Message-ID: <3a142e750810081155p33c18f50v6223621429376f35@mail.gmail.com> On 10/8/08, Bruce M Simpson wrote: > Hi, > > I just had 7.0-RELEASE crash again, whilst kldloading the uplcom.ko module > in multi-user mode with X running, and no USB serial devices plugged in. > > The T43 immediately resets, I don't get a chance to drop into a debugger. > > This seems like a pretty serious USB regression. Is anyone looking into it? > Are these things a thing of the past with the "new" USB code? usb2 have uplcom2 inside usb2_serial module. try it and report outcome. From sclark46 at earthlink.net Wed Oct 8 19:07:09 2008 From: sclark46 at earthlink.net (Stephen Clark) Date: Wed Oct 8 19:07:16 2008 Subject: 6.3-p5 watchdog timer not being disabled Message-ID: <48ED04DA.8050902@earthlink.net> Hello List, We have 2 different platforms that we are trying to use the watchdog timer and watchdogd program on. One is a Soekris 5501: CPU: Geode(TM) Integrated Processor by AMD PCS (433.25-MHz 586-class CPU) Origin = "AuthenticAMD" Id = 0x5a2 Stepping = 2 Features=0x88a93d AMD Features=0xc0400000 The other is a: CPU: VIA C3 Nehemiah+RNG (1002.28-MHz 686-class CPU) Origin = "CentaurHauls" Id = 0x694 Stepping = 4 Features=0x380b03d According to the manpage on watchdogd if is killed with either SIGTERM or SIGINT it is suppose to disable the watchdog timer in the kernel so the system won't reboot. On both of the above platforms this does not work and the platforms reboot when watchdogd is killed with a kill pid, after the timeout value (-t) that had been specified to watchdogd when starting it has elapsed. Am I misunderstanding how this is suppose to work? Thanks for the elucidation, Steve -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) From jhb at freebsd.org Wed Oct 8 19:11:31 2008 From: jhb at freebsd.org (John Baldwin) Date: Wed Oct 8 19:11:39 2008 Subject: [FreeBSD] Fix for ServerWorks HT1000 in upcoming 7.1? In-Reply-To: <20081008101515.GA59675@iib.unsam.edu.ar> References: <520894aa0809301434h68b94628x54ec08fd48785feb@mail.gmail.com> <48EBDE69.1030609@delphij.net> <20081008101515.GA59675@iib.unsam.edu.ar> Message-ID: <200810081412.10808.jhb@freebsd.org> On Wednesday 08 October 2008 06:15:15 am Fernan Aguero wrote: > > Did anyone who can trigger the data corruption has tried John's patch > > and let us know if it worked? > > Not yet. My problem is that it's not that easy ... (at least > for me, but maybe I'm missing something). > > The main issue for me is that I don't have a spare box > running 7.x. All my FreeBSD boxes are running 6.x > > I've tried to make a new 7.1-BETA bootable ISO from the > patched sources (make release), but failed ... this is the > first time I've ever attempted this, and it seems that you > cannot do that from a 6.x box (I have a full CVS mirror of > FreeBSD, and a fresh checkout of RELENG_7). You can just grab the existing iso, untar it into a directory, build your own GENERIC kernel and replace the /boot/kernel/kernel in the iso tree, then use mkisofs to build a new ISO. Just be sure that once you've installed the box, you copy the updated kernel onto the box somehow before you reboot from the installer (you can use the fixit shell to help with this). -- John Baldwin From kabaev at gmail.com Wed Oct 8 20:03:23 2008 From: kabaev at gmail.com (Alexander Kabaev) Date: Wed Oct 8 20:03:30 2008 Subject: Help me to develop a FreeBSD patch for gcc-4.2.1 In-Reply-To: <72513.12488.qm@web57002.mail.re3.yahoo.com> References: <20081007185328.29220983@kan.dnsalias.net> <72513.12488.qm@web57002.mail.re3.yahoo.com> Message-ID: <20081008160316.6e7d7f3f@kan.dnsalias.net> On Tue, 7 Oct 2008 20:25:03 -0700 (PDT) Unga wrote: > --- On Wed, 10/8/08, Alexander Kabaev wrote: > > > > > If you still have CVS tree available, you can do 'cvs > > diff -rFSF' in > > contrib/gcc and apply the patches to files gcc-4.2.1/gcc. > > > > Hi Alexander, thanks for the reply. > > I'm new to 'cvs diff -rFSF'. I need to do more home work before I try > your method. > > Could you kindly confirm it work for you? after applying the patch, > does your compilation of gcc complete cleanly? I get errors. > Therefore, could you try it please. > > I'm waiting for your reply. > > Best regards > Unga > I never had a good reason to try, but it should compile with little or no extra work. Getting diff against vendor branch in CVS is much easier way than what you are doing anyway. -- Alexander Kabaev -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20081008/5606f0e9/signature.pgp From fernan at iib.unsam.edu.ar Wed Oct 8 20:35:11 2008 From: fernan at iib.unsam.edu.ar (Fernan Aguero) Date: Wed Oct 8 20:35:19 2008 Subject: [FreeBSD] Fix for ServerWorks HT1000 in upcoming 7.1? In-Reply-To: <200810081412.10808.jhb@freebsd.org> References: <520894aa0809301434h68b94628x54ec08fd48785feb@mail.gmail.com> <48EBDE69.1030609@delphij.net> <20081008101515.GA59675@iib.unsam.edu.ar> <200810081412.10808.jhb@freebsd.org> Message-ID: <20081008203325.GD77374@iib.unsam.edu.ar> > On Wednesday 08 October 2008 06:15:15 am Fernan Aguero wrote: > > > Did anyone who can trigger the data corruption has tried John's patch > > > and let us know if it worked? > > > > Not yet. My problem is that it's not that easy ... (at least > > for me, but maybe I'm missing something). > > > > The main issue for me is that I don't have a spare box > > running 7.x. All my FreeBSD boxes are running 6.x > > > > I've tried to make a new 7.1-BETA bootable ISO from the > > patched sources (make release), but failed ... this is the > > first time I've ever attempted this, and it seems that you > > cannot do that from a 6.x box (I have a full CVS mirror of > > FreeBSD, and a fresh checkout of RELENG_7). > You can just grab the existing iso, OK > untar it into a directory, OK > build your own GENERIC kernel and replace the > /boot/kernel/kernel in the iso tree, Will I be able to do this using a 7.x checkout on a 6.x box? > then use mkisofs to build a new ISO. Just be sure that > once you've installed the box, you copy the updated kernel > onto the box somehow before you reboot from the installer > (you can use the fixit shell to help with this). Gotcha. > -- > John Baldwin Fernan From jhb at freebsd.org Wed Oct 8 21:02:12 2008 From: jhb at freebsd.org (John Baldwin) Date: Wed Oct 8 21:02:21 2008 Subject: [FreeBSD] Fix for ServerWorks HT1000 in upcoming 7.1? In-Reply-To: <20081008203325.GD77374@iib.unsam.edu.ar> References: <520894aa0809301434h68b94628x54ec08fd48785feb@mail.gmail.com> <200810081412.10808.jhb@freebsd.org> <20081008203325.GD77374@iib.unsam.edu.ar> Message-ID: <200810081700.55729.jhb@freebsd.org> On Wednesday 08 October 2008 04:33:25 pm Fernan Aguero wrote: > > On Wednesday 08 October 2008 06:15:15 am Fernan Aguero wrote: > > > > Did anyone who can trigger the data corruption has tried John's patch > > > > and let us know if it worked? > > > > > > Not yet. My problem is that it's not that easy ... (at least > > > for me, but maybe I'm missing something). > > > > > > The main issue for me is that I don't have a spare box > > > running 7.x. All my FreeBSD boxes are running 6.x > > > > > > I've tried to make a new 7.1-BETA bootable ISO from the > > > patched sources (make release), but failed ... this is the > > > first time I've ever attempted this, and it seems that you > > > cannot do that from a 6.x box (I have a full CVS mirror of > > > FreeBSD, and a fresh checkout of RELENG_7). > > > You can just grab the existing iso, > > OK > > > untar it into a directory, > > OK > > > build your own GENERIC kernel and replace the > > /boot/kernel/kernel in the iso tree, > > Will I be able to do this using a 7.x checkout on a 6.x box? You can use 'make kernel-toolchain' followed by 'make buildkernel' on a 6.x box to build a 7.x kernel though. -- John Baldwin From peter at wemm.org Thu Oct 9 01:17:41 2008 From: peter at wemm.org (Peter Wemm) Date: Thu Oct 9 01:17:48 2008 Subject: 'at now' not working as expected In-Reply-To: <48E75BB7.2060206@madpilot.net> References: <884679.22561.qm@web110112.mail.gq1.yahoo.com> <48E75BB7.2060206@madpilot.net> Message-ID: On Sat, Oct 4, 2008 at 5:04 AM, Guido Falsi wrote: > Jeff Richards wrote: >> >> When I try to schedule something immediately with an 'at now' command it >> appears to queue up but can wait multiple minutes before actually executing. >> >> Is there something I have missed with FreeBSD's version of at? I've used >> 'at now' with AIX, Linux, and OpenBSD and it immediately executes for those >> systems. >> >> I am running FreeBSD 7.0 stable. > > atrun is launched from crontab with a 5 minute granularity. So I think that > at now can launch command with at most a 5 minutes delay. > > If this is a problem you can make atrun be launched every minute > reconfiguring the crontab and you will wait at mosta one minute. > > This is explained in the at(1) man page. > > I don't know about other systems at setup. Having a stand-alone at/atrun like this is pretty antiquated. System V cron has had an integrated 'at' since the late 80's. If somebody wanted to update our vixie-cron to integrate atrun functionality it would make my day. It shouldn't be particularly hard. The trick is to leave the nasty at(1) code alone as much as possible and just do something for atrun(8). My tolerance for hacking at(1) code was exceeded when I added hacks for 'at sunrise' and 'at sunset' support to a local version. It wasn't pretty, especially when handling things like '30 minutes before sunrise' etc. (I use this for home automation stuff) -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV "All of this is for nothing if we don't go to the stars" - JMS/B5 "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell From smithi at nimnet.asn.au Thu Oct 9 04:04:23 2008 From: smithi at nimnet.asn.au (Ian Smith) Date: Thu Oct 9 04:04:31 2008 Subject: sidetrack [was Re: 'at now' not working as expected] In-Reply-To: References: <884679.22561.qm@web110112.mail.gq1.yahoo.com> <48E75BB7.2060206@madpilot.net> Message-ID: <20081009145337.P16723@sola.nimnet.asn.au> On Wed, 8 Oct 2008, Peter Wemm wrote: [..] > My tolerance for hacking at(1) code was exceeded when I added hacks > for 'at sunrise' and 'at sunset' support to a local version. It > wasn't pretty, especially when handling things like '30 minutes before > sunrise' etc. (I use this for home automation stuff) Peter, just curious .. from where do you pull the current sunrise/sunset info for your location, and in what form? cheers, Ian From bf2006a at yahoo.com Thu Oct 9 05:00:33 2008 From: bf2006a at yahoo.com (bf) Date: Thu Oct 9 05:00:40 2008 Subject: Recent Problems with RELENG_7 i386 In-Reply-To: <20081008183652.GA83351@icarus.home.lan> Message-ID: <501797.33750.qm@web39105.mail.mud.yahoo.com> --- On Wed, 10/8/08, Jeremy Chadwick wrote: > From: Jeremy Chadwick > Subject: Re: Recent Problems with RELENG_7 i386 > To: "bf" > Cc: freebsd-stable@freebsd.org > Date: Wednesday, October 8, 2008, 2:36 PM > On Wed, Oct 08, 2008 at 10:19:47AM -0700, bf wrote: > > After updating to RELENG_7 i386 of this weekend, I > have been having problems > > with my machine. When booting normally, the system > slows or hangs at the > > login prompt. If I am able to continue past the > prompt, I sometimes experience > > erratic mouse behavior, and a subsequent hang, after > varying lengths of time, > > even under light workloads. The same problem does not > seem to occur in > > single-user mode, and did not occur with the RELENG_7 > i386 of just over a > > week ago. I have been unable to obtain crashdumps so > far, and the only > > log messages I can find that weren't present > before are notices like those > > recorded below: > > > > Oct 8 11:00:40 myhost kernel: t_delta > 15.fd80bdcb75b60200 too short > > This comes from src/sys/kern/kern_tc.c, around line 908. > I'm not > familiar with the kernel, but two ideas come to mind: > > 1) If you have Intel SpeedStep (EIST) or AMD > Cool'n'Quiet enabled in > your BIOS, try disabling it, > > 2) If you're using powerd, disable it (I don't see > it enabled), > > 3) Try keeping HZ at 1000 (the default). > Thanks, Jeremy, for taking the time to consider my question and reply. My CPU is pre-Cool'n'Quiet, and as far as I can tell I had disabled all forms of power management that may affect the clock speeds. I have found that by raising kern.hz to 250, or by using the default, I no longer receive the t_delta is too short messages, and the other problems are no longer apparent. My question is: why did this occur now? I have been using a similar configuration for months now without any apparent problems. My original goal in using a lower kern.hz was to avoid burdening my machine with excessive context switching. I saw the relevant section of kern_tc.c before I wrote my first message, but when skimming through the changes in RELENG_7 over the past week or two, I couldn't see any commit that may have directly affected kernel timekeeping. Has some new workload been imposed on the system by recent changes, that may have made a kern.hz of 100 insufficient? Is this tuneable setting properly implemented, so that all parts of the base system are using it's current value rather than the default? Could some of my hardware, such as my RTC, be malfunctioning? Regards, b. > -- > | Jeremy Chadwick jdc at > parodius.com | > | Parodius Networking > http://www.parodius.com/ | > | UNIX Systems Administrator Mountain > View, CA, USA | > | Making life hard for others since 1977. PGP: > 4BD6C0CB | From koitsu at FreeBSD.org Thu Oct 9 05:12:16 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Thu Oct 9 05:12:32 2008 Subject: Recent Problems with RELENG_7 i386 In-Reply-To: <501797.33750.qm@web39105.mail.mud.yahoo.com> References: <20081008183652.GA83351@icarus.home.lan> <501797.33750.qm@web39105.mail.mud.yahoo.com> Message-ID: <20081009051214.GA94941@icarus.home.lan> On Wed, Oct 08, 2008 at 10:00:32PM -0700, bf wrote: > > > > --- On Wed, 10/8/08, Jeremy Chadwick wrote: > > > From: Jeremy Chadwick > > Subject: Re: Recent Problems with RELENG_7 i386 > > To: "bf" > > Cc: freebsd-stable@freebsd.org > > Date: Wednesday, October 8, 2008, 2:36 PM > > On Wed, Oct 08, 2008 at 10:19:47AM -0700, bf wrote: > > > After updating to RELENG_7 i386 of this weekend, I > > have been having problems > > > with my machine. When booting normally, the system > > slows or hangs at the > > > login prompt. If I am able to continue past the > > prompt, I sometimes experience > > > erratic mouse behavior, and a subsequent hang, after > > varying lengths of time, > > > even under light workloads. The same problem does not > > seem to occur in > > > single-user mode, and did not occur with the RELENG_7 > > i386 of just over a > > > week ago. I have been unable to obtain crashdumps so > > far, and the only > > > log messages I can find that weren't present > > before are notices like those > > > recorded below: > > > > > > Oct 8 11:00:40 myhost kernel: t_delta > > 15.fd80bdcb75b60200 too short > > > > This comes from src/sys/kern/kern_tc.c, around line 908. > > I'm not > > familiar with the kernel, but two ideas come to mind: > > > > 1) If you have Intel SpeedStep (EIST) or AMD > > Cool'n'Quiet enabled in > > your BIOS, try disabling it, > > > > 2) If you're using powerd, disable it (I don't see > > it enabled), > > > > 3) Try keeping HZ at 1000 (the default). > > > > Thanks, Jeremy, for taking the time to consider my question and reply. > > My CPU is pre-Cool'n'Quiet, and as far as I can tell I had disabled > all forms of power management that may affect the clock speeds. I have > found that by raising kern.hz to 250, or by using the default, I no > longer receive the t_delta is too short messages, and the other problems > are no longer apparent. My question is: why did this occur now? I don't know. We can't rewind time and find out system parameters and kernel details from 6 months ago. :-) I'm thinking it might have something to do with the timecounter selected by the kernel, but as I said, we can't rewind time to find out what things were in the past. The kernel environment variables I'm talking about are kern.timecounter. "sysctl kern.timecounter" could help shed some light here, maybe. It would at least allow us to see what timecounters are available on your system, and if a bad/unreliable one is being selected automatically. > I have been using a similar configuration for months now without any > apparent problems. My original goal in using a lower kern.hz was to > avoid burdening my machine with excessive context switching. This is over my head, technically. I would need to pull John Baldwin into this, since he knows a bit about both (timecounters and context switching). I'm just a simple caveman..... :-) > I saw the relevant section of kern_tc.c before I wrote my first > message, but when skimming through the changes in RELENG_7 over the > past week or two, I couldn't see any commit that may have directly > affected kernel timekeeping. Has some new workload been imposed on > the system by recent changes, that may have made a kern.hz of 100 > insufficient? Is this tuneable setting properly implemented, so that > all parts of the base system are using it's current value rather than > the default? Could some of my hardware, such as my RTC, be > malfunctioning? Well, I believe HZ was increased from 100 to 1000 long ago (RELENG_6?) as a default. I'm really not sure of the implications of decreasing it, besides having less granularity for some things (the only things I know of would be something pertaining to firewalls, I just can't remember what. My brain is full. :-) ) -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From bf2006a at yahoo.com Thu Oct 9 07:20:42 2008 From: bf2006a at yahoo.com (bf) Date: Thu Oct 9 07:20:48 2008 Subject: Recent Problems with RELENG_7 i386 In-Reply-To: <20081009051214.GA94941@icarus.home.lan> Message-ID: <428021.27656.qm@web39105.mail.mud.yahoo.com> --- On Thu, 10/9/08, Jeremy Chadwick wrote: > From: Jeremy Chadwick > Subject: Re: Recent Problems with RELENG_7 i386 > To: "bf" > Cc: freebsd-stable@freebsd.org > Date: Thursday, October 9, 2008, 1:12 AM > On Wed, Oct 08, 2008 at 10:00:32PM -0700, bf wrote: > > > > > > > > --- On Wed, 10/8/08, Jeremy Chadwick > wrote: > > > > > From: Jeremy Chadwick > > > Subject: Re: Recent Problems with RELENG_7 i386 > > > To: "bf" > > > Cc: freebsd-stable@freebsd.org > > > Date: Wednesday, October 8, 2008, 2:36 PM > > > On Wed, Oct 08, 2008 at 10:19:47AM -0700, bf > wrote: > > > > After updating to RELENG_7 i386 of this > weekend, I > > > have been having problems > > > > with my machine. When booting normally, the > system > > > slows or hangs at the > > > > login prompt. If I am able to continue past > the > > > prompt, I sometimes experience > > > > erratic mouse behavior, and a subsequent > hang, after > > > varying lengths of time, > > > > even under light workloads. The same > problem does not > > > seem to occur in > > > > single-user mode, and did not occur with the > RELENG_7 > > > i386 of just over a > > > > week ago. I have been unable to obtain > crashdumps so > > > far, and the only > > > > log messages I can find that weren't > present > > > before are notices like those > > > > recorded below: > > > > > > > > Oct 8 11:00:40 myhost kernel: t_delta > > > 15.fd80bdcb75b60200 too short > > > > > > This comes from src/sys/kern/kern_tc.c, around > line 908. > > > I'm not > > > familiar with the kernel, but two ideas come to > mind: > > > > > > 1) If you have Intel SpeedStep (EIST) or AMD > > > Cool'n'Quiet enabled in > > > your BIOS, try disabling it, > > > > > > 2) If you're using powerd, disable it (I > don't see > > > it enabled), > > > > > > 3) Try keeping HZ at 1000 (the default). > > > > > > > Thanks, Jeremy, for taking the time to consider my > question and reply. > > > > My CPU is pre-Cool'n'Quiet, and as far as I > can tell I had disabled > > all forms of power management that may affect the > clock speeds. I have > > found that by raising kern.hz to 250, or by using the > default, I no > > longer receive the t_delta is too short messages, and > the other problems > > are no longer apparent. My question is: why did this > occur now? > > I don't know. We can't rewind time and find out > system parameters and > kernel details from 6 months ago. :-) Well, actually, with version control, we can -- if we're willing to take the trouble. My local settings haven't changed much, and the load we're talking about is not some pattern lost in the mists of time, but simply booting up. But I'm not suggesting going to any such lengths: the changed behavior occurred after the most recent changes to RELENG_7, in the past two weeks or less. Like you, I haven't taken the time to delve into the inner workings of the kernel, and so I was hoping that someone who had been monitoring RELENG_7's behavior (it's being tested before-and-after commits fairly often during this pre-release freeze, right?) or someone who had made recent changes might be able to narrow it down even further, either by pointing to some changes that might have tipped my machine over the edge at kern.hz=100, or by ruling out FreeBSD changes entirely and pointing the finger at some hardware problem. Some of the related sysctls are: kern.timecounter.tick: 1 kern.timecounter.choice: TSC(800) ACPI-safe(850) i8254(0) dummy(-1000000) kern.timecounter.hardware: ACPI-safe kern.timecounter.stepwarnings: 0 kern.timecounter.tc.i8254.mask: 4294967295 kern.timecounter.tc.i8254.frequency: 1193182 kern.timecounter.tc.i8254.quality: 0 kern.timecounter.tc.ACPI-safe.mask: 16777215 kern.timecounter.tc.ACPI-safe.frequency: 3579545 kern.timecounter.tc.ACPI-safe.quality: 850 kern.timecounter.tc.TSC.mask: 4294967295 kern.timecounter.tc.TSC.frequency: 906349154 kern.timecounter.tc.TSC.quality: 800 vfs.timestamp_precision: 0 machdep.acpi_timer_freq: 3579545 dev.acpi_timer.0.%desc: 24-bit timer at 3.579545MHz dev.acpi_timer.0.%driver: acpi_timer dev.acpi_timer.0.%location: unknown dev.acpi_timer.0.%pnpinfo: unknown dev.acpi_timer.0.%parent: acpi0 dev.attimer.0.%desc: AT realtime clock dev.attimer.0.%driver: attimer dev.attimer.0.%location: handle=\_SB_.PCI0.PIB_.RTC_ dev.attimer.0.%pnpinfo: _HID=PNP0B00 _UID=0 dev.attimer.0.%parent: acpi0 dev.attimer.1.%desc: AT timer dev.attimer.1.%driver: attimer dev.attimer.1.%location: handle=\_SB_.PCI0.PIB_.TIME dev.attimer.1.%pnpinfo: _HID=PNP0100 _UID=0 dev.attimer.1.%parent: acpi0 dev.pmtimer.0.%driver: pmtimer dev.pmtimer.0.%parent: isa0 and my original message showed how some of the timers were handled during booting up. I don't think these have changed since 12 Sept., when jhb@ changed local_apic.c in SVN rev 182982. So that change _alone_ would not have caused my problem. More recently, kib@ committed changes to db_trace.c, devfs, vm, ata, and to various kernel routines; and rwatson@ made changes to udp, tcp, sockets, and ipfw. Regards, b. > > I'm thinking it might have something to do with the > timecounter selected > by the kernel, but as I said, we can't rewind time to > find out what > things were in the past. > > The kernel environment variables I'm talking about are > kern.timecounter. > "sysctl kern.timecounter" could help shed some > light here, maybe. It > would at least allow us to see what timecounters are > available on your > system, and if a bad/unreliable one is being selected > automatically. > > > I have been using a similar configuration for months > now without any > > apparent problems. My original goal in using a lower > kern.hz was to > > avoid burdening my machine with excessive context > switching. > > This is over my head, technically. I would need to pull > John Baldwin > into this, since he knows a bit about both (timecounters > and context > switching). I'm just a simple caveman..... :-) > > > I saw the relevant section of kern_tc.c before I wrote > my first > > message, but when skimming through the changes in > RELENG_7 over the > > past week or two, I couldn't see any commit that > may have directly > > affected kernel timekeeping. Has some new workload > been imposed on > > the system by recent changes, that may have made a > kern.hz of 100 > > insufficient? Is this tuneable setting properly > implemented, so that > > all parts of the base system are using it's > current value rather than > > the default? Could some of my hardware, such as my > RTC, be > > malfunctioning? > > Well, I believe HZ was increased from 100 to 1000 long ago > (RELENG_6?) > as a default. I'm really not sure of the implications > of decreasing it, > besides having less granularity for some things (the only > things I know > of would be something pertaining to firewalls, I just > can't remember > what. My brain is full. :-) ) > > -- > | Jeremy Chadwick jdc at > parodius.com | > | Parodius Networking > http://www.parodius.com/ | > | UNIX Systems Administrator Mountain > View, CA, USA | > | Making life hard for others since 1977. PGP: > 4BD6C0CB | From unga888 at yahoo.com Thu Oct 9 09:34:41 2008 From: unga888 at yahoo.com (Unga) Date: Thu Oct 9 09:34:47 2008 Subject: Help me to develop a FreeBSD patch for gcc-4.2.1 In-Reply-To: <20081007185328.29220983@kan.dnsalias.net> Message-ID: <533947.52036.qm@web57005.mail.re3.yahoo.com> --- On Wed, 10/8/08, Alexander Kabaev wrote: > If you still have CVS tree available, you can do 'cvs > diff -rFSF' in > contrib/gcc and apply the patches to files gcc-4.2.1/gcc. > Hi Alexander Here is how I made the patch: cd ~ mkdir -pv freebsd cd freebsd cvs -d freebsdanoncvs@anoncvs.FreeBSD.org:/home/ncvs co -rRELENG_7 src cvs diff -rFSF >& FreeBSD-gcc-4.2.1.patch I have applied the patch on a fresh copy of gcc-4.2.1 and compiled. As before it develops errors: ../../gcc-4.2.1/gcc/c-format.c: In function 'check_format_info_main': ../../gcc-4.2.1/gcc/c-format.c:1780: error: 'flag_format_extensions' undeclared (first use in this function) ../../gcc-4.2.1/gcc/c-format.c:1780: error: (Each undeclared identifier is reported only once ../../gcc-4.2.1/gcc/c-format.c:1780: error: for each function it appears in.) gmake[2]: *** [c-format.o] Error 1 Have I missed out something? Could you help me to move forward from here? For an example, I can over come the above error by adding following lines to the gcc-4.2.1/gcc/config/i386/i386.opt: fformat-extensions Common Report Var(flag_format_extensions) Init(0) Allow FreeBSD kernel-specific printf format specifiers. Is that the correct move forward? Best regards Unga From chris+freebsd-stable at schug.net Thu Oct 9 10:20:55 2008 From: chris+freebsd-stable at schug.net (Christoph Schug) Date: Thu Oct 9 10:21:02 2008 Subject: Problem with dump stalling In-Reply-To: References: Message-ID: <20081009100816.GA8674@dt1.in-muc.ciao.com> On Wed, Oct 08, 2008, David Peall wrote: > I'm running 7.0-RELEASE-p4 and trying to backup to an external USB > drive. > > I'm using the following command > > dump -a0Lf /backup/diskimages/root /dev/mfid0s1a [...] > But it just stops at a random percentage, the system continues to run > and the processes are killable? This is a know bug which mainly affects multi-core CPU systems. It is fixed in RELENG_7, see also PR bin/121684 [1] where the relevant patch is referenced. [1] http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/121684 -cs From koitsu at FreeBSD.org Thu Oct 9 10:44:36 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Thu Oct 9 10:44:43 2008 Subject: Problem with dump stalling In-Reply-To: <20081009100816.GA8674@dt1.in-muc.ciao.com> References: <20081009100816.GA8674@dt1.in-muc.ciao.com> Message-ID: <20081009104432.GA2053@icarus.home.lan> On Thu, Oct 09, 2008 at 12:08:17PM +0200, Christoph Schug wrote: > On Wed, Oct 08, 2008, David Peall wrote: > > > I'm running 7.0-RELEASE-p4 and trying to backup to an external USB > > drive. > > > > I'm using the following command > > > > dump -a0Lf /backup/diskimages/root /dev/mfid0s1a > [...] > > But it just stops at a random percentage, the system continues to run > > and the processes are killable? > > This is a know bug which mainly affects multi-core CPU systems. It is > fixed in RELENG_7 see also PR bin/121684 [1] where the relevant patch > is referenced. > > [1] http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/121684 This was fixed on HEAD in revision 1.48 (March 13th), with the comment "MFC: 1 week". The commit to RELENG_7 did not happen until April 19th, see revision 1.39.2.3: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/subr_sleepqueue.c The PR referenced in the CVS commit is PR 117603. David, can you verify you're using a version of src/sys/kern/subr_sleepqueue.c that is 1.39.2.3 or newer? If so, the problem David is experiencing is different. If not, David will need to csup and then rebuild world and kernel (do NOT just do one; do both) to pick up the changes. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From andrewd at webzone.net.au Thu Oct 9 11:30:44 2008 From: andrewd at webzone.net.au (Andrew D) Date: Thu Oct 9 11:30:51 2008 Subject: sidetrack [was Re: 'at now' not working as expected] In-Reply-To: <20081009145337.P16723@sola.nimnet.asn.au> References: <884679.22561.qm@web110112.mail.gq1.yahoo.com> <48E75BB7.2060206@madpilot.net> <20081009145337.P16723@sola.nimnet.asn.au> Message-ID: <48EDE8DC.8030108@webzone.net.au> Hi Ian, Ian Smith wrote: > On Wed, 8 Oct 2008, Peter Wemm wrote: > [..] > > My tolerance for hacking at(1) code was exceeded when I added hacks > > for 'at sunrise' and 'at sunset' support to a local version. It > > wasn't pretty, especially when handling things like '30 minutes before > > sunrise' etc. (I use this for home automation stuff) > > Peter, just curious .. from where do you pull the current sunrise/sunset > info for your location, and in what form? > In Australia, you get it from Geoscience Australia. http://www.ga.gov.au/geodesy/astro/sunrise.jsp Just need a few curl queries and then extract the required info from the html source :) HTH cya Andrew > cheers, Ian > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From doconnor at gsoft.com.au Thu Oct 9 11:36:09 2008 From: doconnor at gsoft.com.au (Daniel O'Connor) Date: Thu Oct 9 11:36:17 2008 Subject: Userland PPP not deleting old IP on disconnect Message-ID: <200810092206.02362.doconnor@gsoft.com.au> Hi, I am using userland PPP to do PPPoE and I am finding that it isn't deleting the old IP from tun0 when the link goes down, eg Oct 9 22:00:01 midget ppp[53728]: tun0: Phase: deflink: logout -> hangup Oct 9 22:00:01 midget ppp[53728]: tun0: Phase: deflink: Connect time: 950 secs: 2711068 octets in, 39993514 octets out [midget 22:00] ~ >ifconfig tun0 tun0: flags=8051 metric 0 mtu 1500 inet 121.45.251.180 --> 203.16.215.184 netmask 0xffffffff Opened by PID 53728 I have the following config.. default: set device /dev/cuaa0 set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \"\" AT \ OK-AT-OK ATE1Q0 OK \\dATDT\\T TIMEOUT 40 CONNECT" set speed 115200 set ctsrts on set server /var/run/ppp/tun%d foobar set urgent tcp 22 set urgent udp 27010 27011 27012 27013 27014 27015 27016 27017 27018 27019 27020 27960 14577 14578 14579 14580 set log Phase Chat IPCP CCP tun command connect internode: set device PPPoE:em0 set ifaddr 0.0.0.0/0 0.0.0.0/0 resolv readonly disable pap enable dns set cd 5 set dial set login set redial 5+30-120 0 enable lqr enable echo set lqrperiod 3 set reconnect 10 100000 set authname username set authkey password add default HISADDR I don't have any linkup/linkdown scripts.. Any one have an idea why this would be happening? System is a FreeBSD midget.dons.net.au 7.0-STABLE FreeBSD 7.0-STABLE #1: Sun Jun 1 19:20:18 CST 2008 darius@midget.dons.net.au:/data/obj/data/src/sys/GENERIC i386 Thanks. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20081009/4d6909db/attachment.pgp From david at esn.org.za Thu Oct 9 11:58:50 2008 From: david at esn.org.za (David Peall) Date: Thu Oct 9 11:58:58 2008 Subject: Problem with dump stalling In-Reply-To: <20081009104432.GA2053@icarus.home.lan> References: <20081009100816.GA8674@dt1.in-muc.ciao.com> <20081009104432.GA2053@icarus.home.lan> Message-ID: > -----Original Message----- > From: owner-freebsd-stable@freebsd.org [mailto:owner-freebsd- > stable@freebsd.org] On Behalf Of Jeremy Chadwick > Sent: 09 October 2008 12:45 PM > To: Christoph Schug > Cc: freebsd-stable@freebsd.org; David Peall > Subject: Re: Problem with dump stalling > > This was fixed on HEAD in revision 1.48 (March 13th), with the comment > "MFC: 1 week". > > The commit to RELENG_7 did not happen until April 19th, see revision > 1.39.2.3: > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/subr_sleepqueue.c > > The PR referenced in the CVS commit is PR 117603. > > David, can you verify you're using a version of > src/sys/kern/subr_sleepqueue.c that is 1.39.2.3 or newer? > > If so, the problem David is experiencing is different. If not, David > will need to csup and then rebuild world and kernel (do NOT just do > one; do both) to pick up the changes. > I'm using stable: FreeBSD ochre.school.za 7.0-RELEASE-p4 FreeBSD 7.0-RELEASE-p4 #0: Tue Sep 2 18:48:24 UTC 2008 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 I don't update via source only via binaries, how would I tell? Regards -- David Peall :: IT Manager e-Schools' Network :: http://www.esn.org.za/ Phone +27 (021) 674-9140 From andrewd at webzone.net.au Thu Oct 9 12:22:51 2008 From: andrewd at webzone.net.au (Andrew D) Date: Thu Oct 9 12:22:58 2008 Subject: Userland PPP not deleting old IP on disconnect In-Reply-To: <200810092206.02362.doconnor@gsoft.com.au> References: <200810092206.02362.doconnor@gsoft.com.au> Message-ID: <48EDF787.2010305@webzone.net.au> Hi Fellow Node user :), I have the same + similar issue. Daniel O'Connor wrote: > Hi, > I am using userland PPP to do PPPoE and I am finding that it isn't deleting the old IP from tun0 when the link goes down, eg > > Oct 9 22:00:01 midget ppp[53728]: tun0: Phase: deflink: logout -> hangup > Oct 9 22:00:01 midget ppp[53728]: tun0: Phase: deflink: Connect time: 950 secs: 2711068 octets in, 39993514 octets out > > [midget 22:00] ~ >ifconfig tun0 > tun0: flags=8051 metric 0 mtu 1500 > inet 121.45.251.180 --> 203.16.215.184 netmask 0xffffffff > Opened by PID 53728 > tun0: flags=8051 metric 0 mtu 1492 inet 121.45.215.128 --> 203.16.215.183 netmask 0xffffffff inet 121.45.69.26 --> 203.16.215.186 netmask 0xffffffff Opened by PID 90863 The second line only shows up when the gateway is different between IP assignments from the ISP. I have no idea if this blocks access to the previous IP, not that it's a major issue. uname -a FreeBSD gateway.abdulla 7.0-STABLE FreeBSD 7.0-STABLE #1: Sat Jun 21 03:10:37 CST 2008 root@gateway.abdulla:/usr/obj/usr/src/sys/MYKERN i386 My ppp setup is almost the same. Cheers cya Andrew > I have the following config.. > default: > set device /dev/cuaa0 > set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \"\" AT \ > OK-AT-OK ATE1Q0 OK \\dATDT\\T TIMEOUT 40 CONNECT" > set speed 115200 > set ctsrts on > set server /var/run/ppp/tun%d foobar > set urgent tcp 22 > set urgent udp 27010 27011 27012 27013 27014 27015 27016 27017 27018 27019 27020 27960 14577 14578 14579 14580 > set log Phase Chat IPCP CCP tun command connect > internode: > set device PPPoE:em0 > set ifaddr 0.0.0.0/0 0.0.0.0/0 > resolv readonly > disable pap > enable dns > set cd 5 > set dial > set login > set redial 5+30-120 0 > enable lqr > enable echo > set lqrperiod 3 > set reconnect 10 100000 > set authname username > set authkey password > add default HISADDR > > I don't have any linkup/linkdown scripts.. > > Any one have an idea why this would be happening? > System is a FreeBSD midget.dons.net.au 7.0-STABLE FreeBSD 7.0-STABLE #1: Sun Jun 1 19:20:18 CST 2008 darius@midget.dons.net.au:/data/obj/data/src/sys/GENERIC i386 > > Thanks. > From smithi at nimnet.asn.au Thu Oct 9 12:24:27 2008 From: smithi at nimnet.asn.au (Ian Smith) Date: Thu Oct 9 12:24:34 2008 Subject: sidetrack [was Re: 'at now' not working as expected] In-Reply-To: <48EDE8DC.8030108@webzone.net.au> References: <884679.22561.qm@web110112.mail.gq1.yahoo.com> <48E75BB7.2060206@madpilot.net> <20081009145337.P16723@sola.nimnet.asn.au> <48EDE8DC.8030108@webzone.net.au> Message-ID: <20081009224610.Q16723@sola.nimnet.asn.au> On Thu, 9 Oct 2008, Andrew D wrote: > Ian Smith wrote: > > On Wed, 8 Oct 2008, Peter Wemm wrote: > > [..] > > > My tolerance for hacking at(1) code was exceeded when I added hacks > > > for 'at sunrise' and 'at sunset' support to a local version. It > > > wasn't pretty, especially when handling things like '30 minutes before > > > sunrise' etc. (I use this for home automation stuff) > > > > Peter, just curious .. from where do you pull the current sunrise/sunset > > info for your location, and in what form? > > In Australia, you get it from Geoscience Australia. > > http://www.ga.gov.au/geodesy/astro/sunrise.jsp > > Just need a few curl queries and then extract the required info from the html > source :) > > HTH Sure does, thanks Andrew. Saved as text, very amenable to a bit of grep 'n awking. Took transit times too, useful for calibrating solar clocks. cheers, Ian From david at esn.org.za Thu Oct 9 12:28:12 2008 From: david at esn.org.za (David Peall) Date: Thu Oct 9 12:28:21 2008 Subject: Problem with dump stalling In-Reply-To: <20081009104432.GA2053@icarus.home.lan> References: <20081009100816.GA8674@dt1.in-muc.ciao.com> <20081009104432.GA2053@icarus.home.lan> Message-ID: > -----Original Message----- > From: owner-freebsd-stable@freebsd.org [mailto:owner-freebsd- > stable@freebsd.org] On Behalf Of Jeremy Chadwick > Sent: 09 October 2008 12:45 PM > To: Christoph Schug > Cc: freebsd-stable@freebsd.org; David Peall > Subject: Re: Problem with dump stalling > > > This was fixed on HEAD in revision 1.48 (March 13th), with the comment > "MFC: 1 week". > > The commit to RELENG_7 did not happen until April 19th, see revision > 1.39.2.3: > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/subr_sleepqueue.c > > The PR referenced in the CVS commit is PR 117603. > > David, can you verify you're using a version of > src/sys/kern/subr_sleepqueue.c that is 1.39.2.3 or newer? > > If so, the problem David is experiencing is different. If not, David > will need to csup and then rebuild world and kernel (do NOT just do > one; do both) to pick up the changes. I have two identical machines the second one is displaying the same problems. I'm going to do a cvsup update and build work and kernel, the only partition on this server that is UFS is the /boot/ partition as its running ZFS on the others yet is still fails the dump that. If there is anyone willing to dedicate some time to this problem I will assist where I can? Regards -- David Peall :: IT Manager e-Schools' Network :: http://www.esn.org.za/ Phone +27 (021) 674-9140 From koitsu at FreeBSD.org Thu Oct 9 13:17:52 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Thu Oct 9 13:17:59 2008 Subject: Problem with dump stalling In-Reply-To: References: <20081009104432.GA2053@icarus.home.lan> Message-ID: <20081009131749.GA4679@icarus.home.lan> On Thu, Oct 09, 2008 at 01:58:39PM +0200, David Peall wrote: > > -----Original Message----- > > From: owner-freebsd-stable@freebsd.org [mailto:owner-freebsd- > > stable@freebsd.org] On Behalf Of Jeremy Chadwick > > Sent: 09 October 2008 12:45 PM > > To: Christoph Schug > > Cc: freebsd-stable@freebsd.org; David Peall > > Subject: Re: Problem with dump stalling > > > > This was fixed on HEAD in revision 1.48 (March 13th), with the comment > > "MFC: 1 week". > > > > The commit to RELENG_7 did not happen until April 19th, see revision > > 1.39.2.3: > > > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/subr_sleepqueue.c > > > > The PR referenced in the CVS commit is PR 117603. > > > > David, can you verify you're using a version of > > src/sys/kern/subr_sleepqueue.c that is 1.39.2.3 or newer? > > > > If so, the problem David is experiencing is different. If not, David > > will need to csup and then rebuild world and kernel (do NOT just do > > one; do both) to pick up the changes. > > > > I'm using stable: > FreeBSD ochre.school.za 7.0-RELEASE-p4 FreeBSD 7.0-RELEASE-p4 #0: Tue > Sep 2 18:48:24 UTC 2008 > root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 > > I don't update via source only via binaries, how would I tell? I'm not sure. I don't use freebsd-update, so I don't do binary-only upgrades. Someone else will have to chime in here for assistance. But I can tell you that freebsd-update does not get all the updates to certain things. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From freebsd-stable-local at be-well.ilk.org Thu Oct 9 13:40:22 2008 From: freebsd-stable-local at be-well.ilk.org (Lowell Gilbert) Date: Thu Oct 9 13:40:29 2008 Subject: sidetrack In-Reply-To: <48EDE8DC.8030108@webzone.net.au> (Andrew D.'s message of "Thu\, 09 Oct 2008 21\:49\:56 +1030") References: <884679.22561.qm@web110112.mail.gq1.yahoo.com> <48E75BB7.2060206@madpilot.net> <20081009145337.P16723@sola.nimnet.asn.au> <48EDE8DC.8030108@webzone.net.au> Message-ID: <44y70xhoos.fsf@be-well.ilk.org> Andrew D writes: > Hi Ian, > > Ian Smith wrote: >> On Wed, 8 Oct 2008, Peter Wemm wrote: >> [..] >> > My tolerance for hacking at(1) code was exceeded when I added hacks >> > for 'at sunrise' and 'at sunset' support to a local version. It >> > wasn't pretty, especially when handling things like '30 minutes before >> > sunrise' etc. (I use this for home automation stuff) >> >> Peter, just curious .. from where do you pull the current >> sunrise/sunset info for your location, and in what form? >> > > In Australia, you get it from Geoscience Australia. > > http://www.ga.gov.au/geodesy/astro/sunrise.jsp > > Just need a few curl queries and then extract the required info from > the html source :) You can get and hack the code they're using, too. On your Freebsd box, you can use astro/sscalc among a bunch of other ways of calculating the solar data. [My favorite example: emacs has lisp code for doing it, with glue for using it in the diary mode] From gpalmer at freebsd.org Thu Oct 9 15:36:16 2008 From: gpalmer at freebsd.org (Gary Palmer) Date: Thu Oct 9 15:36:22 2008 Subject: Problem with dump stalling In-Reply-To: References: <20081009104432.GA2053@icarus.home.lan> Message-ID: <20081009153613.GB1262@in-addr.com> On Thu, Oct 09, 2008 at 01:58:39PM +0200, David Peall wrote: > > -----Original Message----- > > From: owner-freebsd-stable@freebsd.org [mailto:owner-freebsd- > > stable@freebsd.org] On Behalf Of Jeremy Chadwick > > Sent: 09 October 2008 12:45 PM > > To: Christoph Schug > > Cc: freebsd-stable@freebsd.org; David Peall > > Subject: Re: Problem with dump stalling > > > > This was fixed on HEAD in revision 1.48 (March 13th), with the comment > > "MFC: 1 week". > > > > The commit to RELENG_7 did not happen until April 19th, see revision > > 1.39.2.3: > > > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/subr_sleepqueue.c > > > > The PR referenced in the CVS commit is PR 117603. > > > > David, can you verify you're using a version of > > src/sys/kern/subr_sleepqueue.c that is 1.39.2.3 or newer? > > > > If so, the problem David is experiencing is different. If not, David > > will need to csup and then rebuild world and kernel (do NOT just do > > one; do both) to pick up the changes. > > > > I'm using stable: > FreeBSD ochre.school.za 7.0-RELEASE-p4 FreeBSD 7.0-RELEASE-p4 #0: Tue > Sep 2 18:48:24 UTC 2008 > root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 > > I don't update via source only via binaries, how would I tell? > > Regards Try running: ident /boot/kernel/kernel | grep subr_sleepqueue That should give you the CVS id for the appropriate file Regards, Gary From smithi at nimnet.asn.au Thu Oct 9 16:51:04 2008 From: smithi at nimnet.asn.au (Ian Smith) Date: Thu Oct 9 16:51:12 2008 Subject: Recent Problems with RELENG_7 i386 In-Reply-To: <20081009051214.GA94941@icarus.home.lan> References: <20081008183652.GA83351@icarus.home.lan> <501797.33750.qm@web39105.mail.mud.yahoo.com> <20081009051214.GA94941@icarus.home.lan> Message-ID: <20081010023938.R16723@sola.nimnet.asn.au> On Wed, 8 Oct 2008, Jeremy Chadwick wrote: > On Wed, Oct 08, 2008 at 10:00:32PM -0700, bf wrote: > > --- On Wed, 10/8/08, Jeremy Chadwick wrote: [..] > > > > Oct 8 11:00:40 myhost kernel: t_delta > > > 15.fd80bdcb75b60200 too short > > > > > > This comes from src/sys/kern/kern_tc.c, around line 908. > > > I'm not > > > familiar with the kernel, but two ideas come to mind: > > > > > > 1) If you have Intel SpeedStep (EIST) or AMD > > > Cool'n'Quiet enabled in > > > your BIOS, try disabling it, > > > > > > 2) If you're using powerd, disable it (I don't see > > > it enabled), > > > > > > 3) Try keeping HZ at 1000 (the default). > > > > > > > Thanks, Jeremy, for taking the time to consider my question and reply. > > > > My CPU is pre-Cool'n'Quiet, and as far as I can tell I had disabled > > all forms of power management that may affect the clock speeds. I have > > found that by raising kern.hz to 250, or by using the default, I no > > longer receive the t_delta is too short messages, and the other problems > > are no longer apparent. My question is: why did this occur now? > > I don't know. We can't rewind time and find out system parameters and > kernel details from 6 months ago. :-) > > I'm thinking it might have something to do with the timecounter selected > by the kernel, but as I said, we can't rewind time to find out what > things were in the past. > > The kernel environment variables I'm talking about are kern.timecounter. > "sysctl kern.timecounter" could help shed some light here, maybe. It > would at least allow us to see what timecounters are available on your > system, and if a bad/unreliable one is being selected automatically. I see bf has since posted these values, but I'd already clipped stuff from the original post with kernel config and verbose dmesg, already wondering why the two didn't match, like: | options HZ=1000 | options DEVICE_POLLING but | CPU: AMD Athlon(tm) Processor (906.35-MHz 686-class CPU) | Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 | inittimecounter(0)... Timecounters tick every 10.000 msec ie HZ=100, as mentioned, and using ACPI-safe as later confirmed. So it's either a different kernel or bf updated kern.hz from loader.conf? > > I have been using a similar configuration for months now without any > > apparent problems. My original goal in using a lower kern.hz was to > > avoid burdening my machine with excessive context switching. > > This is over my head, technically. I would need to pull John Baldwin > into this, since he knows a bit about both (timecounters and context > switching). I'm just a simple caveman..... :-) Me too, but as I get to run much slower gear than many here, I have some small insight into what timer ticks work well with older kit. Not that a 900MHz Athlon should have any trouble with HZ=1000 at all, whereas on a 300MHz Celeron that's way too fast, pushing idle load up considerably. > > I saw the relevant section of kern_tc.c before I wrote my first > > message, but when skimming through the changes in RELENG_7 over the > > past week or two, I couldn't see any commit that may have directly > > affected kernel timekeeping. Has some new workload been imposed on > > the system by recent changes, that may have made a kern.hz of 100 > > insufficient? Is this tuneable setting properly implemented, so that > > all parts of the base system are using it's current value rather than > > the default? Could some of my hardware, such as my RTC, be > > malfunctioning? > > Well, I believe HZ was increased from 100 to 1000 long ago (RELENG_6?) > as a default. I'm really not sure of the implications of decreasing it, > besides having less granularity for some things (the only things I know > of would be something pertaining to firewalls, I just can't remember > what. My brain is full. :-) ) You need a day off :) But yes, RELENG_5 still had HZ=100 default, long after the 'average' CPU clock frequency was 10 or more times faster than the 166MHz Pentiums and such (mostly then on only 100Mbps ethernet) that were comfortable at 100Hz slicing. 1000Hz was a big shift to catch up. In a day or so playing around with it years ago, I found 200-250Hz good for 300MHz, 500Hz a bit much, 1000Hz way too busy, and find my 1133MHz P3-M happy enough at 1000Hz, though I've done no specific tests on it. Some people had perhaps similar clock issues when their fast processors were throttling/stepping down to very low speeds (100, even 75MHz) while still slicing at 1000Hz, which I didn't find too surprising. Limiting minimum CPU freq to 300Mz or more seemed to solve many such issues, but I haven't your perseverance for digging up the relevant threads .. Even in 5.5-S (/sys/conf/NOTES and /sys/i386/conf/NOTES) HZ=1000 or 2000 was suggested for DEVICE_POLLING (which bf included in config, though maybe it's not enabled?) and HZ=1000 or more was recommended when using DUMMYNET with ipfw - to provide smoother queue dispatching, I gather. Bottom line, IMHO, bf should probably run the default 1000Hz, 500 at least, on an Athlon 900. With powerd, maybe set min. freq >= 150MHz? cheers, Ian From koitsu at FreeBSD.org Thu Oct 9 17:07:31 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Thu Oct 9 17:07:38 2008 Subject: Recent Problems with RELENG_7 i386 In-Reply-To: <20081010023938.R16723@sola.nimnet.asn.au> References: <20081008183652.GA83351@icarus.home.lan> <501797.33750.qm@web39105.mail.mud.yahoo.com> <20081009051214.GA94941@icarus.home.lan> <20081010023938.R16723@sola.nimnet.asn.au> Message-ID: <20081009170727.GA9542@icarus.home.lan> On Fri, Oct 10, 2008 at 03:51:02AM +1100, Ian Smith wrote: > I see bf has since posted these values, but I'd already clipped stuff > from the original post with kernel config and verbose dmesg, already > wondering why the two didn't match, like: > > | options HZ=1000 > | options DEVICE_POLLING > > but > > | CPU: AMD Athlon(tm) Processor (906.35-MHz 686-class CPU) > | Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 > | inittimecounter(0)... Timecounters tick every 10.000 msec > > ie HZ=100, as mentioned, and using ACPI-safe as later confirmed. So > it's either a different kernel or bf updated kern.hz from loader.conf? Yep -- his original mail had loader.conf shown, with this in it (near the bottom): kern.hz=100 > > Well, I believe HZ was increased from 100 to 1000 long ago (RELENG_6?) > > as a default. I'm really not sure of the implications of decreasing it, > > besides having less granularity for some things (the only things I know > > of would be something pertaining to firewalls, I just can't remember > > what. My brain is full. :-) ) > > You need a day off :) But yes, RELENG_5 still had HZ=100 default, long > after the 'average' CPU clock frequency was 10 or more times faster than > the 166MHz Pentiums and such (mostly then on only 100Mbps ethernet) that > were comfortable at 100Hz slicing. 1000Hz was a big shift to catch up. > > In a day or so playing around with it years ago, I found 200-250Hz good > for 300MHz, 500Hz a bit much, 1000Hz way too busy, and find my 1133MHz > P3-M happy enough at 1000Hz, though I've done no specific tests on it. > > Some people had perhaps similar clock issues when their fast processors > were throttling/stepping down to very low speeds (100, even 75MHz) while > still slicing at 1000Hz, which I didn't find too surprising. Limiting > minimum CPU freq to 300Mz or more seemed to solve many such issues, but > I haven't your perseverance for digging up the relevant threads .. > > Even in 5.5-S (/sys/conf/NOTES and /sys/i386/conf/NOTES) HZ=1000 or 2000 > was suggested for DEVICE_POLLING (which bf included in config, though > maybe it's not enabled?) and HZ=1000 or more was recommended when using > DUMMYNET with ipfw - to provide smoother queue dispatching, I gather. > > Bottom line, IMHO, bf should probably run the default 1000Hz, 500 at > least, on an Athlon 900. With powerd, maybe set min. freq >= 150MHz? Wow, this is fantastic information. You've just educated me a great bit about the history and use of HZ. I've always had a "general" idea of its importance and key role, but I was never fully aware of the history. P.S. -- I need more like 6 months off. I've never taken an official (read: real) vacation my entire life. Maybe some day I'll get to travel to Seoul and visit Pyun Yong-Hyeon and drink lots of soju. :-) -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From dougb at FreeBSD.org Thu Oct 9 17:43:58 2008 From: dougb at FreeBSD.org (Doug Barton) Date: Thu Oct 9 17:44:05 2008 Subject: stable 7.0 and nslookup help command In-Reply-To: <20081007224422.5388D4500F@ptavv.es.net> References: <20081007224422.5388D4500F@ptavv.es.net> Message-ID: <48EE42DC.9090202@FreeBSD.org> Kevin Oberman wrote: > More importantly, dig(1) uses the standard resolver routines while > nslookup has its own. Actually you have that backwards. :) dig generates a raw dns request packet and sends it out on the wire itself, more or less acting as if it were an actual name server. Therefore if you are trying to debug problems with a name server it is the better choice. host uses the name servers in /etc/resolv.conf and more or less acts as a local stub resolver. It's a good choice if you just want to get the answer to "what does resolve to?" It's also a good tool for debugging what's happening when an application on your system is getting an answer other than the one you think it should get. nslookup actually uses the local stub resolver, and has the benefit of having been around a long time so it's something people know. It's also a good tool to debug the local stub resolver if you're getting an answer other than what you think you should be getting, and/or different from what dig/host say. hth, Doug -- This .signature sanitized for your protection From dimma at higis.ru Thu Oct 9 17:49:48 2008 From: dimma at higis.ru (Dmitriy Kirhlarov) Date: Thu Oct 9 17:49:56 2008 Subject: 7.1 i386 PXE Message-ID: <48EE3A9A.2080107@higis.ru> Hi, list I tryin update my install server. Look like 7.1 i386 pxe boot broken. My own release build is 7.1-i386-2008-10-05 Could somebody test this functionality and confirm or disprove my results. WBR Dmitriy From koitsu at FreeBSD.org Thu Oct 9 18:05:16 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Thu Oct 9 18:05:37 2008 Subject: 7.1 i386 PXE In-Reply-To: <48EE3A9A.2080107@higis.ru> References: <48EE3A9A.2080107@higis.ru> Message-ID: <20081009180513.GA10705@icarus.home.lan> On Thu, Oct 09, 2008 at 09:08:42PM +0400, Dmitriy Kirhlarov wrote: > I tryin update my install server. Look like 7.1 i386 pxe boot broken. > My own release build is 7.1-i386-2008-10-05 > > Could somebody test this functionality and confirm or disprove my results. What's broken about it? What behaviour happens? Are you aware of the mfsroot bug (see step 7 below): http://jdc.parodius.com/freebsd/pxeboot_serial_install.html -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From spork at bway.net Thu Oct 9 18:13:26 2008 From: spork at bway.net (Charles Sprickman) Date: Thu Oct 9 18:13:34 2008 Subject: Recent Problems with RELENG_7 i386 In-Reply-To: <20081009170727.GA9542@icarus.home.lan> References: <20081008183652.GA83351@icarus.home.lan> <501797.33750.qm@web39105.mail.mud.yahoo.com> <20081009051214.GA94941@icarus.home.lan> <20081010023938.R16723@sola.nimnet.asn.au> <20081009170727.GA9542@icarus.home.lan> Message-ID: On Thu, 9 Oct 2008, Jeremy Chadwick wrote: > On Fri, Oct 10, 2008 at 03:51:02AM +1100, Ian Smith wrote: >> > Well, I believe HZ was increased from 100 to 1000 long ago (RELENG_6?) >> > as a default. I'm really not sure of the implications of decreasing it, >> > besides having less granularity for some things (the only things I know >> > of would be something pertaining to firewalls, I just can't remember >> > what. My brain is full. :-) ) >> >> You need a day off :) But yes, RELENG_5 still had HZ=100 default, long >> after the 'average' CPU clock frequency was 10 or more times faster than >> the 166MHz Pentiums and such (mostly then on only 100Mbps ethernet) that >> were comfortable at 100Hz slicing. 1000Hz was a big shift to catch up. >> >> In a day or so playing around with it years ago, I found 200-250Hz good >> for 300MHz, 500Hz a bit much, 1000Hz way too busy, and find my 1133MHz >> P3-M happy enough at 1000Hz, though I've done no specific tests on it. >> >> Some people had perhaps similar clock issues when their fast processors >> were throttling/stepping down to very low speeds (100, even 75MHz) while >> still slicing at 1000Hz, which I didn't find too surprising. Limiting >> minimum CPU freq to 300Mz or more seemed to solve many such issues, but >> I haven't your perseverance for digging up the relevant threads .. >> >> Even in 5.5-S (/sys/conf/NOTES and /sys/i386/conf/NOTES) HZ=1000 or 2000 >> was suggested for DEVICE_POLLING (which bf included in config, though >> maybe it's not enabled?) and HZ=1000 or more was recommended when using >> DUMMYNET with ipfw - to provide smoother queue dispatching, I gather. >> >> Bottom line, IMHO, bf should probably run the default 1000Hz, 500 at >> least, on an Athlon 900. With powerd, maybe set min. freq >= 150MHz? > > Wow, this is fantastic information. You've just educated me a great bit > about the history and use of HZ. I've always had a "general" idea of > its importance and key role, but I was never fully aware of the history. Not to pull this too much further OT, but in the original message there was a comment about HZ and context switching. I care for a number of FBSD boxes that are stuffed full of qmail processes. Context switches are always through the roof when the boxes are busy. My layman's understanding of "context switching" is very vague - in short I assume it's some type of overhead from the kernel having to move between servicing different processes. Altering HZ to "tune" this is very intriguing to me, so if anyone would like to explain, I'm all ears. > P.S. -- I need more like 6 months off. I've never taken an official > (read: real) vacation my entire life. Maybe some day I'll get to travel > to Seoul and visit Pyun Yong-Hyeon and drink lots of soju. :-) Join the f***ing club. I'm still waiting for my honeymoon after two years of being married. :) Charles > -- > | Jeremy Chadwick jdc at parodius.com | > | Parodius Networking http://www.parodius.com/ | > | UNIX Systems Administrator Mountain View, CA, USA | > | Making life hard for others since 1977. PGP: 4BD6C0CB | > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From rink at FreeBSD.org Thu Oct 9 18:15:18 2008 From: rink at FreeBSD.org (Rink Springer) Date: Thu Oct 9 18:15:25 2008 Subject: 7.1 i386 PXE In-Reply-To: <48EE3A9A.2080107@higis.ru> References: <48EE3A9A.2080107@higis.ru> Message-ID: <20081009175803.GA21614@rink.nu> Hi Dmitriy, On Thu, Oct 09, 2008 at 09:08:42PM +0400, Dmitriy Kirhlarov wrote: > I tryin update my install server. Look like 7.1 i386 pxe boot broken. > My own release build is 7.1-i386-2008-10-05 Hmm, I tried it a few days ago and it worked fine for me. What kind of error are you seeing? Regards, -- Rink P.W. Springer - http://rink.nu "Anyway boys, this is America. Just because you get more votes doesn't mean you win." - Fox Mulder From olli at lurza.secnetix.de Thu Oct 9 20:17:46 2008 From: olli at lurza.secnetix.de (Oliver Fromme) Date: Thu Oct 9 20:17:52 2008 Subject: 7.1 i386 PXE In-Reply-To: <20081009180513.GA10705@icarus.home.lan> Message-ID: <200810092017.m99KHhdU022649@lurza.secnetix.de> Jeremy Chadwick wrote: > Dmitriy Kirhlarov wrote: > > I tryin update my install server. Look like 7.1 i386 pxe boot broken. > > My own release build is 7.1-i386-2008-10-05 > > > > Could somebody test this functionality and confirm or disprove my results. > > What's broken about it? What behaviour happens? Are you aware of the > mfsroot bug (see step 7 below): > > http://jdc.parodius.com/freebsd/pxeboot_serial_install.html It is a problem with memory management in the boot loader. I hit exactly the same problem during my experiments with the graphical boot loader, even without PXE and mfsroot involved. The problem is that the btx client breaks and behaves erratically when it runs out of memory. By default it can only use a part of the lower 640 KB of RAM, which isn't very much, given that the loader binary itself is already 250 KB, and the gzip decompressor requires quite some temporary memory for its dictionary. Unfortunately, debugging these things in the boot loader isn't exactly trivial. You can't just load it into gdb and single step it. If you want to boot via PXE but still use a gzipped mfs- root, a workaround is to skip loader.4th and beastie.4th, and instead boot the kernel directly from loader.rc. This should save enough memory to get you through. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Gesch?ftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n- chen, HRB 125758, Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd It's trivial to make fun of Microsoft products, but it takes a real man to make them work, and a God to make them do anything useful. From david at esn.org.za Thu Oct 9 22:14:13 2008 From: david at esn.org.za (David Peall) Date: Thu Oct 9 22:14:39 2008 Subject: Problem with dump stalling In-Reply-To: <20081009153613.GB1262@in-addr.com> References: <20081009104432.GA2053@icarus.home.lan> <20081009153613.GB1262@in-addr.com> Message-ID: > -----Original Message----- > From: owner-freebsd-stable@freebsd.org [mailto:owner-freebsd- > stable@freebsd.org] On Behalf Of Gary Palmer > Sent: 09 October 2008 05:36 PM > To: David Peall > Cc: freebsd-stable@freebsd.org; Jeremy Chadwick; Christoph Schug > Subject: Re: Problem with dump stalling > > > > -----Original Message----- > > > From: owner-freebsd-stable@freebsd.org [mailto:owner-freebsd- > > > stable@freebsd.org] On Behalf Of Jeremy Chadwick > > > Sent: 09 October 2008 12:45 PM > > > To: Christoph Schug > > > Cc: freebsd-stable@freebsd.org; David Peall > > > Subject: Re: Problem with dump stalling > > > > > > David, can you verify you're using a version of > > > src/sys/kern/subr_sleepqueue.c that is 1.39.2.3 or newer? > > > > > > If so, the problem David is experiencing is different. If not, > > > David > > > will need to csup and then rebuild world and kernel (do NOT just do > > > one; do both) to pick up the changes. > > > > > Try running: > > ident /boot/kernel/kernel | grep subr_sleepqueue Thank you Gary: $FreeBSD: src/sys/kern/subr_sleepqueue.c,v 1.39.4.1 2008/01/29 16:37:04 jhb Exp $ Which is indeed newer that 1.39.2.3 and dump on UFS2 is still a problem. -- David Peall :: IT Manager e-Schools' Network :: http://www.esn.org.za/ Phone +27 (021) 674-9140 From doconnor at gsoft.com.au Thu Oct 9 22:16:31 2008 From: doconnor at gsoft.com.au (Daniel O'Connor) Date: Thu Oct 9 22:16:39 2008 Subject: Userland PPP not deleting old IP on disconnect In-Reply-To: <48EDF787.2010305@webzone.net.au> References: <200810092206.02362.doconnor@gsoft.com.au> <48EDF787.2010305@webzone.net.au> Message-ID: <200810100846.19991.doconnor@gsoft.com.au> On Thu, 9 Oct 2008, Andrew D wrote: > Hi Fellow Node user :), > > I have the same + similar issue. > > Daniel O'Connor wrote: > > Hi, > > I am using userland PPP to do PPPoE and I am finding that it isn't > > deleting the old IP from tun0 when the link goes down, eg > > > > Oct 9 22:00:01 midget ppp[53728]: tun0: Phase: deflink: logout -> > > hangup Oct 9 22:00:01 midget ppp[53728]: tun0: Phase: deflink: > > Connect time: 950 secs: 2711068 octets in, 39993514 octets out > > > > [midget 22:00] ~ >ifconfig tun0 > > tun0: flags=8051 metric 0 mtu > > 1500 inet 121.45.251.180 --> 203.16.215.184 netmask 0xffffffff > > Opened by PID 53728 > > tun0: flags=8051 metric 0 mtu 1492 > inet 121.45.215.128 --> 203.16.215.183 netmask 0xffffffff > inet 121.45.69.26 --> 203.16.215.186 netmask 0xffffffff > Opened by PID 90863 > > The second line only shows up when the gateway is different between > IP assignments from the ISP. I have no idea if this blocks access to > the previous IP, not that it's a major issue. I wouldn't care too much except that ddclient looks at tun0 to find the IP to report to dyndns and gets the wrong one.. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20081009/a6e58603/attachment.pgp From peter at wemm.org Thu Oct 9 23:18:41 2008 From: peter at wemm.org (Peter Wemm) Date: Thu Oct 9 23:18:48 2008 Subject: sidetrack [was Re: 'at now' not working as expected] In-Reply-To: <48EDE8DC.8030108@webzone.net.au> References: <884679.22561.qm@web110112.mail.gq1.yahoo.com> <48E75BB7.2060206@madpilot.net> <20081009145337.P16723@sola.nimnet.asn.au> <48EDE8DC.8030108@webzone.net.au> Message-ID: On Thu, Oct 9, 2008 at 4:19 AM, Andrew D wrote: > Hi Ian, > > Ian Smith wrote: >> >> On Wed, 8 Oct 2008, Peter Wemm wrote: >> [..] >> > My tolerance for hacking at(1) code was exceeded when I added hacks >> > for 'at sunrise' and 'at sunset' support to a local version. It >> > wasn't pretty, especially when handling things like '30 minutes before >> > sunrise' etc. (I use this for home automation stuff) >> >> Peter, just curious .. from where do you pull the current sunrise/sunset >> info for your location, and in what form? >> > > In Australia, you get it from Geoscience Australia. > > http://www.ga.gov.au/geodesy/astro/sunrise.jsp > > Just need a few curl queries and then extract the required info from the > html source :) I just calculate it from my lat/lon. Its not particularly hard. I found a bunch of massively over-complicated code examples (mostly in javascript, or worse) that usually was GPL'ed. I ended up finding the original public domain code that was written in basic and did a simple conversion of that. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV "All of this is for nothing if we don't go to the stars" - JMS/B5 "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell From dillon at apollo.backplane.com Thu Oct 9 23:22:14 2008 From: dillon at apollo.backplane.com (Matthew Dillon) Date: Thu Oct 9 23:22:21 2008 Subject: sidetrack [was Re: 'at now' not working as expected] References: <884679.22561.qm@web110112.mail.gq1.yahoo.com> <48E75BB7.2060206@madpilot.net> <20081009145337.P16723@sola.nimnet.asn.au> <48EDE8DC.8030108@webzone.net.au> Message-ID: <200810092322.m99NMD3l043255@apollo.backplane.com> Also, if you happen to have a handheld GPS unit, it almost certainly has a menu option to tell you the sunrise and sunset times at your current position. -Matt From imb at protected-networks.net Fri Oct 10 00:09:02 2008 From: imb at protected-networks.net (Michael Butler) Date: Fri Oct 10 00:09:10 2008 Subject: sidetrack [was Re: 'at now' not working as expected] In-Reply-To: <200810092322.m99NMD3l043255@apollo.backplane.com> References: <884679.22561.qm@web110112.mail.gq1.yahoo.com> <48E75BB7.2060206@madpilot.net> <20081009145337.P16723@sola.nimnet.asn.au> <48EDE8DC.8030108@webzone.net.au> <200810092322.m99NMD3l043255@apollo.backplane.com> Message-ID: <48EE9D0E.8000002@protected-networks.net> Matthew Dillon wrote: > Also, if you happen to have a handheld GPS unit, it almost certainly > has a menu option to tell you the sunrise and sunset times at your > current position. The attached program (not mine - credits in the header) does this effectively given your current position as input, Michael From imb at protected-networks.net Fri Oct 10 00:17:05 2008 From: imb at protected-networks.net (Michael Butler) Date: Fri Oct 10 00:17:13 2008 Subject: sidetrack [was Re: 'at now' not working as expected] In-Reply-To: <48EE9D0E.8000002@protected-networks.net> References: <884679.22561.qm@web110112.mail.gq1.yahoo.com> <48E75BB7.2060206@madpilot.net> <20081009145337.P16723@sola.nimnet.asn.au> <48EDE8DC.8030108@webzone.net.au> <200810092322.m99NMD3l043255@apollo.backplane.com> <48EE9D0E.8000002@protected-networks.net> Message-ID: <48EE9EFA.3080009@protected-networks.net> I wrote: > The attached program (not mine - credits in the header) does this > effectively given your current position as input, Inserted as text since it got stripped last time .. > ------------------------------------------------------------------------ /* SUNRISET.C - computes Sun rise/set times, start/end of twilight, and the length of the day at any date and latitude Written as DAYLEN.C, 1989-08-16 Modified to SUNRISET.C, 1992-12-01 (c) Paul Schlyter, 1989, 1992 This program may be used by anyone for any purpose, iff: 1. it is not being sold for profit 2. this notice is not removed */ #include #include /* A macro to compute the number of days elapsed since 2000 Jan 0.0 */ /* (which is equal to 1999 Dec 31, 0h UT) */ #define days_since_2000_Jan_0(y,m,d) \ (367L*(y)-((7*((y)+(((m)+9)/12)))/4)+((275*(m))/9)+(d)-730530L) /* Some conversion factors between radians and degrees */ #ifndef PI #define PI 3.1415926535897932384 #endif #define RADEG ( 180.0 / PI ) #define DEGRAD ( PI / 180.0 ) /* The trigonometric functions in degrees */ #define sind(x) sin((x)*DEGRAD) #define cosd(x) cos((x)*DEGRAD) #define tand(x) tan((x)*DEGRAD) #define atand(x) (RADEG*atan(x)) #define asind(x) (RADEG*asin(x)) #define acosd(x) (RADEG*acos(x)) #define atan2d(y,x) (RADEG*atan2(y,x)) /* Following are some macros around the "workhorse" function __daylen__ */ /* They mainly fill in the desired values for the reference altitude */ /* below the horizon, and also selects whether this altitude should */ /* refer to the Sun's center or its upper limb. */ /* This macro computes the length of the day, from sunrise to sunset. */ /* Sunrise/set is considered to occur when the Sun's upper limb is */ /* 35 arc minutes below the horizon (this accounts for the refraction */ /* of the Earth's atmosphere). */ #define day_length(year,month,day,lon,lat) \ __daylen__( year, month, day, lon, lat, -35.0/60.0, 1 ) /* This macro computes the length of the day, including civil twilight. */ /* Civil twilight starts/ends when the Sun's center is 6 degrees below */ /* the horizon. */ #define day_civil_twilight_length(year,month,day,lon,lat) \ __daylen__( year, month, day, lon, lat, -6.0, 0 ) /* This macro computes the length of the day, incl. nautical twilight. */ /* Nautical twilight starts/ends when the Sun's center is 12 degrees */ /* below the horizon. */ #define day_nautical_twilight_length(year,month,day,lon,lat) \ __daylen__( year, month, day, lon, lat, -12.0, 0 ) /* This macro computes the length of the day, incl. astronomical twilight. */ /* Astronomical twilight starts/ends when the Sun's center is 18 degrees */ /* below the horizon. */ #define day_astronomical_twilight_length(year,month,day,lon,lat) \ __daylen__( year, month, day, lon, lat, -18.0, 0 ) /* This macro computes times for sunrise/sunset. */ /* Sunrise/set is considered to occur when the Sun's upper limb is */ /* 35 arc minutes below the horizon (this accounts for the refraction */ /* of the Earth's atmosphere). */ #define sun_rise_set(year,month,day,lon,lat,rise,set) \ __sunriset__( year, month, day, lon, lat, -35.0/60.0, 1, rise, set ) /* This macro computes the start and end times of civil twilight. */ /* Civil twilight starts/ends when the Sun's center is 6 degrees below */ /* the horizon. */ #define civil_twilight(year,month,day,lon,lat,start,end) \ __sunriset__( year, month, day, lon, lat, -6.0, 0, start, end ) /* This macro computes the start and end times of nautical twilight. */ /* Nautical twilight starts/ends when the Sun's center is 12 degrees */ /* below the horizon. */ #define nautical_twilight(year,month,day,lon,lat,start,end) \ __sunriset__( year, month, day, lon, lat, -12.0, 0, start, end ) /* This macro computes the start and end times of astronomical twilight. */ /* Astronomical twilight starts/ends when the Sun's center is 18 degrees */ /* below the horizon. */ #define astronomical_twilight(year,month,day,lon,lat,start,end) \ __sunriset__( year, month, day, lon, lat, -18.0, 0, start, end ) /* Function prototypes */ double __daylen__ (int year, int month, int day, double lon, double lat, double altit, int upper_limb); int __sunriset__ (int year, int month, int day, double lon, double lat, double altit, int upper_limb, double *rise, double *set); void sunpos (double d, double *lon, double *r); void sun_RA_dec (double d, double *RA, double *dec, double *r); double revolution (double x); double rev180 (double x); double GMST0 (double d); /* A small test program */ void main (void) { int year, month, day; double lon, lat; double daylen, civlen, nautlen, astrlen; double rise, set, civ_start, civ_end, naut_start, naut_end, astr_start, astr_end; int rs, civ, naut, astr; printf ("Longitude (+ is east) and latitude (+ is north) : "); scanf ("%lf %lf", &lon, &lat); for (;;) { printf ("Input date ( yyyy mm dd ): "); if (scanf ("%d %d %d", &year, &month, &day) != 3) exit (0); daylen = day_length (year, month, day, lon, lat); civlen = day_civil_twilight_length (year, month, day, lon, lat); nautlen = day_nautical_twilight_length (year, month, day, lon, lat); astrlen = day_astronomical_twilight_length (year, month, day, lon, lat); printf ("Day length: %5.2f hours\n", daylen); printf ("With civil twilight %5.2f hours\n", civlen); printf ("With nautical twilight %5.2f hours\n", nautlen); printf ("With astronomical twilight %5.2f hours\n", astrlen); printf ("Length of twilight: civil %5.2f hours\n", (civlen - daylen) / 2.0); printf (" nautical %5.2f hours\n", (nautlen - daylen) / 2.0); printf (" astronomical %5.2f hours\n", (astrlen - daylen) / 2.0); rs = sun_rise_set (year, month, day, lon, lat, &rise, &set); civ = civil_twilight (year, month, day, lon, lat, &civ_start, &civ_end); naut = nautical_twilight (year, month, day, lon, lat, &naut_start, &naut_end); astr = astronomical_twilight (year, month, day, lon, lat, &astr_start, &astr_end); printf ("Sun at south %5.2fh UT\n", (rise + set) / 2.0); switch (rs) { case 0: printf ("Sun rises %5.2fh UT, sets %5.2fh UT\n", rise, set); break; case +1: printf ("Sun above horizon\n"); break; case -1: printf ("Sun below horizon\n"); break; } switch (civ) { case 0: printf ("Civil twilight starts %5.2fh, ends %5.2fh UT\n", civ_start, civ_end); break; case +1: printf ("Never darker than civil twilight\n"); break; case -1: printf ("Never as bright as civil twilight\n"); break; } switch (naut) { case 0: printf ("Nautical twilight starts %5.2fh, ends %5.2fh UT\n", naut_start, naut_end); break; case +1: printf ("Never darker than nautical twilight\n"); break; case -1: printf ("Never as bright as nautical twilight \n"); break; } switch (astr) { case 0: printf ("Astronomical twilight starts %5.2fh, ends %5.2fh UT\n", astr_start, astr_end); break; case +1: printf ("Never darker than astronomical twilight \n "); break; case -1: printf ("Never as bright as astronomical twilight \n "); break; } } } /* The "workhorse" function for sun rise/set times */ int __sunriset__ (int year, int month, int day, double lon, double lat, double altit, int upper_limb, double *trise, double *tset) /***************************************************************************/ /* Note: year,month,date = calendar date, 1801-2099 only. */ /* Eastern longitude positive, Western longitude negative */ /* Northern latitude positive, Southern latitude negative */ /* The longitude value IS critical in this function! */ /* altit = the altitude which the Sun should cross */ /* Set to -35/60 degrees for rise/set, -6 degrees */ /* for civil, -12 degrees for nautical and -18 */ /* degrees for astronomical twilight. */ /* upper_limb: non-zero -> upper limb, zero -> center */ /* Set to non-zero (e.g. 1) when computing rise/set */ /* times, and to zero when computing start/end of */ /* twilight. */ /* *rise = where to store the rise time */ /* *set = where to store the set time */ /* Both times are relative to the specified altitude, */ /* and thus this function can be used to comupte */ /* various twilight times, as well as rise/set times */ /* Return value: 0 = sun rises/sets this day, times stored at */ /* *trise and *tset. */ /* +1 = sun above the specified "horizon" 24 hours. */ /* *trise set to time when the sun is at south, */ /* minus 12 hours while *tset is set to the south */ /* time plus 12 hours. "Day" length = 24 hours */ /* -1 = sun is below the specified "horizon" 24 hours */ /* "Day" length = 0 hours, *trise and *tset are */ /* both set to the time when the sun is at south. */ /* */ /**********************************************************************/ { double d, /* Days since 2000 Jan 0.0 (negative before) */ sr, /* Solar distance, astronomical units */ sRA, /* Sun's Right Ascension */ sdec, /* Sun's declination */ sradius, /* Sun's apparent radius */ t, /* Diurnal arc */ tsouth, /* Time when Sun is at south */ sidtime; /* Local sidereal time */ int rc = 0; /* Return cde from function - usually 0 */ /* Compute d of 12h local mean solar time */ d = days_since_2000_Jan_0 (year, month, day) + 0.5 - lon / 360.0; /* Compute local sideral time of this moment */ sidtime = revolution (GMST0 (d) + 180.0 + lon); /* Compute Sun's RA + Decl at this moment */ sun_RA_dec (d, &sRA, &sdec, &sr); /* Compute time when Sun is at south - in hours UT */ tsouth = 12.0 - rev180 (sidtime - sRA) / 15.0; /* Compute the Sun's apparent radius, degrees */ sradius = 0.2666 / sr; /* Do correction to upper limb, if necessary */ if (upper_limb) altit -= sradius; /* Compute the diurnal arc that the Sun traverses to reach */ /* the specified altitide altit: */ { double cost; cost = (sind (altit) - sind (lat) * sind (sdec)) / (cosd (lat) * cosd (sdec)); if (cost >= 1.0) rc = -1, t = 0.0; /* Sun always below altit */ else if (cost <= -1.0) rc = +1, t = 12.0; /* Sun always above altit */ else t = acosd (cost) / 15.0; /* The diurnal arc, hours */ } /* Store rise and set times - in hours UT */ *trise = tsouth - t; *tset = tsouth + t; return rc; } /* __sunriset__ */ /* The "workhorse" function */ double __daylen__ (int year, int month, int day, double lon, double lat, double altit, int upper_limb) /**********************************************************************/ /* Note: year,month,date = calendar date, 1801-2099 only. */ /* Eastern longitude positive, Western longitude negative */ /* Northern latitude positive, Southern latitude negative */ /* The longitude value is not critical. Set it to the correct */ /* longitude if you're picky, otherwise set to to, say, 0.0 */ /* The latitude however IS critical - be sure to get it correct */ /* altit = the altitude which the Sun should cross */ /* Set to -35/60 degrees for rise/set, -6 degrees */ /* for civil, -12 degrees for nautical and -18 */ /* degrees for astronomical twilight. */ /* upper_limb: non-zero -> upper limb, zero -> center */ /* Set to non-zero (e.g. 1) when computing day length */ /* and to zero when computing day+twilight length. */ /**********************************************************************/ { double d, /* Days since 2000 Jan 0.0 (negative before) */ obl_ecl, /* Obliquity (inclination) of Earth's axis */ sr, /* Solar distance, astronomical units */ slon, /* True solar longitude */ sin_sdecl, /* Sine of Sun's declination */ cos_sdecl, /* Cosine of Sun's declination */ sradius, /* Sun's apparent radius */ t; /* Diurnal arc */ /* Compute d of 12h local mean solar time */ d = days_since_2000_Jan_0 (year, month, day) + 0.5 - lon / 360.0; /* * Compute obliquity of ecliptic (inclination of Earth's axis) */ obl_ecl = 23.4393 - 3.563E-7 * d; /* Compute Sun's position */ sunpos (d, &slon, &sr); /* Compute sine and cosine of Sun's declination */ sin_sdecl = sind (obl_ecl) * sind (slon); cos_sdecl = sqrt (1.0 - sin_sdecl * sin_sdecl); /* Compute the Sun's apparent radius, degrees */ sradius = 0.2666 / sr; /* Do correction to upper limb, if necessary */ if (upper_limb) altit -= sradius; /* Compute the diurnal arc that the Sun traverses to reach */ /* the specified altitide altit: */ { double cost; cost = (sind (altit) - sind (lat) * sin_sdecl) / (cosd (lat) * cos_sdecl); if (cost >= 1.0) t = 0.0; /* Sun always below altit */ else if (cost <= -1.0) t = 24.0; /* Sun always above altit */ else t = (2.0 / 15.0) * acosd (cost); /* The diurnal arc, hours */ } return t; } /* __daylen__ */ /* This function computes the Sun's position at any instant */ void sunpos (double d, double *lon, double *r) /******************************************************/ /* Computes the Sun's ecliptic longitude and distance */ /* at an instant given in d, number of days since */ /* 2000 Jan 0.0. The Sun's ecliptic latitude is not */ /* computed, since it's always very near 0. */ /******************************************************/ { double M, /* Mean anomaly of the Sun */ w, /* Mean longitude of perihelion */ /* Note: Sun's mean longitude = M + w */ e, /* Eccentricity of Earth's orbit */ E, /* Eccentric anomaly */ x, y, /* x, y coordinates in orbit */ v; /* True anomaly */ /* Compute mean elements */ M = revolution (356.0470 + 0.9856002585 * d); w = 282.9404 + 4.70935E-5 * d; e = 0.016709 - 1.151E-9 * d; /* Compute true longitude and radius vector */ E = M + e * RADEG * sind (M) * (1.0 + e * cosd (M)); x = cosd (E) - e; y = sqrt (1.0 - e * e) * sind (E); *r = sqrt (x * x + y * y); /* Solar distance */ v = atan2d (y, x); /* True anomaly */ *lon = v + w; /* True solar longitude */ if (*lon >= 360.0) *lon -= 360.0; /* Make it 0..360 degrees */ } void sun_RA_dec (double d, double *RA, double *dec, double *r) { double lon, obl_ecl, x, y, z; /* Compute Sun's ecliptical coordinates */ sunpos (d, &lon, r); /* Compute ecliptic rectangular coordinates (z=0) */ x = *r * cosd (lon); y = *r * sind (lon); /* * Compute obliquity of ecliptic (inclination of Earth's axis) */ obl_ecl = 23.4393 - 3.563E-7 * d; /* * Convert to equatorial rectangular coordinates - x is uchanged */ z = y * sind (obl_ecl); y = y * cosd (obl_ecl); /* Convert to spherical coordinates */ *RA = atan2d (y, x); *dec = atan2d (z, sqrt (x * x + y * y)); } /* sun_RA_dec */ /******************************************************************/ /* This function reduces any angle to within the first revolution */ /* by subtracting or adding even multiples of 360.0 until the */ /* result is >= 0.0 and < 360.0 */ /******************************************************************/ #define INV360 ( 1.0 / 360.0 ) double revolution (double x) /*****************************************/ /* Reduce angle to within 0..360 degrees */ /*****************************************/ { return (x - 360.0 * floor (x * INV360)); } /* revolution */ double rev180 (double x) /*********************************************/ /* Reduce angle to within +180..+180 degrees */ /*********************************************/ { return (x - 360.0 * floor (x * INV360 + 0.5)); } /* revolution */ /*******************************************************************/ /* This function computes GMST0, the Greenwhich Mean Sidereal Time */ /* at 0h UT (i.e. the sidereal time at the Greenwhich meridian at */ /* 0h UT). GMST is then the sidereal time at Greenwich at any */ /* time of the day. I've generelized GMST0 as well, and define it */ /* as: GMST0 = GMST - UT -- this allows GMST0 to be computed at */ /* other times than 0h UT as well. While this sounds somewhat */ /* contradictory, it is very practical: instead of computing */ /* GMST like: */ /* */ /* GMST = (GMST0) + UT * (366.2422/365.2422) */ /* */ /* where (GMST0) is the GMST last time UT was 0 hours, one simply */ /* computes: */ /* */ /* GMST = GMST0 + UT */ /* */ /* where GMST0 is the GMST "at 0h UT" but at the current moment! */ /* Defined in this way, GMST0 will increase with about 4 min a */ /* day. It also happens that GMST0 (in degrees, 1 hr = 15 degr) */ /* is equal to the Sun's mean longitude plus/minus 180 degrees! */ /* (if we neglect aberration, which amounts to 20 seconds of arc */ /* or 1.33 seconds of time) */ /* */ /*******************************************************************/ double GMST0 (double d) { double sidtim0; /* Sidtime at 0h UT = L (Sun's mean longitude) + 180.0 degr */ /* L = M + w, as defined in sunpos(). Since I'm too lazy to */ /* add these numbers, I'll let the C compiler do it for me. */ /* Any decent C compiler will add the constants at compile */ /* time, imposing no runtime or code overhead. */ sidtim0 = revolution ((180.0 + 356.0470 + 282.9404) + (0.9856002585 + 4.70935E-5) * d); return sidtim0; } /* GMST0 */ From mike at sentex.net Fri Oct 10 00:36:27 2008 From: mike at sentex.net (Mike Tancsa) Date: Fri Oct 10 00:36:33 2008 Subject: Userland PPP not deleting old IP on disconnect In-Reply-To: <48EDF787.2010305@webzone.net.au> References: <200810092206.02362.doconnor@gsoft.com.au> <48EDF787.2010305@webzone.net.au> Message-ID: <200810100036.m9A0aMCi078828@lava.sentex.ca> At 08:22 AM 10/9/2008, Andrew D wrote: >Hi Fellow Node user :), > >I have the same + similar issue. Hi, What about adding disable iface-alias iface-alias Default: Enabled if -nat is specified. This option simply tells ppp to add new interface addresses to the interface rather than replacing them. The option can only be enabled if network address translation is enabled (``nat enable yes''). With this option enabled, ppp will pass traffic for old interface addresses through the NAT engine (see libalias(3)), resulting in the ability (in -auto mode) to properly connect the process that caused the PPP link to come up in the first place. Disabling NAT with ``nat enable no'' will also disable `iface-alias'. >Daniel O'Connor wrote: >>Hi, >>I am using userland PPP to do PPPoE and I am finding that it isn't >>deleting the old IP from tun0 when the link goes down, eg >>Oct 9 22:00:01 midget ppp[53728]: tun0: Phase: deflink: logout -> hangup >>Oct 9 22:00:01 midget ppp[53728]: tun0: Phase: deflink: Connect >>time: 950 secs: 2711068 octets in, 39993514 octets out >>[midget 22:00] ~ >ifconfig tun0 >>tun0: flags=8051 metric 0 mtu 1500 >> inet 121.45.251.180 --> 203.16.215.184 netmask 0xffffffff >> Opened by PID 53728 > >tun0: flags=8051 metric 0 mtu 1492 > inet 121.45.215.128 --> 203.16.215.183 netmask 0xffffffff > inet 121.45.69.26 --> 203.16.215.186 netmask 0xffffffff > Opened by PID 90863 > >The second line only shows up when the gateway is different between >IP assignments from the ISP. I have no idea if this blocks access to >the previous IP, not that it's a major issue. > >uname -a >FreeBSD gateway.abdulla 7.0-STABLE FreeBSD 7.0-STABLE #1: Sat Jun 21 >03:10:37 CST 2008 root@gateway.abdulla:/usr/obj/usr/src/sys/MYKERN i386 > >My ppp setup is almost the same. > >Cheers >cya >Andrew > >>I have the following config.. >>default: >> set device /dev/cuaa0 >> set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \"\" AT \ >> OK-AT-OK ATE1Q0 OK \\dATDT\\T TIMEOUT 40 CONNECT" >> set speed 115200 >> set ctsrts on >> set server /var/run/ppp/tun%d foobar >> set urgent tcp 22 >> set urgent udp 27010 27011 27012 27013 27014 27015 27016 27017 >> 27018 27019 27020 27960 14577 14578 14579 14580 >> set log Phase Chat IPCP CCP tun command connect >>internode: >> set device PPPoE:em0 >> set ifaddr 0.0.0.0/0 0.0.0.0/0 >> resolv readonly >> disable pap >> enable dns >> set cd 5 >> set dial >> set login >> set redial 5+30-120 0 >> enable lqr >> enable echo >> set lqrperiod 3 >> set reconnect 10 100000 >> set authname username >> set authkey password >> add default HISADDR >>I don't have any linkup/linkdown scripts.. >>Any one have an idea why this would be happening? >>System is a FreeBSD midget.dons.net.au 7.0-STABLE FreeBSD >>7.0-STABLE #1: Sun Jun 1 19:20:18 CST >>2008 darius@midget.dons.net.au:/data/obj/data/src/sys/GENERIC i386 >>Thanks. > >_______________________________________________ >freebsd-stable@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-stable >To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From doconnor at gsoft.com.au Fri Oct 10 00:55:26 2008 From: doconnor at gsoft.com.au (Daniel O'Connor) Date: Fri Oct 10 00:55:33 2008 Subject: Userland PPP not deleting old IP on disconnect In-Reply-To: <200810100036.m9A0aMCi078828@lava.sentex.ca> References: <200810092206.02362.doconnor@gsoft.com.au> <48EDF787.2010305@webzone.net.au> <200810100036.m9A0aMCi078828@lava.sentex.ca> Message-ID: <200810101125.21261.doconnor@gsoft.com.au> On Fri, 10 Oct 2008, Mike Tancsa wrote: > At 08:22 AM 10/9/2008, Andrew D wrote: > >Hi Fellow Node user :), > > > >I have the same + similar issue. > What about adding > > disable iface-alias > > iface-alias > Default: Enabled if -nat is specified. This option > simply tells ppp to add new interface addresses to the interface > rather than replacing them. The option can only be enabled if > network address translation is enabled (``nat enable yes''). I've added that and nat enable no (even though it was not enabled) and I'll see how I go. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20081010/3bca9aef/attachment.pgp From pyunyh at gmail.com Fri Oct 10 01:23:02 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Fri Oct 10 01:23:09 2008 Subject: can not wake on lan after halt -p (or shutdown -p now) on releng_7 and releng_7_0 In-Reply-To: <596673353.20081006181334@pulsar.bg> References: <596673353.20081006181334@pulsar.bg> Message-ID: <20081010012058.GA99376@cdnetworks.co.kr> On Mon, Oct 06, 2008 at 06:13:34PM +0300, Georgi Iovchev wrote: > Hello list > > I have a shutdown problem. I have a machine with gigabyte GA-G33M-DS2R > motherboard. Integrated network card is Realtek 8111B. > I can not wake the computer after I shutdown it from FreeBSD. > It is a dualboot system - windows xp and freebsd. If I shutdown the > computer from windows - later I can wake it up with magic packet. Even > if i shutdown the machine on the boot menu with the power button - than > later I can wake on lan. The only situation where I CANNOT wake it is > when I shutdown the machine from freebsd (halt -p). > > First I tested with 7.0-RELEASE-p5 amd64 (RELENG_7_0) and than I > upgraded to 7.1 PRERELASE amd64 (RELENG_7). I also tested with two > network cards - the integrated one Realtek 8111B and another one Intel > PRO1000PT PCI-E with WOL enabled. > Don't know WOL issue of em(4) but re(4) should respond to WOL. 7.0-RELEASE had no support for WOL so RELENG_7 or 7.1-PRERELEASE should be used to experiment WOL. > With both nics and both freebsd versions the situation is the same - > after shutdown from bsd the computer is not able to wake on lan. The Because you can wake up your sytem from Windows shutdown I think your BIOS is already configured to allow wakeup from WOL. Would you compare ethernet address of re(4) to Winwods? Have you tried to send Magic packets to FreeBSD box? You may also try suspend your box with acpiconf and resume from WOL. > indication on the switch port says that after shut down there is > active link. > That indicates the controller is alive so it shall respond to WOL if it was correctly configured to receive WOL packets. Have you tried to send Magic packets to FreeBSD box? > Here is some information after last update: > > [root@backup ~]# uname -a > FreeBSD backup.pulsar.bg 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #1: Mon Oct 6 17:01:26 EEST 2008 root@backup.pulsar.bg:/usr/obj/usr/src/sys/MYCONF amd64 > > [root@backup ~]# pciconf -lv > ... > re0@pci0:3:0:0: class=0x020000 card=0xe0001458 chip=0x816810ec rev=0x01 hdr=0x00 > vendor = 'Realtek Semiconductor' > device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC' > class = network > subclass = ethernet > ... Show me dmesg output pertinent to re(4). -- Regards, Pyun YongHyeon From zanchey at ucc.gu.uwa.edu.au Fri Oct 10 04:08:40 2008 From: zanchey at ucc.gu.uwa.edu.au (David Adam) Date: Fri Oct 10 04:08:48 2008 Subject: can not wake on lan after halt -p (or shutdown -p now) on releng_7 and releng_7_0 In-Reply-To: <596673353.20081006181334@pulsar.bg> References: <596673353.20081006181334@pulsar.bg> Message-ID: On Mon, 6 Oct 2008, Georgi Iovchev wrote: > I have a shutdown problem. I have a machine with gigabyte GA-G33M-DS2R > motherboard. Integrated network card is Realtek 8111B. > I can not wake the computer after I shutdown it from FreeBSD. > It is a dualboot system - windows xp and freebsd. If I shutdown the > computer from windows - later I can wake it up with magic packet. Even > if i shutdown the machine on the boot menu with the power button - than > later I can wake on lan. The only situation where I CANNOT wake it is > when I shutdown the machine from freebsd (halt -p). > > First I tested with 7.0-RELEASE-p5 amd64 (RELENG_7_0) and than I > upgraded to 7.1 PRERELASE amd64 (RELENG_7). I also tested with two > network cards - the integrated one Realtek 8111B and another one Intel > PRO1000PT PCI-E with WOL enabled. > > With both nics and both freebsd versions the situation is the same - > after shutdown from bsd the computer is not able to wake on lan. The > indication on the switch port says that after shut down there is > active link. I have a similar problem with an Intel SR1200 Pentium 3-class system, using fxp(4) cards, although I haven't yet tried the `halt -p` command. I was discussing WoL with a colleague recently and he suggested that on some Linux systems he needed to use `ethtool -s eth0 wol g` on every boot to maintain the WoL status. >From the ethtool(1) manpage: wol p|u|m|b|a|g|s|d... Set Wake-on-LAN options. Not all devices support this. g Wake on MagicPacket(tm) >From my reading, this might be necessary if the driver clears the flag during initialisation of the card. kern/83807 was filed to fix this issue for sis(4), but was never committed. However, work is apparently being done in 8-CURRENT to support exposing the WoL settings to ifconfig: see http://wiki.freebsd.org/WakeOnLan . Until that work lands in a release, I think we're out of luck. (Another administrator has also suggested that, on Linux at least, using the 'ifdown' command will destroy WoL status, but I don't think that's an issue here.) Hope that helps. I'm sure any contributions to the effort to add driver support will be appreciated. David Adam zanchey@ucc.gu.uwa.edu.au From koitsu at FreeBSD.org Fri Oct 10 04:26:44 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Fri Oct 10 04:26:51 2008 Subject: Problem with dump stalling In-Reply-To: References: <20081009153613.GB1262@in-addr.com> Message-ID: <20081010042637.GA22356@icarus.home.lan> On Fri, Oct 10, 2008 at 12:14:09AM +0200, David Peall wrote: > > -----Original Message----- > > From: owner-freebsd-stable@freebsd.org [mailto:owner-freebsd- > > stable@freebsd.org] On Behalf Of Gary Palmer > > Sent: 09 October 2008 05:36 PM > > To: David Peall > > Cc: freebsd-stable@freebsd.org; Jeremy Chadwick; Christoph Schug > > Subject: Re: Problem with dump stalling > > > > > > -----Original Message----- > > > > From: owner-freebsd-stable@freebsd.org [mailto:owner-freebsd- > > > > stable@freebsd.org] On Behalf Of Jeremy Chadwick > > > > Sent: 09 October 2008 12:45 PM > > > > To: Christoph Schug > > > > Cc: freebsd-stable@freebsd.org; David Peall > > > > Subject: Re: Problem with dump stalling > > > > > > > > David, can you verify you're using a version of > > > > src/sys/kern/subr_sleepqueue.c that is 1.39.2.3 or newer? > > > > > > > > If so, the problem David is experiencing is different. If not, > > > > David > > > > will need to csup and then rebuild world and kernel (do NOT just > do > > > > one; do both) to pick up the changes. > > > > > > > > Try running: > > > > ident /boot/kernel/kernel | grep subr_sleepqueue > > Thank you Gary: > $FreeBSD: src/sys/kern/subr_sleepqueue.c,v 1.39.4.1 2008/01/29 > 16:37:04 jhb Exp $ > > Which is indeed newer that 1.39.2.3 and dump on UFS2 is still a problem. Okay wait a minute here. We can't go purely off of the version number, because the version numbers differ per tag (HEAD/CURRENT, RELENG_7, RELENG_7_0, and so on). 1.39.2.3 was committed to RELENG_7 on 2008/04/19. The timestamp shown for you src/sys/kern/subr_sleepqueue.c is 2008/01/29. So I would say you **do not** have the fix. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From pyunyh at gmail.com Fri Oct 10 06:02:20 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Fri Oct 10 06:02:28 2008 Subject: can not wake on lan after halt -p (or shutdown -p now) on releng_7 and releng_7_0 In-Reply-To: References: <596673353.20081006181334@pulsar.bg> Message-ID: <20081010060013.GB99376@cdnetworks.co.kr> On Fri, Oct 10, 2008 at 11:41:59AM +0800, David Adam wrote: > On Mon, 6 Oct 2008, Georgi Iovchev wrote: > > I have a shutdown problem. I have a machine with gigabyte GA-G33M-DS2R > > motherboard. Integrated network card is Realtek 8111B. > > I can not wake the computer after I shutdown it from FreeBSD. > > It is a dualboot system - windows xp and freebsd. If I shutdown the > > computer from windows - later I can wake it up with magic packet. Even > > if i shutdown the machine on the boot menu with the power button - than > > later I can wake on lan. The only situation where I CANNOT wake it is > > when I shutdown the machine from freebsd (halt -p). > > > > First I tested with 7.0-RELEASE-p5 amd64 (RELENG_7_0) and than I > > upgraded to 7.1 PRERELASE amd64 (RELENG_7). I also tested with two > > network cards - the integrated one Realtek 8111B and another one Intel > > PRO1000PT PCI-E with WOL enabled. > > > > With both nics and both freebsd versions the situation is the same - > > after shutdown from bsd the computer is not able to wake on lan. The > > indication on the switch port says that after shut down there is > > active link. > > I have a similar problem with an Intel SR1200 Pentium 3-class system, > using fxp(4) cards, although I haven't yet tried the `halt -p` command. > fxp(4) should be taught to support WOL. Also note, not all fxp(4) hardwares support WOL. > I was discussing WoL with a colleague recently and he suggested that on > some Linux systems he needed to use `ethtool -s eth0 wol g` on every boot > to maintain the WoL status. > In FreeBSD this is controlled by ifconfig(8) and WOL implementation is up to driver writer. Some controllers require special configuration to make WOL work but I think re(4) should have no such issue as one of hardest part of WOL is handled by firmware on RealTek controllers(You don't need to reestablish a 10/100Mbps link). > >From the ethtool(1) manpage: > > wol p|u|m|b|a|g|s|d... > Set Wake-on-LAN options. Not all devices support this. > g Wake on MagicPacket(tm) > > >From my reading, this might be necessary if the driver clears the flag > during initialisation of the card. > > kern/83807 was filed to fix this issue for sis(4), but was never > committed. However, work is apparently being done in 8-CURRENT to support > exposing the WoL settings to ifconfig: see > http://wiki.freebsd.org/WakeOnLan . Until that work lands in a release, I > think we're out of luck. > If I had sis(4) hardware I would have written WOL support code. The patch in the PR needs minor modifications but it requires real hardware to test the WOL functionality. Maybe PR submitter can do that. > (Another administrator has also suggested that, on Linux at least, using > the 'ifdown' command will destroy WoL status, but I don't think that's an > issue here.) > > Hope that helps. I'm sure any contributions to the effort to add driver > support will be appreciated. > > David Adam > zanchey@ucc.gu.uwa.edu.au -- Regards, Pyun YongHyeon From david at esn.org.za Fri Oct 10 06:27:16 2008 From: david at esn.org.za (David Peall) Date: Fri Oct 10 06:27:24 2008 Subject: Problem with dump stalling In-Reply-To: <20081010042637.GA22356@icarus.home.lan> References: <20081009153613.GB1262@in-addr.com> <20081010042637.GA22356@icarus.home.lan> Message-ID: > -----Original Message----- > From: owner-freebsd-stable@freebsd.org [mailto:owner-freebsd- > stable@freebsd.org] On Behalf Of Jeremy Chadwick > Sent: 10 October 2008 06:27 AM > To: David Peall > Cc: freebsd-stable@freebsd.org > Subject: Re: Problem with dump stalling > > Okay wait a minute here. We can't go purely off of the version number, > because the version numbers differ per tag (HEAD/CURRENT, RELENG_7, > RELENG_7_0, and so on). > > 1.39.2.3 was committed to RELENG_7 on 2008/04/19. The timestamp > shown for you src/sys/kern/subr_sleepqueue.c is 2008/01/29. So I would > say you **do not** have the fix. > After rebuilding and installing both kernel and world # uname -a FreeBSD 7.0-RELEASE-p5 FreeBSD 7.0-RELEASE-p5 #0: Thu Oct 9 16:28:45 UTC 2008 david@:/usr/obj/usr/src/sys/GENERIC amd64 And: # ident /boot/kernel/kernel | grep subr_sleepqueue $FreeBSD: src/sys/kern/subr_sleepqueue.c,v 1.39.4.1 2008/01/29 16:37:04 jhb Exp $ So where is it getting that time stamp? More interestingly the dump still fails: # dump -a0Lf boot.dump /dev/mfid0s1a DUMP: Date of this level 0 dump: Fri Oct 10 08:24:05 2008 DUMP: Date of last level 0 dump: the epoch DUMP: Dumping snapshot of /dev/mfid0s1a (/bootdir) to boot.dump DUMP: mapping (Pass I) [regular files] DUMP: mapping (Pass II) [directories] DUMP: estimated 372176 tape blocks. DUMP: dumping (Pass III) [directories] DUMP: dumping (Pass IV) [regular files] # ps ax | grep dump 1110 p0 I+ 0:00.01 dump -a0Lf boot.dump /dev/mfid0s1a (dump) 1113 p0 I+ 0:00.01 dump: /dev/mfid0s1a: pass 4: 0.35% done, finished in 0:00 at Fri Oct 10 08:24:05 2008 (dump) 1114 p0 I+ 0:00.01 dump -a0Lf boot.dump /dev/mfid0s1a (dump) 1115 p0 I+ 0:00.01 dump -a0Lf boot.dump /dev/mfid0s1a (dump) 1116 p0 I+ 0:00.01 dump -a0Lf boot.dump /dev/mfid0s1a (dump) Regards -- David Peall :: IT Manager e-Schools' Network :: http://www.esn.org.za/ Phone +27 (021) 674-9140 From david at esn.org.za Fri Oct 10 06:36:03 2008 From: david at esn.org.za (David Peall) Date: Fri Oct 10 06:36:10 2008 Subject: Problem with dump stalling In-Reply-To: <20081010042637.GA22356@icarus.home.lan> References: <20081009153613.GB1262@in-addr.com> <20081010042637.GA22356@icarus.home.lan> Message-ID: After some digging it would appear the patch has not been committed ? From /src/sys/kern/subr_sleepqueue.c /* * Lock sleepq chain before unlocking proc * without this, we could lose a race. */ mtx_lock_spin(&sc->sc_lock); PROC_UNLOCK(p); thread_lock(td); if (ret == 0) { Should read /* + * Lock the per-process spinlock prior to dropping the PROC_LOCK + * to avoid a signal delivery race. PROC_LOCK, PROC_SLOCK, and + * thread_lock() are currently held in tdsignal(). */ + PROC_SLOCK(p); mtx_lock_spin(&sc->sc_lock); PROC_UNLOCK(p); thread_lock(td); + PROC_SUNLOCK(p); if (ret == 0) { Also : __FBSDID("$FreeBSD: src/sys/kern/subr_sleepqueue.c,v 1.39.4.1 2008/01/29 16:37:04 jhb Exp $"); Regards -- David Peall :: IT Manager e-Schools' Network :: http://www.esn.org.za/ Phone +27 (021) 674-9140 From koitsu at FreeBSD.org Fri Oct 10 07:03:30 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Fri Oct 10 07:03:37 2008 Subject: Problem with dump stalling In-Reply-To: References: <20081010042637.GA22356@icarus.home.lan> Message-ID: <20081010070327.GA25225@icarus.home.lan> On Fri, Oct 10, 2008 at 08:27:11AM +0200, David Peall wrote: > > -----Original Message----- > > From: owner-freebsd-stable@freebsd.org [mailto:owner-freebsd- > > stable@freebsd.org] On Behalf Of Jeremy Chadwick > > Sent: 10 October 2008 06:27 AM > > To: David Peall > > Cc: freebsd-stable@freebsd.org > > Subject: Re: Problem with dump stalling > > > > Okay wait a minute here. We can't go purely off of the version > number, > > because the version numbers differ per tag (HEAD/CURRENT, RELENG_7, > > RELENG_7_0, and so on). > > > > 1.39.2.3 was committed to RELENG_7 on 2008/04/19. The timestamp > > shown for you src/sys/kern/subr_sleepqueue.c is 2008/01/29. So I > would > > say you **do not** have the fix. > > > > After rebuilding and installing both kernel and world > # uname -a > FreeBSD 7.0-RELEASE-p5 FreeBSD 7.0-RELEASE-p5 #0: Thu Oct 9 16:28:45 > UTC 2008 david@:/usr/obj/usr/src/sys/GENERIC amd64 > > And: > # ident /boot/kernel/kernel | grep subr_sleepqueue > $FreeBSD: src/sys/kern/subr_sleepqueue.c,v 1.39.4.1 2008/01/29 > 16:37:04 jhb Exp $ > > So where is it getting that time stamp? >From the file: /usr/src/sys/kern/subr_sleepqueue.c You did not state what CVS tag you're using in your supfiles. I'm willing to bet you're using RELENG_7_0 and not RELENG_7. The fix was not committed to RELENG_7_0. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From bsam at ipt.ru Fri Oct 10 07:11:21 2008 From: bsam at ipt.ru (Boris Samorodov) Date: Fri Oct 10 07:11:29 2008 Subject: Problem with dump stalling In-Reply-To: (David Peall's message of "Fri\, 10 Oct 2008 08\:27\:11 +0200") References: <20081009153613.GB1262@in-addr.com> <20081010042637.GA22356@icarus.home.lan> Message-ID: <84641123@bs1.sp34.ru> "David Peall" writes: >> -----Original Message----- >> From: owner-freebsd-stable@freebsd.org [mailto:owner-freebsd- >> stable@freebsd.org] On Behalf Of Jeremy Chadwick >> Sent: 10 October 2008 06:27 AM >> To: David Peall >> Cc: freebsd-stable@freebsd.org >> Subject: Re: Problem with dump stalling >> >> Okay wait a minute here. We can't go purely off of the version > number, >> because the version numbers differ per tag (HEAD/CURRENT, RELENG_7, >> RELENG_7_0, and so on). >> >> 1.39.2.3 was committed to RELENG_7 on 2008/04/19. The timestamp >> shown for you src/sys/kern/subr_sleepqueue.c is 2008/01/29. So I > would >> say you **do not** have the fix. >> > > After rebuilding and installing both kernel and world You should update your sources with RELENG_7 tag... > # uname -a > FreeBSD 7.0-RELEASE-p5 FreeBSD 7.0-RELEASE-p5 #0: Thu Oct 9 16:28:45 ...and you'll get 7.1-PRERELEASE here. > UTC 2008 david@:/usr/obj/usr/src/sys/GENERIC amd64 WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD committer, http://www.FreeBSD.org The Power To Serve From david at esn.org.za Fri Oct 10 07:37:02 2008 From: david at esn.org.za (David Peall) Date: Fri Oct 10 07:37:09 2008 Subject: Problem with dump stalling In-Reply-To: <20081010070327.GA25225@icarus.home.lan> References: <20081010042637.GA22356@icarus.home.lan> <20081010070327.GA25225@icarus.home.lan> Message-ID: > >From the file: > > /usr/src/sys/kern/subr_sleepqueue.c > > You did not state what CVS tag you're using in your supfiles. I'm > willing to bet you're using RELENG_7_0 and not RELENG_7. The fix > was not committed to RELENG_7_0. > It was indeed have updated it to RELENG_7 building away again. -- David Peall :: IT Manager e-Schools' Network :: http://www.esn.org.za/ Phone +27 (021) 674-9140 From koitsu at FreeBSD.org Fri Oct 10 07:42:06 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Fri Oct 10 07:42:14 2008 Subject: Problem with dump stalling In-Reply-To: References: <20081010070327.GA25225@icarus.home.lan> Message-ID: <20081010074200.GA26124@icarus.home.lan> On Fri, Oct 10, 2008 at 09:36:55AM +0200, David Peall wrote: > > >From the file: > > > > /usr/src/sys/kern/subr_sleepqueue.c > > > > You did not state what CVS tag you're using in your supfiles. I'm > > willing to bet you're using RELENG_7_0 and not RELENG_7. The fix > > was not committed to RELENG_7_0. > > > > It was indeed have updated it to RELENG_7 building away again. Did you do the following before running csup on the supfile with the RELENG_7 tag? rm -fr /usr/src/* rm -fr /var/db/sup/src-all -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From geo at pulsar.bg Fri Oct 10 08:42:42 2008 From: geo at pulsar.bg (Georgi Iovchev) Date: Fri Oct 10 08:42:51 2008 Subject: can not wake on lan after halt -p (or shutdown -p now) on releng_7 and releng_7_0 In-Reply-To: <20081010012058.GA99376@cdnetworks.co.kr> References: <596673353.20081006181334@pulsar.bg> <20081010012058.GA99376@cdnetworks.co.kr> Message-ID: <1948191744.20081010114326@pulsar.bg> -- Friday, October 10, 2008, 4:20:58 AM: > On Mon, Oct 06, 2008 at 06:13:34PM +0300, Georgi Iovchev wrote: >> Hello list >> >> I have a shutdown problem. I have a machine with gigabyte GA-G33M-DS2R >> motherboard. Integrated network card is Realtek 8111B. >> I can not wake the computer after I shutdown it from FreeBSD. >> It is a dualboot system - windows xp and freebsd. If I shutdown the >> computer from windows - later I can wake it up with magic packet. Even >> if i shutdown the machine on the boot menu with the power button - than >> later I can wake on lan. The only situation where I CANNOT wake it is >> when I shutdown the machine from freebsd (halt -p). >> >> First I tested with 7.0-RELEASE-p5 amd64 (RELENG_7_0) and than I >> upgraded to 7.1 PRERELASE amd64 (RELENG_7). I also tested with two >> network cards - the integrated one Realtek 8111B and another one Intel >> PRO1000PT PCI-E with WOL enabled. >> > Don't know WOL issue of em(4) but re(4) should respond to WOL. > 7.0-RELEASE had no support for WOL so RELENG_7 or 7.1-PRERELEASE > should be used to experiment WOL. Now I am using 7.1-prerelase >> With both nics and both freebsd versions the situation is the same - >> after shutdown from bsd the computer is not able to wake on lan. The > Because you can wake up your sytem from Windows shutdown I think > your BIOS is already configured to allow wakeup from WOL. Would > you compare ethernet address of re(4) to Winwods? Have you tried to > send Magic packets to FreeBSD box? I have tried sending magic packets from another bsd machine. I am using net/wol. I also tried to send magic packets from windows machine using 3 different programs. > You may also try suspend your box with acpiconf and resume from WOL. I cant. [root@backup ~]# acpiconf -s 5 acpiconf: invalid sleep type (5) Actually I cant enter in any sleep state [root@backup ~]# acpiconf -s 4 acpiconf: request sleep type (4) failed: Operation not supported [root@backup ~]# acpiconf -s 3 acpiconf: request sleep type (3) failed: Operation not supported [root@backup ~]# acpiconf -s 2 acpiconf: request sleep type (2) failed: Operation not supported [root@backup ~]# acpiconf -s 1 acpiconf: request sleep type (1) failed: Operation not supported I am using generic kernel with little modifications, (generally i have commented many unused drivers - raid, if_....) Acpi is in generic kernel now. I even tried to wake the machine with magic packet after shutdown -h. But still no luck. >> indication on the switch port says that after shut down there is >> active link. >> > That indicates the controller is alive so it shall respond to WOL > if it was correctly configured to receive WOL packets. Have you > tried to send Magic packets to FreeBSD box? >> Here is some information after last update: >> >> [root@backup ~]# uname -a >> FreeBSD backup.pulsar.bg 7.1-PRERELEASE FreeBSD >> 7.1-PRERELEASE #1: Mon Oct 6 17:01:26 EEST 2008 >> root@backup.pulsar.bg:/usr/obj/usr/src/sys/MYCONF amd64 >> >> [root@backup ~]# pciconf -lv >> ... >> re0@pci0:3:0:0: class=0x020000 card=0xe0001458 >> chip=0x816810ec rev=0x01 hdr=0x00 >> vendor = 'Realtek Semiconductor' >> device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC' >> class = network >> subclass = ethernet >> ... > Show me dmesg output pertinent to re(4). re0: port 0xd000-0xd0ff mem 0xf2000000-0xf2000fff irq 17 at device 0.0 on pci3 re0: turning off MSI enable bit. re0: Chip rev. 0x38000000 re0: MAC rev. 0x00000000 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto re0: Ethernet address: 00:1f:d0:24:19:e9 re0: [FILTER] From david at esn.org.za Fri Oct 10 08:46:42 2008 From: david at esn.org.za (David Peall) Date: Fri Oct 10 08:46:52 2008 Subject: Problem with dump stalling [solved] In-Reply-To: <20081010074200.GA26124@icarus.home.lan> References: <20081010070327.GA25225@icarus.home.lan> <20081010074200.GA26124@icarus.home.lan> Message-ID: Thank you all The problem does not exist in RELENG_7, So it is safe to assume that FreeBSD 7.1 RELEASE will be a working. I see that its due out shortly. -- David Peall :: IT Manager e-Schools' Network :: http://www.esn.org.za/ Phone +27 (021) 674-9140 From petefrench at ticketswitch.com Fri Oct 10 10:06:05 2008 From: petefrench at ticketswitch.com (Pete French) Date: Fri Oct 10 10:06:12 2008 Subject: Problem with dump stalling In-Reply-To: <20081010074200.GA26124@icarus.home.lan> Message-ID: > Did you do the following before running csup on the supfile with > the RELENG_7 tag? > > rm -fr /usr/src/* > rm -fr /var/db/sup/src-all This is the second time I have seen this mentioned, but on none of the machines that I csup on do I haave a "/var/db/sup" at all. Is this a hangover from cvsup and not necessary for csup ? -pete. From gerrit at pmp.uni-hannover.de Fri Oct 10 10:22:22 2008 From: gerrit at pmp.uni-hannover.de (Gerrit =?ISO-8859-1?Q?K=FChn?=) Date: Fri Oct 10 10:22:29 2008 Subject: Regression 7.0R -> 7-stable? In-Reply-To: <200810071205.35961.jhb@freebsd.org> References: <20080807132947.061d24eb.gerrit@pmp.uni-hannover.de> <20081007142542.GA51071@icarus.home.lan> <20081007170742.75669f32.gerrit@pmp.uni-hannover.de> <200810071205.35961.jhb@freebsd.org> Message-ID: <20081010122205.edd1b2f5.gerrit@pmp.uni-hannover.de> On Tue, 7 Oct 2008 12:05:35 -0400 John Baldwin wrote about Re: Regression 7.0R -> 7-stable?: JB> > Ok, I added options KDB and DDB to my kernel configuration and JB> > compiled with SCHED_ULE. However, after hanging the system does not JB> > react on Ctrl-Alt-Esc. Am I missing something? JB> Can you add VERBOSE_SYSINIT to your kernel config and do a boot -v? Ok, I just did that. Now I get some more info after "SMP: AP CPU #2 Launched!" (omissions by me): cpu2 AP: [list with ID, lint0, timer etc. like f?r CPU0 and cpu1] done. 0x[omitted]... ioapic0: Assigning ISA IRQ 1 to local APIC 0 ioapic0: Assigning ISA IRQ 9 to local APIC1 ioapic0: Assigning ISA IRQ 11 to local APIC2 ioapic0: Assigning ISA IRQ 14 to local APIC0 ioapic0: Assigning ISA IRQ 15 to local APIC1 ioapic0: Assigning PCI IRQ 17 to local APIC2 ioapic0: Assigning PCI IRQ 18 to local APIC0 ioapic0: Assigning PCI IRQ 19 to local APIC1 ioapic0: Assigning PCI IRQ 20 to local APIC2 done. 0x[omitted]... done. 0x[omitted]... done. subsystem fffffff 0xffffffff804608c0(0)... x Where I put the "x" I see a grey inverted cursor and the system hangs. I cannot break into the debugger. JB> Also, are you able to log the output at all (such as via a serial JB> console)? Well, I need to get a serial cable, notebook and stuff for that. As I am on holiday for the next two weeks I will probably not find time to do that soonish. cu Gerrit From koitsu at FreeBSD.org Fri Oct 10 10:41:21 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Fri Oct 10 10:41:28 2008 Subject: Problem with dump stalling In-Reply-To: References: <20081010074200.GA26124@icarus.home.lan> Message-ID: <20081010104117.GA30217@icarus.home.lan> On Fri, Oct 10, 2008 at 11:06:04AM +0100, Pete French wrote: > > Did you do the following before running csup on the supfile with > > the RELENG_7 tag? > > > > rm -fr /usr/src/* > > rm -fr /var/db/sup/src-all > > This is the second time I have seen this mentioned, but on none > of the machines that I csup on do I haave a "/var/db/sup" at all. > Is this a hangover from cvsup and not necessary for csup ? No. cvsup (in the base system) stores in /usr/sup. Here, let me make an outline tree: csup (in base system): stores CVS data in /var/db/sup cvsup (in ports system): stores CVS data in /usr/sup csup (in ports): not sure where it stores the CVS data All of this assumes the user DOES NOT override the defaults. Further proof: $ which csup /usr/bin/csup $ ls -l /var/db/sup total 4 drwxr-xr-x 2 root wheel 512 2 Oct 01:38 ports-all/ drwxr-xr-x 2 root wheel 512 8 Oct 01:33 src-all/ -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From koitsu at FreeBSD.org Fri Oct 10 10:42:27 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Fri Oct 10 10:42:34 2008 Subject: Problem with dump stalling In-Reply-To: <20081010104117.GA30217@icarus.home.lan> References: <20081010074200.GA26124@icarus.home.lan> <20081010104117.GA30217@icarus.home.lan> Message-ID: <20081010104223.GA30297@icarus.home.lan> On Fri, Oct 10, 2008 at 03:41:17AM -0700, Jeremy Chadwick wrote: > On Fri, Oct 10, 2008 at 11:06:04AM +0100, Pete French wrote: > > > Did you do the following before running csup on the supfile with > > > the RELENG_7 tag? > > > > > > rm -fr /usr/src/* > > > rm -fr /var/db/sup/src-all > > > > This is the second time I have seen this mentioned, but on none > > of the machines that I csup on do I haave a "/var/db/sup" at all. > > Is this a hangover from cvsup and not necessary for csup ? > > No. cvsup (in the base system) stores in /usr/sup. Here, let me make ^^^^^^^^^^^^^^^^^^^^^^^^^^ This should have read: "in ports system" -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From bf2006a at yahoo.com Fri Oct 10 09:14:04 2008 From: bf2006a at yahoo.com (bf) Date: Fri Oct 10 11:19:55 2008 Subject: Recent Problems with RELENG_7 i386 In-Reply-To: Message-ID: <147365.67345.qm@web39101.mail.mud.yahoo.com> Yes, I disabled device polling on my NIC. It's in my kernel so that I can experiment with it. I use ipfw, but not dummynet. I find your numbers interesting, Ian. But how did you determine when a kern.hz setting was too high or too low -- and was this very sensitive to different workloads? I'd also like to learn more about this subject, and I'm hoping that some of the developers will take the time to include some discussion of this parameter in an updated and expanded tuning(7) manpage. Best wishes for some enjoyable holidays soon, b. --- On Thu, 10/9/08, Charles Sprickman wrote: > From: Charles Sprickman > Subject: Re: Recent Problems with RELENG_7 i386 > To: "Jeremy Chadwick" > Cc: "Ian Smith" , "bf" , freebsd-stable@freebsd.org > Date: Thursday, October 9, 2008, 2:13 PM > On Thu, 9 Oct 2008, Jeremy Chadwick wrote: > > > On Fri, Oct 10, 2008 at 03:51:02AM +1100, Ian Smith > wrote: > >> > Well, I believe HZ was increased from 100 to > 1000 long ago (RELENG_6?) > >> > as a default. I'm really not sure of the > implications of decreasing it, > >> > besides having less granularity for some > things (the only things I know > >> > of would be something pertaining to > firewalls, I just can't remember > >> > what. My brain is full. :-) ) > >> > >> You need a day off :) But yes, RELENG_5 still had > HZ=100 default, long > >> after the 'average' CPU clock frequency > was 10 or more times faster than > >> the 166MHz Pentiums and such (mostly then on only > 100Mbps ethernet) that > >> were comfortable at 100Hz slicing. 1000Hz was a > big shift to catch up. > >> > >> In a day or so playing around with it years ago, I > found 200-250Hz good > >> for 300MHz, 500Hz a bit much, 1000Hz way too busy, > and find my 1133MHz > >> P3-M happy enough at 1000Hz, though I've done > no specific tests on it. > >> > >> Some people had perhaps similar clock issues when > their fast processors > >> were throttling/stepping down to very low speeds > (100, even 75MHz) while > >> still slicing at 1000Hz, which I didn't find > too surprising. Limiting > >> minimum CPU freq to 300Mz or more seemed to solve > many such issues, but > >> I haven't your perseverance for digging up the > relevant threads .. > >> > >> Even in 5.5-S (/sys/conf/NOTES and > /sys/i386/conf/NOTES) HZ=1000 or 2000 > >> was suggested for DEVICE_POLLING (which bf > included in config, though > >> maybe it's not enabled?) and HZ=1000 or more > was recommended when using > >> DUMMYNET with ipfw - to provide smoother queue > dispatching, I gather. > >> > >> Bottom line, IMHO, bf should probably run the > default 1000Hz, 500 at > >> least, on an Athlon 900. With powerd, maybe set > min. freq >= 150MHz? > > > > Wow, this is fantastic information. You've just > educated me a great bit > > about the history and use of HZ. I've always had > a "general" idea of > > its importance and key role, but I was never fully > aware of the history. > > Not to pull this too much further OT, but in the original > message there > was a comment about HZ and context switching. I care for a > number of FBSD > boxes that are stuffed full of qmail processes. Context > switches are > always through the roof when the boxes are busy. My > layman's > understanding of "context switching" is very > vague - in short I assume > it's some type of overhead from the kernel having to > move between > servicing different processes. Altering HZ to > "tune" this is very > intriguing to me, so if anyone would like to explain, > I'm all ears. > > > P.S. -- I need more like 6 months off. I've never > taken an official > > (read: real) vacation my entire life. Maybe some day > I'll get to travel > > to Seoul and visit Pyun Yong-Hyeon and drink lots of > soju. :-) > > Join the f***ing club. I'm still waiting for my > honeymoon after two years > of being married. :) > > Charles > > > -- > > | Jeremy Chadwick jdc > at parodius.com | > > | Parodius Networking > http://www.parodius.com/ | > > | UNIX Systems Administrator Mountain > View, CA, USA | > > | Making life hard for others since 1977. > PGP: 4BD6C0CB | > > > > _______________________________________________ > > freebsd-stable@freebsd.org mailing list > > > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > > To unsubscribe, send any mail to > "freebsd-stable-unsubscribe@freebsd.org" > > From avg at icyb.net.ua Fri Oct 10 11:56:50 2008 From: avg at icyb.net.ua (Andriy Gapon) Date: Fri Oct 10 11:56:56 2008 Subject: 7.1 i386 PXE In-Reply-To: <200810092017.m99KHhdU022649@lurza.secnetix.de> References: <20081009180513.GA10705@icarus.home.lan> <200810092017.m99KHhdU022649@lurza.secnetix.de> Message-ID: <48EF42F9.7040409@icyb.net.ua> on 09/10/2008 23:17 Oliver Fromme said the following: > Jeremy Chadwick wrote: > > Dmitriy Kirhlarov wrote: > > > I tryin update my install server. Look like 7.1 i386 pxe boot broken. > > > My own release build is 7.1-i386-2008-10-05 > > > > > > Could somebody test this functionality and confirm or disprove my results. > > > > What's broken about it? What behaviour happens? Are you aware of the > > mfsroot bug (see step 7 below): > > > > http://jdc.parodius.com/freebsd/pxeboot_serial_install.html > > It is a problem with memory management in the boot loader. > I hit exactly the same problem during my experiments with > the graphical boot loader, even without PXE and mfsroot > involved. The problem is that the btx client breaks and > behaves erratically when it runs out of memory. By default > it can only use a part of the lower 640 KB of RAM, which > isn't very much, given that the loader binary itself is > already 250 KB, and the gzip decompressor requires quite > some temporary memory for its dictionary. > > Unfortunately, debugging these things in the boot loader > isn't exactly trivial. You can't just load it into gdb > and single step it. On a tangent - would running this under qemu with gdb stub enabled (qemu -s) and then connecting with remote gdb help? I am not sure about debugging symbols but raw assembly you should be able to track. -- Andriy Gapon From koitsu at FreeBSD.org Fri Oct 10 11:58:58 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Fri Oct 10 11:59:05 2008 Subject: Request for testing: ata(4) MFC In-Reply-To: <20081006051211.GA10542@icarus.home.lan> References: <676151223134689@webmail38.yandex.ru> <20081005004808.GA70137@icarus.home.lan> <48E99C18.6070602@yandex.ru> <20081006051211.GA10542@icarus.home.lan> Message-ID: <20081010115855.GA31707@icarus.home.lan> On Sun, Oct 05, 2008 at 10:12:11PM -0700, Jeremy Chadwick wrote: > On Mon, Oct 06, 2008 at 09:03:20AM +0400, Andrey V. Elsukov wrote: > > Jeremy Chadwick wrote: > >> Also, does your patch include any fixes (intentional or inadvertent) for > >> Intel MatrixRAID? This has been a sore spot for FreeBSD for quite > >> some time, and I'm curious to know if that has been fixed. > > > > There is only one fix for Intel Matrix RAID: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/121899 > > Ahh, yeah, I've seen that one as well. I'll apply the patch and let you > know if the behaviour documented in the PR happens. I'm sorry I haven't gotten around to testing this -- my day (night) job has kept me incredibly busy, and I've had hardly any time at home to work on personal projects. It sucks. I'll try to make time for testing either today or tomorrow. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From dudu at dudu.ro Fri Oct 10 12:40:28 2008 From: dudu at dudu.ro (Vlad GALU) Date: Fri Oct 10 12:40:44 2008 Subject: UDP LOR with the latest RELENG_7 Message-ID: As my kernel had started to lock up periodically and I don't have hands-on access to that machine, I enabled WITNESS. So these started to pop up: -- cut here -- --- syscall (97, FreeBSD ELF64, socket), rip = 0x80070427c, rsp = 0x7fffffffe8c8, rbp = 0x516348 --- uma_zalloc_arg: zone "16" with the following non-sleepable locks held: exclusive rw udp r = 0 (0xffffffff8064c928) locked @ /usr/src/sys/netinet/udp_usrreq.c:1125 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a witness_warn() at witness_warn+0x241 uma_zalloc_arg() at uma_zalloc_arg+0x290 malloc() at malloc+0x5c getenv() at getenv+0x93 getenv_quad() at getenv_quad+0x13 getenv_int() at getenv_int+0x15 udp_inpcb_init() at udp_inpcb_init+0x1f slab_zalloc() at slab_zalloc+0x1ad uma_zone_slab() at uma_zone_slab+0xb4 uma_zalloc_arg() at uma_zalloc_arg+0x31d in_pcballoc() at in_pcballoc+0x38 udp_attach() at udp_attach+0x57 socreate() at socreate+0x14f socket() at socket+0x8a syscall() at syscall+0x1a9 Xfast_syscall() at Xfast_syscall+0xab --- syscall (97, FreeBSD ELF64, socket), rip = 0x80070427c, rsp = 0x7fffffffe8c8, rbp = 0x516348 --- -- and here -- I tried to see whether bz@ had this one on his page, but his website is currently being migrated and the list of LORs was unavailable. Therefore, sorry if this mail is just noise... -- ~/.signature: no such file or directory From patfbsd at davenulle.org Fri Oct 10 12:56:06 2008 From: patfbsd at davenulle.org (Patrick =?ISO-8859-15?Q?Lamaizi=E8re?=) Date: Fri Oct 10 12:56:14 2008 Subject: 6.3-p5 watchdog timer not being disabled In-Reply-To: <48ED04DA.8050902@earthlink.net> References: <48ED04DA.8050902@earthlink.net> Message-ID: <20081010144035.01fc764a@baby-jane-lamaiziere-net.local> Le Wed, 08 Oct 2008 15:07:06 -0400, Stephen Clark a ?crit : > Hello List, > > We have 2 different platforms that we are trying to use the watchdog > timer and watchdogd program on. One is a Soekris 5501: > CPU: Geode(TM) Integrated Processor by AMD PCS (433.25-MHz 586-class > CPU) Origin = "AuthenticAMD" Id = 0x5a2 Stepping = 2 > Features=0x88a93d > AMD Features=0xc0400000 > The other is a: > CPU: VIA C3 Nehemiah+RNG (1002.28-MHz 686-class CPU) > Origin = "CentaurHauls" Id = 0x694 Stepping = 4 > Features=0x380b03d > > According to the manpage on watchdogd if is killed with either SIGTERM > or SIGINT it is suppose to disable the watchdog timer in the kernel so > the system won't reboot. > > On both of the above platforms this does not work and the platforms > reboot when watchdogd is killed with a kill pid, > after the timeout value (-t) that had been specified to watchdogd > when starting it has elapsed. > t > Am I misunderstanding how this is suppose to work? No, i have tested on my net5501 on freebsd-current. It works. Can you try with watchdog -d -t