date:20060106



On Jan 6, 2006, at 6:38 PM, Scott Mitchell wrote:

We'll only be mirroring the internal drives too for now - the 4e/DC  
seems

to be the only RAID option on the 1850 with battery-backed cache, and
doesn't cost much more for the extra peace-of-mind.


Then you'll be pleasantly surprised to know that the 4e/Si has a  
battery too.  I certainly was... and it even has 256MB of cache RAM.   
Quite the bargain!  I'll send you screen shots of the config menus in  
private email.



Unfortunately for me, the latest equipment I just got only takes low-
profile cards, and LSI doesn't offer a dual channel RAID card in low-
profile configuration... so I need to look at adaptec.


This is on your x4100?  Nice machine.  We have a v20z with dual  
Opteron
270s that I totally love.  Looking at getting an x4100 too... sadly  
these
are product development machines so they'll be running RedHat and  
Solaris.

Doesn't the x4100 have h/w RAID built in?  Or does that not work with
FreeBSD?


Yes, this is the X4100.  It only has room for two low-profile PCI-X  
cards, which the 320-2X certainly is not.  Curiously, LSI has on  
their web site some big announcements about some deals with Sun to  
use their products, so one would hope they would have a low-profile  
high-end card.  Currently they only have a low-end card that is low  
profile.


I'm biting the bullet and getting an Adaptec 2230 low profile card.   
I hope it is fast.  if not, then back to the drawing board... sigh.


___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: asr-util Not work after upgrade to 5.4

2006-01-06 Thread Jonathan Noack


Paul.LKW wrote:

As I upgraded to 5.4 I found the raid utilities 'asr-util' no longer work
for me.
I tried to deinstall and install again, but the problem still !
The error message in the console after the comman 'raidutil -L raid' is :
  Engine connect failed: COMPATILITY number

Any one know now to solve it.


Add 'options ASR_COMPAT' to your kernel config and compile a new kernel. 
 This is listed in /sys/i386/conf/NOTES but didn't make it into the 
release notes.


-Jonathan
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: [6.0] Snapshot removes acls flag from fs.

2006-01-06 Thread Václav Haisman



David Malone wrote:
> On Fri, Jan 06, 2006 at 10:50:57AM +0100, V??clav Haisman wrote:
> 
>>When I make snapshot of fs it removes "acls" flag from mount. While the
>>command is "mount -u -o snapshot etc." I don't think it should remove
>>the flag because it is not specified besides the snapshot option.
> 
> 
> You probably want something like:
> 
>   mount -u -o cur,snapshot ...
> 
> See the "current" and "fstab" options in the mount man page. An
> easier way to do this would be to use the mksnap_ffs command, which
> should preserve the old options.
> 
>   David.
Hmmm, I use the sysutils/snapshot port that allows to automates this
through periodic.conf... I guess I should rather complain to them then.

VH


signature.asc
Description: OpenPGP digital signature

Re: /boot/nextboot.conf not deactivated after one boot

2006-01-06 Thread Marius Nuennerich

On Fri, 6 Jan 2006 15:14:41 +
Ceri Davies <[EMAIL PROTECTED]> wrote:

> On Thu, Jan 05, 2006 at 01:41:33PM +0100, Marius Nuennerich wrote:
> > Hi folks,
> > 
> > it seems like /boot/nextboot.conf is neither deleted nor
> > nextboot_enable set to NO on the first line after a reboot.
> > So it isn't a one shot anymore as the manpage claims.
> > 
> > System is 6.0-RELEASE.
> 
> I think this is down to a typo in /etc/rc.d/root; at least I can't find
> any other reference to /boot/nextkernel in src/.  Patch attached
> (root.diff).
> 
> > It would also be fine imo, if the -k option would be optional and the
> > next kernel defaults to "kernel".
> 
> I'm not sure if getopts can be persuaded to take an optional argument to
> an option.  If not, the attached patch (nextboot.diff) should work for
> you.

I tested both patches and they work as they should. Please commit :)

Thanks
Marius
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: 6.0 on Dell 1850 with DRAC4 management card?

On Fri, Jan 06, 2006 at 05:22:04PM +0100, Marian Hettwer wrote:
> 
> Vivek Khera wrote:
> > 
> > On Jan 6, 2006, at 9:47 AM, Marian Hettwer wrote:
> > 
> >> I don't know about the DRAC with FreeBSD, but I assume that the  BIOS of
> >> this Dell still supports BIOS redirection to serial port. If so,  you can
> >> have Monitor and Keyboard connected locally and use the serial console
> >> remote.
> >> Just get a small console server (depending on the amount of servers  you
> >> have remote), for instance an old cyclades TS. Connect them and you  can
> >> get on your serial port through the console server via ssh.

Thanks all for the replies - this is good stuff.

I have been thinking about something like that - we have a bunch of old Sun
boxes with their serial ports chained together for console access, would be
nice to have that done properly.  On the other hand the Windows guys seem
to really like the DRAC cards on the Dells they look after.

> > I've never enabled the DRAC card on any dell I have that came with  them...
> >
> I'd rather stick with a good old console which I can access remotely via
> ssh, too.

I agree that is the best way.  Sun have got this right on their Opteron
servers: Ethernet port for the management board, ssh access into that then
just start a console session.

Cheers,

Scott

-- 
===
Scott Mitchell   | PGP Key ID | "Eagles may soar, but weasels
Cambridge, England   | 0x54B171B9 |  don't get sucked into jet engines"
scott at fishballoon.org | 0xAA775B8B |  -- Anon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: 6.0 on Dell 1850 with PERC4e/DC RAID?

On Fri, Jan 06, 2006 at 10:35:46AM -0500, Vivek Khera wrote:
> 
> On Jan 5, 2006, at 5:41 PM, Scott Mitchell wrote:
> 
> >I may be getting a new Dell PE1850 soon, to replace our ancient CVS  
> >server
> >(still running 4-STABLE).  The new machine will ideally run 6.0 and  
> >have a
> >PERC4e/DC RAID card - the one with battery-backed cache.  This is  
> >listed as
> 
> I have an 1850 with the buil-in PERC 4e/Si since all I needed was the  
> RAID1 mirror of the internal drives.  It works extremely well, and  
> the speed is quite good.

We'll only be mirroring the internal drives too for now - the 4e/DC seems
to be the only RAID option on the 1850 with battery-backed cache, and
doesn't cost much more for the extra peace-of-mind.

> As for notices of when the drives go bad, under 4.x I've had disk  
> failures with the amr driver (different PERC cards) and not gotten  
> any such notices in the syslog that I recall.

That's a pity.  Maybe Doug was thinking of one of the aac(4) based PERC
cards?  Still, something I can run out of cron to check the array status
should be fine.

> I did find a program   
> posted to one of the freebsd lists called 'amrstat' that I run  
> nightly.  It produces this kind of output:
> 
> Drive 0:68.24 GB, RAID1  io> optimal
> 
> If it says "degraded" it is time to fix a drive.   You just fire up  
> the lsi megaraid tools and find out which drive it is.
> 
> If you go to the LSI download area, they have one file for FreeBSD,  
> which is labeled the driver.  In that zip file is also the management  
> software for freebsd.  You'll want that.  Personally, I like the  
> "MEGAMGR" software which was released for freebsd 4.x and mimics the  
> BIOS' interface in a terminal window.

There's a port of the management software now: sysutils/megarc

> The rebuild on LSI controllers is set to automatic on the dells as  
> default.  It just works as expected.

Cool.

> Overall, I'm a big fan of the LSI cards and the amr driver...
> 
> Unfortunately for me, the latest equipment I just got only takes low- 
> profile cards, and LSI doesn't offer a dual channel RAID card in low- 
> profile configuration... so I need to look at adaptec.

This is on your x4100?  Nice machine.  We have a v20z with dual Opteron
270s that I totally love.  Looking at getting an x4100 too... sadly these
are product development machines so they'll be running RedHat and Solaris.
Doesn't the x4100 have h/w RAID built in?  Or does that not work with
FreeBSD?

Scott

-- 
===
Scott Mitchell   | PGP Key ID | "Eagles may soar, but weasels
Cambridge, England   | 0x54B171B9 |  don't get sucked into jet engines"
scott at fishballoon.org | 0xAA775B8B |  -- Anon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Motherboard

2006-01-06 Thread Martin Cracauer

Øystein Holmen wrote on Fri, Jan 06, 2006 at 11:03:18PM +0100: 
> Hi all!
> 
> I'm setting up a new server with FreeBSD 6.0. The motherboard I am  
> planning to use is Asus A8N-SLI Premium. Does anyone know if the on- 
> board ethernet controller (nve(4)) works?

Works for me with the newest 7-current commits, but losing carrier
means temporary machine hang.  The other GbE on the board works, too.

Temperature monitoring is also functional.

Be warned that this board even with the newest BIOS does not correctly
do remapping of the physical memory between 3-4 GB to above 4 GB.

> Also I'm planning on getting this graphics controller: Gainward  
> GeForce 6200 TurboCache, PCI-Express.

Works for me, "nv" driver.  No "nvidia" driver for FreeBSD/AMD64.

Martin
-- 
%%%
Martin Cracauerhttp://www.cons.org/cracauer/
FreeBSD - where you want to go, today.  http://www.freebsd.org/
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Motherboard

2006-01-06 Thread Øystein Holmen


Hi all!

I'm setting up a new server with FreeBSD 6.0. The motherboard I am  
planning to use is Asus A8N-SLI Premium. Does anyone know if the on- 
board ethernet controller (nve(4)) works?


Also I'm planning on getting this graphics controller: Gainward  
GeForce 6200 TurboCache, PCI-Express.


Sincerely,
Øystein Holmen___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Fast releases demand binary updates.. (Was: Release schedule for 2006)

2006-01-06 Thread John-Mark Gurney

Jo Rhett wrote this message on Fri, Jan 06, 2006 at 03:03 -0800:
> On Thu, Jan 05, 2006 at 10:41:47AM -0800, John-Mark Gurney wrote:
> > I believe core has a policy of never supporting vaporware...  There is
> > always the chicken and egg problem with arguments like this...  I'll
> > code this if you agree to support it and maintain it/I will agree to
> > support it once you code it...   In FreeBSD, and many open source
> > projects, no code, no support, how can you support or even agree to
> > support something that doesn't exist?  And then as soon as FreeBSD
> > agrees to support something that doesn't exist, either a) other people who
> > were interested in the project stop, even if you end up never producing
> > a bit of code, or b) someone else produces better code, drops the
> > support for the original, but then the author complains about being
> > told they'd support his code, and going with another code base...
> > 
> > Bottom line:  Once code exists, then support can be talked about..
>  
> This is the chicken and egg problem that will kill FreeBSD.   I don't

And many other open source software projects...  FreeBSD isn't unique
in this.. I've submitted patches to many other projects just to have
them ignored for years too...  It's a problem of voluteer orginizations..

> bother writing up patches for FreeBSD because every time I do they sit in a
> PR and get ignored for several years.  Then someone that does have commit
> rights makes their own patch (which often is less useful) but they own it
> and the best I've ever succeeded at was convincing them to put some of the
> ideas from my patch into their code.
> 
> Note that none of these patches were ever rejected for any technical or
> political or any other reason.  They just don't get paid attention to.
> 
> Thus, I try to get consensus that the idea has merit.  IF freebsd
> committers can be bothered to pay attention to the idea, I'll write code
> for it.  But I'm too old and tired to spend another week writing up
> something that will get ignored for X years and then dropped for obsoletion
> again.

You're trying to target to large of an audience...  You need to get _A_
committer interested in your work, and get HIM to guide you and commit
your work...

> AND there are a lot of opinions and politics around how to version the core
> that have nothing to do with code.  There's no value in writing code that
> will be ignored because it doesn't agree with -core's view of "should be".
> I'm a coder, not a politician.  If we can get consensus on what type of
> implementation would be acceptable to core, then I and many others would be
> happy to write code to implement this idea.  But this is a considerable
> amount of work that will be closely tied to the operation system
> installation.  It's not something that you can churn out 7 different
> implementations of just to see which one fits the current polical
> environment. 

stop talking about core...  -core makes absolutely no technical decisions
about how FreeBSD is..  it is the developers, and previously there was
a technical review board for settling differences between developers
that were pure "technical" in nature...  And if you claim you didn't
know this, then you better read the email you respond to more closely,
since this has been pointed out to you numerous times..

and you said in another email:
> First, this is obvious and true for all open source projects.  But no,
> FreeBSD _never_ advances because someone writes code that does something
> well.  FreeBSD _only_ advances when the core developers agree that this
> thing is worthy of their interest.

hmmm...  you really are choosing to completely ignore what people have
said about core, that at least you did add developers after core, which
makes it appear less likely that you're talking about -core.. but lots
of stuff gets done w/o core developers... I did lots of work on -sparc64,
and I'm pretty sure you wouldn't call me a core developer..  and I also
got TS-7200 arm support (though it hasn't been committed to cvs due to
issues that I haven't resolved with device configuration)...

As for the whole installation thing, you need to talk with re (release
engineering) as they are the ones to really have final say in what
installation and releases look like...

> Back to your finale:
> 
> > Bottom line:  Once code exists, then support can be talked about..
> 
> This is bullhockey and you know it.  Once the project is done, we'll
> authorize a budget for it?  Once the season is over we'll know who should

FreeBSD isn't commercial, so you can't talk about budgets...  And most
orgs want some sort of prototypes and feasibility study done before
they'll commit any budget to it...

> be on the starting team?  Yeah, hindsight is sweet.  But this isn't a
> simple change.  It will require very close integration with the installation
> and kernel modules at least (and probably more).  So having some sort of
> consensus that (a) the project has in

Re: FreeBSD Update is the binary update solution [Re: HEADS UP: Release schedule for 2006]

2006-01-06 Thread Peter Jeremy

On Fri, 2006-Jan-06 02:34:40 -0800, Jo Rhett wrote:
>On Thu, Jan 05, 2006 at 10:47:38AM +0100, Patrick M. Hausen wrote:
>> While I agree with much of your reasoning, I know exactly zero
>> people running a modified kernel of any version of Windows,
>> Mac OS X or Solaris, to name just three commercial OS's.
> 
>You're tickling a different subject here.  All three of these operating
>systems have loadable kernel modules that work.

As does FreeBSD.

>  I mean, they dynamically
>load the modules they need, and you can disable kernel modules in
>configuration files.  FreeBSD has loadable kernel modules, but they don't
>autoload (you have to modify rc files)

This isn't quite true.  FreeBSD does not currently have the tools to
automatically load kernel modules for most hardware device drivers and
they need to either be built into the kernel or specified in
loader.conf.  Writing a tool to do this automatically would be fairly
simple - either use pciconf(8) and a database of PCI ID to driver
mappings or (as Solaris and X do) load every module and see if it can
attach to anything, unload it if it can't.  To date, no-one has been
sufficiently motivated to do so.

FreeBSD will autoload kernel modules for many software functions if
their functionality is required (NFS, SysV IPC, firewalls).  In some
cases this is automatic (NFS client loads automatically if NFS
filesystems are found).  In other cases, (eg firewalls) you need to
configure the functionality anyway.

> and you can't trim down the kernel
>to minimize unused memory without recompiling.

In the absence of tools to automatically detect your configuration and
load the appropriate modules, GENERIC includes a fairly standard set
of drivers that also exist as modules.  GENERIC probably could be cut
down somewhat but this isn't the forum to discuss that.

>To give you a specific example: if we could remove NFS and the 3ware
>driver from the kernel in a configuration file, we could probably run
>GENERIC.

IMHO, NFS server could be removed without problems (it will autoload),
as could tw{a,e} (which are loadable).  NFS client can't be removed
because it has to be built in to support diskless operation.

>hog we have to remove on small footprint systems

FreeBSD has never claimed to optimally support small footprint systems
without customisation.  There are too many variables and some kernel
functionality can't be readily converted to modules (eg IPv6 support).
In any case, the way to minimise the kernel footprint is to statically
load all the required functionality and not have any modules.

-- 
Peter Jeremy
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Fast releases demand binary updates.. (Was: Release schedule for 2006)

2006-01-06 Thread Peter Jeremy

On Fri, 2006-Jan-06 03:03:18 -0800, Jo Rhett wrote:
>> Bottom line:  Once code exists, then support can be talked about..
>
>This is bullhockey and you know it.  Once the project is done, we'll
>authorize a budget for it?  Once the season is over we'll know who should
>be on the starting team?

In general, volunteer projects have a surfeit of ideas and a shortage
of real implementations.  The Project is never going to agree to import
an idea without some substance.

>  Yeah, hindsight is sweet.  But this isn't a
>simple change.  It will require very close integration with the installation
>and kernel modules at least (and probably more).  So having some sort of
>consensus that (a) the project has interest and (b) what flavors would be
>acceptable to the existing groups - are both necessary for this project to
>even mumble it's first line of code.

In which case you need to move this thread to freebsd-arch where these
sort of issues are discussed.  You need to clearly define your goals
and suggest a design to meet them.  If your idea has merit, you'll be
able to convince at least one committer to work with you to implement
your design.

-- 
Peter Jeremy
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ucom.ko and palm pilot m500

2006-01-06 Thread Anish Mistry

On Friday 06 January 2006 01:56 pm, Carsten Wald wrote:
> On Friday 06 January 2006 17:51, Gleb Kozyrev wrote:
> > man uvisor
>
> Great!  Thank you.  That's what I needed! -- uvisor.ko apparently
> uses ucom.ko and the ucom0 device I looked for is (temporarily)
> created.  However, after pressing the sync button the pilot can
> then be accessed through the /dev/ttyU0 device.
>
> Since I didn't find this information at kpilot.org or
> pilot-link.org or whatsoever (although they oftern refer to
> FreeBSD) and somebody else might have the same problem ... here is
> what I did:
>
> 1. Load the proper kernel modules.  Among others this is uvisor.ko.
>
>   $ kldload /boot/kernel/uvisor.ko
>
>(In addition, I configured this in /boot/loader.conf)
>
> 2. Configure /etc/usbd.conf in such a way, that the permissions of
> the proper device will be set when it appears after pressing the
> HotSync button.  This is /dev/ttyU0 in my case.
>
> I just synced as a normal user and it works.
You shouldn't be using usbd/usbd.conf as it is going away (It's 
already gone in CURRENT).  You should configure it using 
devd/devd.conf instead.


-- 
Anish Mistry


pgpakgSIHZSNx.pgp
Description: PGP signature

asr-util Not work after upgrade to 5.4

2006-01-06 Thread Paul.LKW

Dear all:
As I upgraded to 5.4 I found the raid utilities 'asr-util' no longer work
for me.
I tried to deinstall and install again, but the problem still !
The error message in the console after the comman 'raidutil -L raid' is :
  Engine connect failed: COMPATILITY number

Any one know now to solve it.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

6.0 hangs at boot on Toshiba laptop

2006-01-06 Thread Olivier Boudeville

Hi everybody,

I tried to install on my laptop (Toshiba M60-176) FreeBSD 6.0 STABLE and
it failed despite careful installation and web/archives search. It is a
multiboot installation (Windows XP/Linux Ubuntu/FreeBSD) driven by GRUB
4.95.

After the whole installation process ended, the reboot is performed and
the bootstrap goes until the FreeBSD menu is displayed. Whatever the
chosen option (default, without ACPI, fail-safe, verbose, etc.) the
system hangs immediately. For example with the first choice, we have :
/boot/kernel/acpi.ko/boot/kernel/acpi.ko text=0x40c2c data=0x2160+0x1090
[..] and everything stops. The situation is explained very clearly here
: http://marc.theaimsgroup.com/?l=freebsd-mobile&m=113177565322135&w=2

I do not think it is related to GRUB (the real boot has started, this
version allows for UFS2 access, various GRUB settings have been tried,
unsucessfully) nor to ACPI since even when disabled, thanks to the
relevant menu option, the boot hangs as well (same behaviour, without
the ACPI module line being displayed). I cannot disable Legacy USB in my
BIOS, if ever it was a common workaround.

If it can help, I detailed my full installation process here :
http://osdl.sourceforge.net/OSDL/OSDL-0.3/src/doc/web/main/documentation/misc/Toshiba.html#freebsd
(by the way, there seems to be a bug when aborting/restarting under
sysinstall : apparently in some cases it tries to install FreeBSD on the
ramdisk instead of the requested slice).

Thanks in advance for any hint,
kind regards,

Olivier.

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ucom.ko and palm pilot m500

2006-01-06 Thread Carsten Wald

On Friday 06 January 2006 17:51, Gleb Kozyrev wrote:

> man uvisor

Great!  Thank you.  That's what I needed! -- uvisor.ko apparently uses ucom.ko 
and the ucom0 device I looked for is (temporarily) created.  However, after 
pressing the sync button the pilot can then be accessed through 
the /dev/ttyU0 device. 

Since I didn't find this information at kpilot.org or pilot-link.org or 
whatsoever (although they oftern refer to FreeBSD) and somebody else might 
have the same problem ... here is what I did:

1. Load the proper kernel modules.  Among others this is uvisor.ko.

$ kldload /boot/kernel/uvisor.ko

   (In addition, I configured this in /boot/loader.conf)

2. Configure /etc/usbd.conf in such a way, that the permissions of the proper 
device will be set when it appears after pressing the HotSync button.  This 
is /dev/ttyU0 in my case.

I just synced as a normal user and it works.

-- 
bye
  Carsten




___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: 6.0 on Dell 1850 with PERC4e/DC RAID?



On Jan 5, 2006, at 9:21 PM, Michael Vince wrote:

 Items 3 and 4 significantly increase the performance of the  
driver.  On an
 LSI 320-2X card, transactions per second went from 13,000 to  
31,000 in my

 testing with these changes.  However, these changes are still fairly
 experimental and shouldn't be merged to 6.x until there is more  
testing.
  Thanks to Doug Ambrosko, LSI, Dell, and Yahoo for contributing  
towards

 this.


Damn that's awesome!  Thanks to all who helped with this...  This  
will be great for some of my servers.


Now, does anyone have any numbers to compare this with other RAID  
cards?  Particularly the 2230SLP? :-)


/me wishes LSI maid low profile dual channel cards...

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: SCSI RAID card recommendation (1/2 height PCI-X U320 SCSI dual channel)

2006-01-06 Thread Chuck Swiger


Vivek Khera wrote:

On Jan 5, 2006, at 11:08 PM, Chuck Swiger wrote:
There's an interesting thread about the AMR RAID controller used in  
the newer 18x0/28x0 Dells with the PERC/4 controller, and I know of  
enough people using them that such improvements (by Doug Ambrisko?)  
will be welcomed.


Thanks for your note.  Turns out I have more than one Dell system with 
aac controllers in them :-)


They seem to be OK, although I like the AMR's a little better.  I had to update 
the RAID BIOS on the PE 2650 before auto-rebuild of a broken mirror would work 
right using the aac controller.


(It's either rackrounted Dells or HP 370/380 Proliants for me, depending upon 
the specific client in question.)


One happens to be a PE 1750 with the PERC 3/Di in it running RAID1.   It 
is lightly loaded but is sufficient for that server's needs, but  is 
running FreeBSD 4.11 on it.


Is there a way to backport this diskinfo utility to 4.x or 5.x?   Looks 
most useful!  On my 6.0 box with a PERC 3/Si card (aac driver  too) it 
is showing seek times slower than yours but transfer rates  faster.


diskinfo runs on 5.x, at least.  I'm not sure about 4.x; I think some of the 
underlying infrastructure which smarttools also depends upon wasn't available 
until 5.x...


--
-Chuck
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ucom.ko and palm pilot m500

2006-01-06 Thread Gleb Kozyrev

Carsten "CC" Wald wrote to  on Fri, 6 Jan 2006 
16:43:15 +:

CCW> I own an old palm pilot -- a m500 model -- and have the following
CCW> problem when I try to sync under 6-STABLE.

CCW> Whenever I pressed the HotSync-Button of that device -- connected to my
CCW> 6-STABLE box via a USB cable, the pilot was recognized as a ugen0
CCW> device.  

man uvisor

-- 
With best regards, Gleb Kozyrev. 
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: 6.0 on Dell 1850 with DRAC4 management card?

2006-01-06 Thread David Sze

On Fri, Jan 06, 2006 at 05:32:54PM +0100, Marian Hettwer wrote:
> 
> The only thing missing would be hardware power down. if that can be done
> via DRAC, that'll be an advantage :)

One big advantage of the DRAC is virtual media (floppy, CD) support.
Good for BIOS/firmware upgrades, booting a rescue/repair CD, or even
reinstalling the OS.

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Swapfile problem in 6?

2006-01-06 Thread Don Lewis

On  2 Jan, Lars Kristiansen wrote:
>> Attempting to catch up with my backlog of unread email, only 12K unread
>> messages to go ...
>>
>> On 24 Nov, Rob wrote:
>>
>>> I have cvsup'ed the sources to STABLE as of Nov. 23rd
>>> 2005.
>>> After recompiling/installing world and debug-kernel,
>>> I again get a kernel deadlock when using swapfile:
>>>http://surfion.snu.ac.kr/~lahaye/swapfile2.txt
>>>
>>> Previous deadlocks are still documented here
>>>http://surfion.snu.ac.kr/~lahaye/swapfile.txt
>>>
>>> I hope this is of use for fixing this bug in 6.
>>> If further investigation is needed, then please let me
>>> know.
>>
>> This is a deadlock caused by memory exhaustion.  The pagedaemon only has
>> a limited number of bufs that it uses for writing dirty pages to swap to
>> prevent it from saturating the I/O subsystem with large numbers of
>> writes.  In this case, pagedaemon is trying to free up memory by writing
>> dirty pages, and it has used up all of its bufs and is waiting for the
>> write requests to complete and the bufs the bufs to be returned to it.
>> This isn't happening because md0 is stuck waiting for memory.  This is a
>> little bit suprising to me because it looks like writes to vnode backed
>> devices are done synchronously by default.
>>
>> If you have a chance to test this again, a stack trace of md0 in the
>> deadlock state would be interesting.  I'd like to know where md0 is
>> getting stuck.
>>
>> I wonder if pagedaemon should scan ahead and more agressively discard
>> clean pages when it has run out of bufs to write dirty pages, especially
>> in low memory situations.  Preventing the creation of more dirty pages
>> would be nice, but I don't know how to do that ...
> 
> Just in case it can help. Do not have this machine available for testing
> at the moment but this is the last debuginfo I did get from it.
> Here is a trace from a situation when a possible idle system got stuck
> during the night and db showed only one locked vnode:
> 
> db> show lockedvnods
> Locked vnodes
> 
> 0xc1309330: tag ufs, type VREG
> usecount 1, writecount 1, refcount 154 mountedhere 0
> flags ()
> v_object 0xc12cb39c ref 0 pages 606
>  lock type ufs: EXCL (count 1) by thread 0xc126b900 (pid 178)
> ino 8155, on dev ad0s1f
> db> trace 178
> Tracing pid 178 tid 100058 td 0xc126b900
> sched_switch(c126b900,0,1) at 0xc066a4db = sched_switch+0x17b
> mi_switch(1,0) at 0xc065f49e = mi_switch+0x27e
> sleepq_switch(c09b2a98,c484bacc,c065f0e3,c09b2a98,0) at 0xc0677f00 =
> sleepq_switch+0xe0
> sleepq_wait(c09b2a98,0,0,c08ad92d,37b) at 0xc0678100 = sleepq_wait+0x30
> msleep(c09b2a98,c09b2d00,244,c08adb6a,0) at 0xc065f0e3 = msleep+0x333
> vm_wait(c12cb39c,0,c08990f3,ad7,c06512a4) at 0xc07c6a71 = vm_wait+0x91
> allocbuf(c28fa9d8,4000,354000,0,354000) at 0xc06a2f89 = allocbuf+0x4e9
> getblk(c1309330,d5,0,4000,0) at 0xc06a29cb = getblk+0x4eb
> cluster_read(c1309330,1000,0,d5,0) at 0xc06a5d65 = cluster_read+0xe5
> ffs_read(c484bc9c) at 0xc07a631f = ffs_read+0x28f
> VOP_READ_APV(c09309a0,c484bc9c) at 0xc0838aab = VOP_READ_APV+0x7b
> mdstart_vnode(c1310800,c1634294,c1310820,1,c0566e10) at 0xc056688c =
> mdstart_vnode+0xec
> md_kthread(c1310800,c484bd38,c1310800,c0566e10,0) at 0xc0566f7f =
> md_kthread+0x16f
> fork_exit(c0566e10,c1310800,c484bd38) at 0xc0645618 = fork_exit+0xa8
> fork_trampoline() at 0xc0816f3c = fork_trampoline+0x8
> --- trap 0x1, eip = 0, esp = 0xc484bd6c, ebp = 0 ---

The md thread is stuck waiting for memory to be freed by pagedaemon.
Pagedaemon is stuck waiting for at least one of its pageout requests to
complete.  The pageout requests are probably all stuck waiting for md.

I had expected that the problem is that while pagedaemon is allowed to
dig deeper into the free page pool, I didn't think that the md thread
would be allowed to, allowing the md thread to get wedged first.  That
does not appear to be the case because the vm_page_alloc() call in
allocbuf() has the VM_ALLOC_SYSTEM flag set, which should match
vm_page_alloc()'s treatment of requests by pagedaemon.

I don't see how the md thread could be consuming a large number of
reserved pages, but it looks like that must be what is happening.



___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

nsswitch - pflog problem

2006-01-06 Thread skv1040


Hi,

I have a little (I hope) problem with my FreeBSD 6-STABLE.
I had pf+pflog working fine...
I added nss_ldap, pam_ldap etc.
Everything worked fine, until reboot.

I noticed strange message:
pflogd[244]: NSSWITCH(nss_method_lookup): ldap, passwd, endpwent, not found

Nevertheless everything works.
After some experiments I discovered the message
being triggered by /etc/nsswitch.conf:
when I change "passwd: files"
to "passwd: files ldap"
message appears.

Thanks in advance
Tim
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: 6.0 on Dell 1850 with DRAC4 management card?

Hej there,

Ralph Hempel wrote:
> Yes, you get that too. Full hardware power down. Wait as long as
> you want, then power the machine up. It's not the same as a remote
> reboot where you HOPE the server comes up far enough to get
> a console session.
>
Well, if the BIOS can do console redirection, the server will come up
far enough ;)
If I don't see a BIOS screen, although console redirection is enabled,
there's something really really wrong...

> Plus you don't need anything mote than an Ethernet connection to
> your existing infrastructure to make it all work.
> 
same counts for a console server (say 48 ports, 1 U) and all servers
connected to it.
One IP adress, ethernet...

> If you are paranoid and/or have a lot of servers, you can
> put all the DRAC ports on a separate subnet and their own
> VPN...
>
I would do that anyway... IMO an out-of-band network belongs into its
own subnet (vlan) and you want to secure it in some way for remote
access (ssh only, VPN, whatever)

Marian
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: gdm problem with kernel as of 2005-01-04

2006-01-06 Thread Paul T. Root


I'm in at work and turned off gdm in my rc.conf and rebooted.
The keyboard works fine! Then manually starting gdm and it
still works. That's great.

I think that something happened in the rc files that makes it
start earlier and that's conflicting with something that freezes
the keyboard.


Richard Kuhns wrote:
I just finished a buildworld/buildkernel/mergemaster on my Dell Inspiron 
9300. Upon rebooting, I noticed that gdm seemed to start earlier in the 
boot process than it used to. When the login screen appeared, the mouse 
seemed to work fine, but nothing I typed appeared. Attempting to use 
C-A-F1 to switch to vty0 just beeped. C-A-Del worked to reboot the 
laptop. I booted single user, commented out gdm_enable="YES" in 
/etc/rc.conf, and rebooted -- everything was fine. I put the gdm_enable 
back and ran /usr/X11R6/etc/rc.d/gdm.sh start -- gdm started, fully 
functional.


I rebooted again -- gdm ignored the keyboard.

After several reboots, I've found that gdm seems to work fine as long as 
I don't have 'gdm_enable="YES"' in /etc/rc.conf when the machine boots.


I've just finished upgrading gdm (using portmanager); still the same 
problem.


If anyone has suggestions/wants me to try anything, just say so.

Thanks!
- Rich


--
   __   Paul T. Root
  /_ \  1977 MGB
 /  /||  \\
||\/ ||  _ |
||   ||   ||
 \   ||__//
  \__/

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

ucom.ko and palm pilot m500

2006-01-06 Thread Carsten \"CC\" Wald

Hello List,

I own an old palm pilot -- a m500 model -- and have the following problem when 
I try to sync under 6-STABLE.

Whenever I pressed the HotSync-Button of that device -- connected to my 
6-STABLE box via a USB cable, the pilot was recognized as a ugen0 device.  
Using the pilot-xfer program then failed. After some investigation on 
pilot-link.org I learned, that Palm devices work with FreeBSD over USB only 
with the ucom driver (while for those of Handspring, the generic ugen driver 
is sufficient). -- Well, I made sure, that ucom.ko was loaded, but the device 
was still detected by the ugen.ko-module instead.  Even after unloading the 
generic driver, the ucom driver still wasn't able to detect the palm pilot.
Just a few minutes ago, I cvsuped the kernel sources and rebuilt and installed 
the kernel along with the modules (and rebooted), but it still doesn't work.

Am I the only one with that problem (and such an old pilot)? -- I have 
searched the FreeBSD documentation, pilot-link docu, etc.. but didn't find 
anything.

Is it possible to somehow force the ucom driver to "accept" the pilot, or give 
him some hints?

Thanks in advance.

-- 
bye
  Carsten


___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: 6.0 on Dell 1850 with DRAC4 management card?

2006-01-06 Thread Ralph Hempel


The only thing missing would be hardware power down. if that can be done
via DRAC, that'll be an advantage :)


Yes, you get that too. Full hardware power down. Wait as long as
you want, then power the machine up. It's not the same as a remote
reboot where you HOPE the server comes up far enough to get
a console session.

Plus you don't need anything mote than an Ethernet connection to
your existing infrastructure to make it all work.

If you are paranoid and/or have a lot of servers, you can
put all the DRAC ports on a separate subnet and their own
VPN...

Ralph

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: rpcbind lingering on IP no longer specified on command line

2006-01-06 Thread Dmitry Morozovsky

On Fri, 6 Jan 2006, Ceri Davies wrote:

CD> > [EMAIL PROTECTED]:/usr/src/usr.sbin/rpcbind# rpcinfo -p
CD> > rpcinfo: can't contact portmapper: RPC: Port mapper failure - RPC: Success
CD> 
CD> That's more annoying.  It's not INET6 though; it's because the local
CD> transport is also tpi_cots_ord, so /var/run/rpcbind.sock is not getting
CD> created.  I'll take another go at this over the weekend.

Ah yes, I did not check sockets other than tcp4.

Sincerely,
D.Marck [DM5020, MCK-RIPE, DM3-RIPN]

*** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] ***

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: 6.0 on Dell 1850 with DRAC4 management card?



Ralph Hempel wrote:
> 
>> I've never enabled the DRAC card on any dell I have that came with
>> them...
> 
> 
> Hmmm. The DRAC card can save you a long drive sometimes. You actually
> get to look at the hardware boot process and can even adjust
> BIOS settings if needed. To get to a FreeBSD console, I think that
> the OS actually needs to boot.
> 
> The DRAC lets you control the server BEFORE the OS is even loaded,
> all through a browser interface.
>
Well, you can do that too, if you enable Console Redirection to Serial
Port in the BIOS. The old DELL 1550 and 1650 were definetly capable of
doing so. I don't know about the 1850, but I assume they can redirect
the console too.
Usually the BIOS accepts VT100 or ANSI input. Of course you want to go
with VT100. And from your workstation:

export TERM=vt100
ssh user:[EMAIL PROTECTED]

and of you go.
The only thing missing would be hardware power down. if that can be done
via DRAC, that'll be an advantage :)

- Marian
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: 6.0 on Dell 1850 with DRAC4 management card?



On Jan 6, 2006, at 11:22 AM, Marian Hettwer wrote:


How old is your Cyclades box? Since mid 2002 these boxes don't send a
break when power cycled. And I know what I say, being an ex- 
employee of

cyclades (o' course, technician). We had customers with quite a large
amount of sun servers and these are usually pretty sensitive regarding
breaks.
Never had an issue due to power cycles...
hm... consider a replacement :)
The old boxes had 5 years of warranty. So, go for it ;))


thanks for the note.  it was an original ts1000 i bought new in  
spring 2001.  it recently died so I got a replacement for the $100  
repair fee.  i haven't tried a power cycle on this one: i unplugged  
everything before I powered it on :-)


___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: 6.0 on Dell 1850 with DRAC4 management card?

2006-01-06 Thread Ralph Hempel




I've never enabled the DRAC card on any dell I have that came with them...


Hmmm. The DRAC card can save you a long drive sometimes. You actually
get to look at the hardware boot process and can even adjust
BIOS settings if needed. To get to a FreeBSD console, I think that
the OS actually needs to boot.

The DRAC lets you control the server BEFORE the OS is even loaded,
all through a browser interface.

Ralph
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: 6.0 on Dell 1850 with DRAC4 management card?



Vivek Khera wrote:
> 
> On Jan 6, 2006, at 9:47 AM, Marian Hettwer wrote:
> 
>> I don't know about the DRAC with FreeBSD, but I assume that the  BIOS of
>> this Dell still supports BIOS redirection to serial port. If so,  you can
>> have Monitor and Keyboard connected locally and use the serial console
>> remote.
>> Just get a small console server (depending on the amount of servers  you
>> have remote), for instance an old cyclades TS. Connect them and you  can
>> get on your serial port through the console server via ssh.
> 
> 
> This is precisely what I do.  The cyclades work extremely well,  except
> for one flaw: if you power cycle them they send a BREAK signal  down
> every serial port.  So just make sure you don't have  BREAK_TO_DEBUGGER
> enabled on your kernels and you're safe.  Otherwise  expect every server
> to break to debugger on a power cycle of your  cyclade.  Not that you
> need to ever reboot those little boxes, but  you never know
>
How old is your Cyclades box? Since mid 2002 these boxes don't send a
break when power cycled. And I know what I say, being an ex-employee of
cyclades (o' course, technician). We had customers with quite a large
amount of sun servers and these are usually pretty sensitive regarding
breaks.
Never had an issue due to power cycles...
hm... consider a replacement :)
The old boxes had 5 years of warranty. So, go for it ;))


> I've never enabled the DRAC card on any dell I have that came with  them...
>
I'd rather stick with a good old console which I can access remotely via
ssh, too.


So Long,
Marian
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: 6.0 on Dell 1850 with DRAC4 management card?



On Jan 6, 2006, at 9:47 AM, Marian Hettwer wrote:

I don't know about the DRAC with FreeBSD, but I assume that the  
BIOS of
this Dell still supports BIOS redirection to serial port. If so,  
you can

have Monitor and Keyboard connected locally and use the serial console
remote.
Just get a small console server (depending on the amount of servers  
you
have remote), for instance an old cyclades TS. Connect them and you  
can

get on your serial port through the console server via ssh.


This is precisely what I do.  The cyclades work extremely well,  
except for one flaw: if you power cycle them they send a BREAK signal  
down every serial port.  So just make sure you don't have  
BREAK_TO_DEBUGGER enabled on your kernels and you're safe.  Otherwise  
expect every server to break to debugger on a power cycle of your  
cyclade.  Not that you need to ever reboot those little boxes, but  
you never know


I've never enabled the DRAC card on any dell I have that came with  
them...


___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: rpcbind lingering on IP no longer specified on command line

2006-01-06 Thread Ceri Davies

On Fri, Jan 06, 2006 at 05:35:28PM +0300, Dmitry Morozovsky wrote:
> On Fri, 6 Jan 2006, Ceri Davies wrote:
> 
> CD> > VK> I had rpcbind running with on two interfaces like this:
> CD> > VK> 
> CD> > VK> rpcbind -h 192.168.100.200 -h 10.0.0.9
> CD> > VK> 
> CD> > VK> Now, I changed rpcbind_flags in /etc/rc.conf to just have the first 
> address,
> CD> > VK> and I restarted rpcbind.  the process list from ps shows it is 
> running like
> CD> > VK> this:
> CD> > VK> 
> CD> > VK> rpcbind -h 192.168.100.200
> CD> > VK> 
> CD> > VK> Yet nmap on the other address shows rpcbind is still listening on 
> udp there.
> CD> > VK> How do I stop that?
> CD> > 
> CD> > As I sometimes looked into this, rpcbind (formely portmap) listens on 
> all 
> CD> > described addresses via udp *and* an tcp:*.111 - I tried to dig why is 
> this but 
> CD> > did not succeed much.
> CD> 
> CD> Please test this patch.  It's probably a very naive fix, but seems to
> CD> work OK.
> 
> Well, two objections:
> 
> - (obvious and dumb ;): three kinds of changes inside: behaviour, style and 
> typo ;-)))

Well yeah, but I figured that didn't matter for now.  I disagree that
the RUN_AS stuff is style though; the previous hardcoded "daemon"
completely takes away the point of the '#define RUN_AS "daemon"'.
If you are referring to my indentation, again that's just a "keep the
patch simple" thing.  Anyway...

> - serious: no way to run on NO_INET6 kernel:
> 
> [EMAIL PROTECTED]:/usr/src/usr.sbin/rpcbind# pid rpc
> 83231  ??  Ss 0:00.00 /usr/obj/ar/src.6/usr.sbin/rpcbind/rpcbind
> [EMAIL PROTECTED]:/usr/src/usr.sbin/rpcbind# killall rpcbind
> [EMAIL PROTECTED]:/usr/src/usr.sbin/rpcbind# pid rpc
> [EMAIL PROTECTED]:/usr/src/usr.sbin/rpcbind# rpcbind
> [EMAIL PROTECTED]:/usr/src/usr.sbin/rpcbind# rpcinfo -p
>program vers proto   port  service
> 104   tcp111  rpcbind
> 103   tcp111  rpcbind
> 102   tcp111  rpcbind
> 104   udp111  rpcbind
> 103   udp111  rpcbind
> 102   udp111  rpcbind
> 104 local111  rpcbind
> 103 local111  rpcbind
> 102 local111  rpcbind
> [EMAIL PROTECTED]:/usr/src/usr.sbin/rpcbind# killall rpcbind
> [EMAIL PROTECTED]:/usr/src/usr.sbin/rpcbind# 
> /usr/obj/ar/src.6/usr.sbin/rpcbind/rpcbind
> [EMAIL PROTECTED]:/usr/src/usr.sbin/rpcbind# rpcinfo -p
> rpcinfo: can't contact portmapper: RPC: Port mapper failure - RPC: Success
> [EMAIL PROTECTED]:/usr/src/usr.sbin/rpcbind# sockstat -4 | grep rpc
> root rpcbind83332 7  udp4   *:111 *:*
> root rpcbind83332 8  udp4   *:608 *:*
> root rpcbind83332 9  tcp4   *:111 *:*

That's more annoying.  It's not INET6 though; it's because the local
transport is also tpi_cots_ord, so /var/run/rpcbind.sock is not getting
created.  I'll take another go at this over the weekend.

Ceri
-- 
Only two things are infinite, the universe and human stupidity, and I'm
not sure about the former.-- Einstein (attrib.)


pgpXkG0Mwshuf.pgp
Description: PGP signature

Re: 6.0 on Dell 1850 with PERC4e/DC RAID?



On Jan 5, 2006, at 5:41 PM, Scott Mitchell wrote:

I may be getting a new Dell PE1850 soon, to replace our ancient CVS  
server
(still running 4-STABLE).  The new machine will ideally run 6.0 and  
have a
PERC4e/DC RAID card - the one with battery-backed cache.  This is  
listed as


I have an 1850 with the buil-in PERC 4e/Si since all I needed was the  
RAID1 mirror of the internal drives.  It works extremely well, and  
the speed is quite good.


As for notices of when the drives go bad, under 4.x I've had disk  
failures with the amr driver (different PERC cards) and not gotten  
any such notices in the syslog that I recall.  I did find a program   
posted to one of the freebsd lists called 'amrstat' that I run  
nightly.  It produces this kind of output:


Drive 0:68.24 GB, RAID1 io> optimal


If it says "degraded" it is time to fix a drive.   You just fire up  
the lsi megaraid tools and find out which drive it is.


If you go to the LSI download area, they have one file for FreeBSD,  
which is labeled the driver.  In that zip file is also the management  
software for freebsd.  You'll want that.  Personally, I like the  
"MEGAMGR" software which was released for freebsd 4.x and mimics the  
BIOS' interface in a terminal window.


The rebuild on LSI controllers is set to automatic on the dells as  
default.  It just works as expected.


Overall, I'm a big fan of the LSI cards and the amr driver...

Unfortunately for me, the latest equipment I just got only takes low- 
profile cards, and LSI doesn't offer a dual channel RAID card in low- 
profile configuration... so I need to look at adaptec.


___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: rpcbind lingering on IP no longer specified on command line



On Jan 6, 2006, at 4:40 AM, James Long wrote:


Yeah, I noticed that little tiny "UDP requests" note in the -h docs
too.  There's no reason to bind to all tcp addresses, and it is
causing me heartburn for getting the server certified...


Good grief, why not just firewall off the undesired UDP ports and call
it good?


I guess we could take that band-aid approach... however, how do you  
know what port RPC decides to listen on other than the 111 port?  It  
is more or less random.  That makes it very difficult to firewall.


___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: /boot/nextboot.conf not deactivated after one boot

2006-01-06 Thread Ceri Davies

On Thu, Jan 05, 2006 at 01:41:33PM +0100, Marius Nuennerich wrote:
> Hi folks,
> 
> it seems like /boot/nextboot.conf is neither deleted nor
> nextboot_enable set to NO on the first line after a reboot.
> So it isn't a one shot anymore as the manpage claims.
> 
> System is 6.0-RELEASE.

I think this is down to a typo in /etc/rc.d/root; at least I can't find
any other reference to /boot/nextkernel in src/.  Patch attached
(root.diff).

> It would also be fine imo, if the -k option would be optional and the
> next kernel defaults to "kernel".

I'm not sure if getopts can be persuaded to take an optional argument to
an option.  If not, the attached patch (nextboot.diff) should work for
you.

Ceri
-- 
Only two things are infinite, the universe and human stupidity, and I'm
not sure about the former.-- Einstein (attrib.)
Index: etc/rc.d/root
===
RCS file: /home/ncvs/src/etc/rc.d/root,v
retrieving revision 1.11
diff -u -r1.11 root
--- etc/rc.d/root   2 Dec 2005 21:33:43 -   1.11
+++ etc/rc.d/root   6 Jan 2006 14:37:51 -
@@ -34,8 +34,8 @@
 
# If we booted a special kernel remove the record
# so we will boot the default kernel next time.
-   if [ -e /boot/nextkernel ]; then
-   rm -f /boot/nextkernel
+   if [ -e /boot/nextboot.conf ]; then
+   rm -f /boot/nextboot.conf
fi
 }
 
Index: sbin/reboot/nextboot.8
===
RCS file: /home/ncvs/src/sbin/reboot/nextboot.8,v
retrieving revision 1.4
diff -u -r1.4 nextboot.8
--- sbin/reboot/nextboot.8  12 Dec 2002 17:25:56 -  1.4
+++ sbin/reboot/nextboot.8  6 Jan 2006 15:13:24 -
@@ -24,7 +24,7 @@
 .\"
 .\" $FreeBSD: src/sbin/reboot/nextboot.8,v 1.4 2002/12/12 17:25:56 ru Exp $
 .\"
-.Dd November 4, 2002
+.Dd January 6, 2006
 .Dt NEXTBOOT 8
 .Os
 .Sh NAME
@@ -33,8 +33,8 @@
 .Sh SYNOPSIS
 .Nm
 .Op Fl f
+.Op Fl k Ar kernel
 .Op Fl o Ar options
-.Fl k Ar kernel
 .Nm
 .Fl D
 .Sh DESCRIPTION
@@ -68,6 +68,8 @@
 This option specifies a kernel directory relative to
 .Pa /boot
 to load the kernel and any modules from.
+If this option is not provided, defaults to
+.Dq Li kernel .
 .It Fl o Ar options
 This option
 allows the passing of kernel flags for the next boot.
@@ -90,7 +92,7 @@
 .Pp
 To enable into single user mode with the normal kernel:
 .Pp
-.Dl "nextboot -o ""-s"" -k kernel"
+.Dl "nextboot -o ""-s"""
 .Pp
 To remove an existing nextboot configuration:
 .Pp
Index: sbin/reboot/nextboot.sh
===
RCS file: /home/ncvs/src/sbin/reboot/nextboot.sh,v
retrieving revision 1.1
diff -u -r1.1 nextboot.sh
--- sbin/reboot/nextboot.sh 24 May 2002 04:06:03 -  1.1
+++ sbin/reboot/nextboot.sh 6 Jan 2006 15:13:24 -
@@ -10,10 +10,12 @@
 nextboot_file="/boot/nextboot.conf"
 
 display_usage() {
-   echo "Usage: nextboot [-f] [-o options] -k kernel"
+   echo "Usage: nextboot [-f] [-k kernel] [-o options]"
echo "   nextboot -D"
 }
 
+kernel="kernel"
+
 while getopts "Dfk:o:" argument ; do
case "${argument}" in
D)
@@ -40,11 +42,6 @@
exit 0
 fi
 
-if [ "xxx${kernel}" = "xxx" ]; then
-   display_usage
-   exit 1
-fi
-
 if [ ${force} = "NO" -a ! -d /boot/${kernel} ]; then
echo "Error: /boot/${kernel} doesn't exist. Use -f to override."
exit 1


pgp042fBvaYVV.pgp
Description: PGP signature

Re: SCSI RAID card recommendation (1/2 height PCI-X U320 SCSI dual channel)



On Jan 5, 2006, at 11:08 PM, Chuck Swiger wrote:

There's an interesting thread about the AMR RAID controller used in  
the newer 18x0/28x0 Dells with the PERC/4 controller, and I know of  
enough people using them that such improvements (by Doug Ambrisko?)  
will be welcomed.


Thanks for your note.  Turns out I have more than one Dell system  
with aac controllers in them :-)


One happens to be a PE 1750 with the PERC 3/Di in it running RAID1.   
It is lightly loaded but is sufficient for that server's needs, but  
is running FreeBSD 4.11 on it.


Is there a way to backport this diskinfo utility to 4.x or 5.x?   
Looks most useful!  On my 6.0 box with a PERC 3/Si card (aac driver  
too) it is showing seek times slower than yours but transfer rates  
faster.



___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: 6.0 on Dell 1850 with DRAC4 management card?

On Fri, Jan 06, 2006 at 09:12:06AM -0500, Ralph Hempel wrote:
> Scott Mitchell wrote:
> >Hi all,
> >
> >On to my next question about running 6.0 on a Dell PE1850, since it seems
> >that the RAID card will work just fine...
> >
> >I'm thinking about getting the machine with a DRAC4 remote management card.
> >This looks to be OS-independent (you can configure through the BIOS) so I
> >expect it will just work.  I've seen various posts talking about how it
> >tends to take over the keyboard and render the real console inaccessible,
> >but there are workarounds for that.
> 
> I'm not sure about that, but I have 15 of these machines in locations
> all over Ontario, running Windows2003 Server.

I should have said that this was really a FreeBSD issue rather than a
problem with the DRAC - apparently it attaches as a second keyboard and
mouse, but FreeBSD has historically only allowed a single 'console'
keyboard to exist.  6.0 has the kbdmux(4) driver that might solve this
without and messing about with keyboard attachments.
 
> To make the thing as secure as possible, there is no keyboard or
> monitor on the server, I attach through the client's LAN.
> 
> The DRAC gets a static IP on the local subnet, so using a laptop with
> a connection (hard or wireless), I can access and control the server
> from inside the server room, from an office or desk in the building,
> or from anywhere in the world there is an Internet connection.
> 
> The last option means having VPN access to the local building network.

That sounds cool.  The server room is right behind my desk so it's not a
big deal go in there, but being able to reboot a stuck machine from home is
nice!
 
> >Does anyone have the console redirection working?  I'd like to leave the
> >'real' console (actually a USB keyboard attached to a KVM) active so the
> >machine is accessible to someone actually in the server room, but still be
> >able to get to the console remotely when necessary.  The Dell docs imply
> >that you can just point a browser at the DRAC and fire up a new console,
> >but I'd like to hear from someone who's done this with FreeBSD!
> 
> Works for me! It's really cool! You can access multiple servers through
> additional browser windows. As long as there is another computer in the
> server room with access to your server, they can control it through
> the browser interface. No KBD or monitor are necessary.
> 
> I'd like to assume FreeBSD will "just work".

Me too.  Sounds like it will mostly behave itself.

Scott
 
-- 
===
Scott Mitchell   | PGP Key ID | "Eagles may soar, but weasels
Cambridge, England   | 0x54B171B9 |  don't get sucked into jet engines"
scott at fishballoon.org | 0xAA775B8B |  -- Anon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: 6.0 on Dell 1850 with DRAC4 management card?

Hi there,

Scott Mitchell wrote:
> Hi all,
> 
> 
> I'm thinking about getting the machine with a DRAC4 remote management card.
> This looks to be OS-independent (you can configure through the BIOS) so I
> expect it will just work.  I've seen various posts talking about how it
> tends to take over the keyboard and render the real console inaccessible,
> but there are workarounds for that.

I don't know about the DRAC with FreeBSD, but I assume that the BIOS of
this Dell still supports BIOS redirection to serial port. If so, you can
have Monitor and Keyboard connected locally and use the serial console
remote.
Just get a small console server (depending on the amount of servers you
have remote), for instance an old cyclades TS. Connect them and you can
get on your serial port through the console server via ssh.
There you go ;)

ssh username:[EMAIL PROTECTED]

A pretty nice way to do remote management.

HTH,
Marian

PS.: If you need additional informations, ask me. At work we have approx
1000 servers (appr. 300 dell's) remote managed with console servers. And
it's working fine.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: rpcbind lingering on IP no longer specified on command line

2006-01-06 Thread Dmitry Morozovsky

On Fri, 6 Jan 2006, Ceri Davies wrote:

CD> > VK> I had rpcbind running with on two interfaces like this:
CD> > VK> 
CD> > VK> rpcbind -h 192.168.100.200 -h 10.0.0.9
CD> > VK> 
CD> > VK> Now, I changed rpcbind_flags in /etc/rc.conf to just have the first 
address,
CD> > VK> and I restarted rpcbind.  the process list from ps shows it is 
running like
CD> > VK> this:
CD> > VK> 
CD> > VK> rpcbind -h 192.168.100.200
CD> > VK> 
CD> > VK> Yet nmap on the other address shows rpcbind is still listening on udp 
there.
CD> > VK> How do I stop that?
CD> > 
CD> > As I sometimes looked into this, rpcbind (formely portmap) listens on all 
CD> > described addresses via udp *and* an tcp:*.111 - I tried to dig why is 
this but 
CD> > did not succeed much.
CD> 
CD> Please test this patch.  It's probably a very naive fix, but seems to
CD> work OK.

Well, two objections:

- (obvious and dumb ;): three kinds of changes inside: behaviour, style and 
typo ;-)))

- serious: no way to run on NO_INET6 kernel:

[EMAIL PROTECTED]:/usr/src/usr.sbin/rpcbind# pid rpc
83231  ??  Ss 0:00.00 /usr/obj/ar/src.6/usr.sbin/rpcbind/rpcbind
[EMAIL PROTECTED]:/usr/src/usr.sbin/rpcbind# killall rpcbind
[EMAIL PROTECTED]:/usr/src/usr.sbin/rpcbind# pid rpc
[EMAIL PROTECTED]:/usr/src/usr.sbin/rpcbind# rpcbind
[EMAIL PROTECTED]:/usr/src/usr.sbin/rpcbind# rpcinfo -p
   program vers proto   port  service
104   tcp111  rpcbind
103   tcp111  rpcbind
102   tcp111  rpcbind
104   udp111  rpcbind
103   udp111  rpcbind
102   udp111  rpcbind
104 local111  rpcbind
103 local111  rpcbind
102 local111  rpcbind
[EMAIL PROTECTED]:/usr/src/usr.sbin/rpcbind# killall rpcbind
[EMAIL PROTECTED]:/usr/src/usr.sbin/rpcbind# 
/usr/obj/ar/src.6/usr.sbin/rpcbind/rpcbind
[EMAIL PROTECTED]:/usr/src/usr.sbin/rpcbind# rpcinfo -p
rpcinfo: can't contact portmapper: RPC: Port mapper failure - RPC: Success
[EMAIL PROTECTED]:/usr/src/usr.sbin/rpcbind# sockstat -4 | grep rpc
root rpcbind83332 7  udp4   *:111 *:*
root rpcbind83332 8  udp4   *:608 *:*
root rpcbind83332 9  tcp4   *:111 *:*


Sincerely,
D.Marck [DM5020, MCK-RIPE, DM3-RIPN]

*** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] ***

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: [EMAIL PROTECTED]: Re: [Flow-tools] Memory leak ?]

2006-01-06 Thread Todor Dragnev

Hello, 

I will try with malloc and Electric Fence. I have no idea how big must be a 
process, because I use flow-capture for first time on this machine. Please, 
if someone have experience with this tool, to share some statistics.

Only for information - flow-capture is a part of flow-tools in /usr/ports 
category net-mgmt. To collect netflow-data I use softflowd.

Thank you for your email.

On Friday 06 January 2006 13:15, you wrote:
> [flow-capture process too large]
>
> On Fri, 2006-Jan-06 11:08:54 +0200, Todor Dragnev wrote:
> >Can someone help with this ?
>
> Help how?  AFAIK, flow-control/flow-capture is not a FreeBSD port so
> finding someone here with knowledge of it may be difficult.  If you
> think it's a problem with FreeBSD, you're going to need to supply more
> information so that we can help you.
>
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: 6.0 on Dell 1850 with DRAC4 management card?

2006-01-06 Thread Ralph Hempel


Scott Mitchell wrote:

Hi all,

On to my next question about running 6.0 on a Dell PE1850, since it seems
that the RAID card will work just fine...

I'm thinking about getting the machine with a DRAC4 remote management card.
This looks to be OS-independent (you can configure through the BIOS) so I
expect it will just work.  I've seen various posts talking about how it
tends to take over the keyboard and render the real console inaccessible,
but there are workarounds for that.


I'm not sure about that, but I have 15 of these machines in locations
all over Ontario, running Windows2003 Server.

To make the thing as secure as possible, there is no keyboard or
monitor on the server, I attach through the client's LAN.

The DRAC gets a static IP on the local subnet, so using a laptop with
a connection (hard or wireless), I can access and control the server
from inside the server room, from an office or desk in the building,
or from anywhere in the world there is an Internet connection.

The last option means having VPN access to the local building network.


Does anyone have the console redirection working?  I'd like to leave the
'real' console (actually a USB keyboard attached to a KVM) active so the
machine is accessible to someone actually in the server room, but still be
able to get to the console remotely when necessary.  The Dell docs imply
that you can just point a browser at the DRAC and fire up a new console,
but I'd like to hear from someone who's done this with FreeBSD!


Works for me! It's really cool! You can access multiple servers through
additional browser windows. As long as there is another computer in the
server room with access to your server, they can control it through
the browser interface. No KBD or monitor are necessary.

I'd like to assume FreeBSD will "just work".

Ralph
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

6.0 on Dell 1850 with DRAC4 management card?

Hi all,

On to my next question about running 6.0 on a Dell PE1850, since it seems
that the RAID card will work just fine...

I'm thinking about getting the machine with a DRAC4 remote management card.
This looks to be OS-independent (you can configure through the BIOS) so I
expect it will just work.  I've seen various posts talking about how it
tends to take over the keyboard and render the real console inaccessible,
but there are workarounds for that.

Does anyone have the console redirection working?  I'd like to leave the
'real' console (actually a USB keyboard attached to a KVM) active so the
machine is accessible to someone actually in the server room, but still be
able to get to the console remotely when necessary.  The Dell docs imply
that you can just point a browser at the DRAC and fire up a new console,
but I'd like to hear from someone who's done this with FreeBSD!

Apologies for all the dumb questions... I'd try all this stuff myself but
the hardware isn't here yet and has to go into production pretty quickly
once it arrives.  All the similar machines in the building are already
running Windows and someone would object if I 'liberated' any of them :)

Cheers,

Scott

-- 
===
Scott Mitchell   | PGP Key ID | "Eagles may soar, but weasels
Cambridge, England   | 0x54B171B9 |  don't get sucked into jet engines"
scott at fishballoon.org | 0xAA775B8B |  -- Anon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Fast releases demand binary updates.. (Was: Release schedule for 2006)

Hi there,

Jo Rhett wrote:
> On Fri, Jan 06, 2006 at 11:20:13AM +1030, Daniel O'Connor wrote:
>>
>>So, uhh, how would your magical binary upgrade system handle custom kernels?
>>Why would it be any different? You still haven't explained how this would 
>>work..
> 
>  
> Versioning of the core package would tell you WHAT you have with a query.
> It's trivial to then install the matching patches.  Right now every
> enterprise has to build a backend database tracking core os, installed
> options, compile options, etc for every single installed system.  Or build
> a checksum database that can be used to derive this information from the
> system (if all systems have the CPU/RAM to spare to play this game)
>
I'm actually wondering how yahoo for instance handles this situation. To
my knowledge, they have several thousand of FreeBSD based servers.
Either they are all the same in regards to configuration and version, or
they have some other cunning way to solve the issue of patching.


> 
> We need support from the freebsd core developers that this is a worthwhile
> idea, and what kind of solutions would be acceptable to them.  Once we have
> a direction to go in, code can be written.
>
Generally speaking: Your statement is true. You don't start writing code
without an agreement that the direction choosen is a direction where
FreeBSD wants to evolve.
However, you (as in, you as a developer) could come up with a proof of
concept. Start with an implementation like you would like to have it.
And even if it's just a piece of paper and some code.
Then start this thread over again, fine tune the concept and hopefully
some others will jump aboard and help developing.
I would like to, but I do lack knowledge in C. Shell and a wee bit of
Perl is fine. Definitly too few knowledge for a project like that :-/


> 
>>If you supply a working framework then I think you'll find a lot of support 
>>materialises. The problem is when you are just proposing vapourware solutions 
>>everyone steps in and wants it done their way.
>>
>>Code speaks louder than words :)
> 
> 
> I've written far too much code for various freebsd problems, and it has
> always been ignored.  Not rejected, ignored.  Unless someone with commit
> rights thinks it's a good idea, writing code for freebsd is a waste of
> time.
>
That statement ain't true. If the code solves your problem, fine. If it
solves problems of others too, even better. Chances are higher that it
doesn't get ignored...

regards,
Marian
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Fast releases demand binary updates.. (Was: Release schedule for 2006 )

2006-01-06 Thread Daniel O'Connor

On Fri, 6 Jan 2006 21:53, Jo Rhett wrote:
> > you mean? Are you claiming someone from (or claiming to be from core)
> > said "Don't do this, we won't allow it"? If so, can you supply proof?
>
> I used to write a lot of patches to freebsd.  I used to submit a lot of bug
> reports.  I've found over the years that unless you have gotten
> pre-agreement from others about the nature of the patch, or agreement to
> focus on the problem, neither one amounts to a hill of beans.  Installation
> problems that existed in 4.4 are still alive and well in the 6.0 installer,
> for example.


That is not my experience.

> How FreeBSD "works" is by getting someone in the core team to care about
> the issue.  No amount of problem reports, patches or code will generate
> even a millimeter of movement otherwise.

You are mistaking core@ for [EMAIL PROTECTED]
Like I've said before, core is largely irrelevant in FreeBSD when it comes to 
deciding what stuff gets added.

> I've written far too much code for various freebsd problems, and it has
> always been ignored.  Not rejected, ignored.  Unless someone with commit
> rights thinks it's a good idea, writing code for freebsd is a waste of
> time.

Yes.. and those people AREN'T CORE. Please, please stop confusing your terms, 
it makes the discussion much harder than it needs to be.

You ARE right if what you mean is that "We need interested committers to help 
thrash out a system for making upgrades simpler".

I imagine there are a few committers interested, but I'd say you need to ask 
the right way first..

-- 
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


pgpW2Ga0PbgcH.pgp
Description: PGP signature

Re: Fast releases demand binary updates.. (Was: Release schedule for 2006)

> > I just know that core has either struck it down or been Silent.

On Thu, Jan 05, 2006 at 05:32:26PM -0600, Mark Linimon wrote:
> The latter is an entirely different case from the former, and you've been
> claiming core has done the former.  This, and the above, tell me that
> you're not interested in checking your facts before making an accusation.
> (And, as well, that you do not even understand the role the core plays
> in the project.  Hint: it is not primarily technical in nature.)

I agree with most of what you said here.  This was known and understood.
Agreement on direction is what I was expecting, er, dreaming about. Not 
technical issues.  Sorry if that surprises you.  

But I have to take objection to this:

> As a final observation, FreeBSD is rarely advanced by postings of the
> form 'FreeBSD must do XYZ'.  This is primarily because volunteers work on
> whatever they feel interested in doing with their free time, rather than
> the priorities anyone else sets for them.

First, this is obvious and true for all open source projects.  But no,
FreeBSD _never_ advances because someone writes code that does something
well.  FreeBSD _only_ advances when the core developers agree that this
thing is worthy of their interest.

And I'm not even saying this is a bad thing.  It just means that writing
code without buy-in from the core developers is GUARANTEED to be a waste of
time.

-- 
Jo Rhett
senior geek
SVcolo : Silicon Valley Colocation
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Fast releases demand binary updates.. (Was: Release schedule for 2006)

On Fri, Jan 06, 2006 at 11:20:13AM +1030, Daniel O'Connor wrote:
> For NFS mount, read: any network file system. You can also use, say IPSEC to 
> protect the NFS packets (although I'm not claiming it's a trivial thing to 
> set up..)

IPsec is trivial compared to the amount of code and localized databases we
use to manage system versioning information today.

> As for restricting the number of writes - that is a totally separate issue 
> and 
> isn't very relevant to this discussion.

Agreed.

> In general core IS silent.
> Core isn't some governing body that decides what happens in FreeBSD and plans 
> in detail what happens. You are showing a fundamental misunderstanding about 
> how FreeBSD "works".
> Also, you just said "... the topic is always struck down ..." - what do you 
> mean? Are you claiming someone from (or claiming to be from core) said "Don't 
> do this, we won't allow it"? If so, can you supply proof?

I used to write a lot of patches to freebsd.  I used to submit a lot of bug
reports.  I've found over the years that unless you have gotten
pre-agreement from others about the nature of the patch, or agreement to
focus on the problem, neither one amounts to a hill of beans.  Installation
problems that existed in 4.4 are still alive and well in the 6.0 installer,
for example.

How FreeBSD "works" is by getting someone in the core team to care about 
the issue.  No amount of problem reports, patches or code will generate 
even a millimeter of movement otherwise.

So yeah, I take Silence as a negative.  I've got zero experience to
demonstrate otherwise.  

> I would *welcome* a more sophisticated method for binary upgrades that was a 
> lot smarter. I imagine pretty much everyone else would too.

Really?  I'm about to give up again and bring it up next year.  It's become
the annual gonzo-thread that never generates anything.

> Anyway, so what? Nothing stops you writing such a system, 

Nothing stops me, but it will become useless without constant maintenance.
And core would have no obligation to consider the effects of their changes
on this.

> and I contend it 
> isn't necessary to version the base system, or package it specially to do 
> binary upgrades. Something similar to freebsd-update could do it.

I've already spelled out the problems here.  Freebsd-update/bsdupdates.com 
spell out the problems with their approach in their documentation.  Many
others have written on this issue.

That said, if we can actually get a real conversation going about how to
handle this then I'd love to hear your input on how to solve all of the
problems we've raised without versioning of the core.
--but not now, in this thread.  This thread appears to be DOA and
I'm not going to keep wasting time on this without even a hint that 
core would be interested in a solution to this problem.
(not a blank check, just an expression of interest)

> > freebsd-update works "fine" if you run GENERIC with no build options.
> > Back to "useful for home computers".
> 
> So, uhh, how would your magical binary upgrade system handle custom kernels?
> Why would it be any different? You still haven't explained how this would 
> work..

Versioning of the core package would tell you WHAT you have with a query.
It's trivial to then install the matching patches.  Right now every
enterprise has to build a backend database tracking core os, installed
options, compile options, etc for every single installed system.  Or build
a checksum database that can be used to derive this information from the
system (if all systems have the CPU/RAM to spare to play this game)

> > freebsd-update is hampered by the exact problems I'm listing here.
> > Difficulty determining "what I have", no method to store "what I did" and
> > no effective backout mechanism to speak of.
> 
> Then feel free to expand on it.
> This IS an open source project - you can see how everything is written, if 
> you 
> want to improve it

I would be happy to write code.  See my other messages about "waste of time".
Without a comittment to the idea from someone with commit access, writing
patches or new code just sits in PRs and dies of old age.

> > Nobody that I know cares whether or not the solution manifests as core os
> > packages, but some sort of core versioning ability has to be developed and
> > supported by the core.
> 
> I don't think core is really very relevant here - core is there to mostly 
> settle disputes. The way forward is to achieve consensus and have working 
> solutions.

Sorry, I was mixing my uses of 'core' here.  My bad.

The "unpackaged" part of freebsd needs some sort of versioning ability.

But yes, you are making my point for me.  Without core's agreement that
this is a worthwhile project (as in: to be considered - not a blank check)
no amount of code will ever amount to anything other than another
unsupported freebsd-update style project.

We need support from the freebsd core developers that this is a wort

Re: [EMAIL PROTECTED]: Re: [Flow-tools] Memory leak ?]

2006-01-06 Thread Peter Jeremy

[flow-capture process too large]

On Fri, 2006-Jan-06 11:08:54 +0200, Todor Dragnev wrote:
>Can someone help with this ?

Help how?  AFAIK, flow-control/flow-capture is not a FreeBSD port so
finding someone here with knowledge of it may be difficult.  If you
think it's a problem with FreeBSD, you're going to need to supply more
information so that we can help you.

>>>I use flow-control from about 1 week. My OS is FreeBSD 6.0-RELEASE #0
>>>for AMD64. All works fine but yesterday I found  this in dmesg:
>>>
>>>Jan  4 21:30:58 katana kernel: swap_pager_getswapspace(16): failed
>>>Jan  4 21:30:58 katana kernel: swap_pager_getswapspace(12): failed
>>>Jan  4 21:30:58 katana kernel: swap_pager_getswapspace(6): failed
...
>>>518 root1  960  2648M   104M select   0:33  0.00% flow-capture

This means you've run out of swap space.  The top output shows that
the offending process was flow-capture.  Presumably you already knew
this much.

>>>My starting line for flow-capture is:
>>>
>>>/usr/local/bin/flow-capture -p /var/run/flow-capture.pid -n 287 -N 0 -w 
>>>/var/log/netflows/ -S 5 /127.0.0.1/8899
>>>
>>>Is that huge memory usage is memory leak or I do something wrong ?

The command line means nothing to me.  How big a process size were you
expecting?  If you kill and restart the process, how big is it
initially?  What libraries is it using?  What does it do?

>>I think the easiest way to start looking at this would be to run
>>flow-capture under a memory debugger of some sort, like efence 
>>(Electric Fence Malloc Debugger).

Have you tried this suggestion?  Note that phkmalloc (the standard
FreeBSD malloc) has some good debugging facilities built in - check
malloc(3) for details.

>I'm running flow-capture on AMD64 on Fedora Core 3 with no problems. 
>The only issue I run into is lack of disk space!  Sometimes 50GB is not 
>enough!

Unfortunately, Jonathan didn't say what the process size he saw was so
this doesn't help much.

-- 
Peter Jeremy
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Fast releases demand binary updates.. (Was: Release schedule for 2006)

On Thu, Jan 05, 2006 at 10:41:47AM -0800, John-Mark Gurney wrote:
> I believe core has a policy of never supporting vaporware...  There is
> always the chicken and egg problem with arguments like this...  I'll
> code this if you agree to support it and maintain it/I will agree to
> support it once you code it...   In FreeBSD, and many open source
> projects, no code, no support, how can you support or even agree to
> support something that doesn't exist?  And then as soon as FreeBSD
> agrees to support something that doesn't exist, either a) other people who
> were interested in the project stop, even if you end up never producing
> a bit of code, or b) someone else produces better code, drops the
> support for the original, but then the author complains about being
> told they'd support his code, and going with another code base...
> 
> Bottom line:  Once code exists, then support can be talked about..

This is the chicken and egg problem that will kill FreeBSD.   I don't
bother writing up patches for FreeBSD because every time I do they sit in a
PR and get ignored for several years.  Then someone that does have commit
rights makes their own patch (which often is less useful) but they own it
and the best I've ever succeeded at was convincing them to put some of the
ideas from my patch into their code.

Note that none of these patches were ever rejected for any technical or
political or any other reason.  They just don't get paid attention to.

Thus, I try to get consensus that the idea has merit.  IF freebsd
committers can be bothered to pay attention to the idea, I'll write code
for it.  But I'm too old and tired to spend another week writing up
something that will get ignored for X years and then dropped for obsoletion
again.

AND there are a lot of opinions and politics around how to version the core
that have nothing to do with code.  There's no value in writing code that
will be ignored because it doesn't agree with -core's view of "should be".
I'm a coder, not a politician.  If we can get consensus on what type of
implementation would be acceptable to core, then I and many others would be
happy to write code to implement this idea.  But this is a considerable
amount of work that will be closely tied to the operation system
installation.  It's not something that you can churn out 7 different
implementations of just to see which one fits the current polical
environment. 

Back to your finale:

> Bottom line:  Once code exists, then support can be talked about..

This is bullhockey and you know it.  Once the project is done, we'll
authorize a budget for it?  Once the season is over we'll know who should
be on the starting team?  Yeah, hindsight is sweet.  But this isn't a
simple change.  It will require very close integration with the installation
and kernel modules at least (and probably more).  So having some sort of
consensus that (a) the project has interest and (b) what flavors would be
acceptable to the existing groups - are both necessary for this project to
even mumble it's first line of code.

-- 
Jo Rhett
senior geek
SVcolo : Silicon Valley Colocation
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: [6.0] Snapshot removes acls flag from fs.

2006-01-06 Thread David Malone

On Fri, Jan 06, 2006 at 10:50:57AM +0100, V??clav Haisman wrote:
> When I make snapshot of fs it removes "acls" flag from mount. While the
> command is "mount -u -o snapshot etc." I don't think it should remove
> the flag because it is not specified besides the snapshot option.

You probably want something like:

mount -u -o cur,snapshot ...

See the "current" and "fstab" options in the mount man page. An
easier way to do this would be to use the mksnap_ffs command, which
should preserve the old options.

David.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: 6.0 on Dell 1850 with PERC4e/DC RAID?

On Fri, Jan 06, 2006 at 01:21:56PM +1100, Michael Vince wrote:
> FYI there also has been a big update to the amr driver which claims to 
> dramatically increase performance among other things, interestingly 
> enought it was augmented by Yahoo, I can only assume they are moving to 
> Dell, yahoo for me (and now you :).
> The updates are still in -current but it will be MFC'ed into stable 
> sooner or later.
> 
> http://lists.freebsd.org/pipermail/cvs-src/2005-December/056814.html

Yeah, I saw that, and it sounds most excellent.  Good to see some real
support from the likes of Dell and LSI, too. 

I might be able to get away with running -stable on this machine, but
-current will be right out.  Hopefully these changes can be MFCed in time
for 6.1.

Scott

>  Log:
>  Mega update to the LSI MegaRAID driver:
>  
>  1.  Implement a large set of ioctl shims so that the Linux management apps
>  from LSI will work.  This includes infrastructure to support adding, 
>  deleting
>  and rescanning arrays at runtime.  This is based on work from Doug 
>  Ambrosko,
>  heavily augmented by LSI and Yahoo.
>  
>  2.  Implement full 64-bit DMA support.  Systems with more than 4GB of RAM
>  can now operate without the cost of bounce buffers.  Cards that cannot do
>  64-bit DMA will automatically revert to using bounce buffers.  This option
>  can be forced off by setting the 'hw.amr.force_sg32" tunable in the loader.
>  It should only be turned off for debugging purposes.  This work was 
>  sponsored
>  by Yahoo.
>  
>  3.  Streamline the command delivery and interrupt handler paths after
>  much discussion with Dell and LSI.  The logic now closely matches the
>  intended design, making it both more robust and much faster.  Certain
>  i/o failures under heavy load should be fixed with this.
>  
>  4.  Optimize the locking.  In the interrupt handler, the card can be 
>  checked
>  for completed commands without any locks held, due to the handler being
>  implicitely serialized and there being no need to look at any shared data.
>  Only grab the lock to return the command structure to the free pool.  A
>  small optimization can still be made to collect all of the completions
>  together and then free them together under a single lock.
>  
>  Items 3 and 4 significantly increase the performance of the driver.  On an
>  LSI 320-2X card, transactions per second went from 13,000 to 31,000 in my
>  testing with these changes.  However, these changes are still fairly
>  experimental and shouldn't be merged to 6.x until there is more testing.
>  
>  Thanks to Doug Ambrosko, LSI, Dell, and Yahoo for contributing towards
>  this.
> 
> 
> 
> 
> ___
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "[EMAIL PROTECTED]"
> 

-- 
===
Scott Mitchell   | PGP Key ID | "Eagles may soar, but weasels
Cambridge, England   | 0x54B171B9 |  don't get sucked into jet engines"
scott at fishballoon.org | 0xAA775B8B |  -- Anon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: FreeBSD Update is the binary update solution [Re: HEADS UP: Release schedule for 2006]

On Thu, Jan 05, 2006 at 10:40:56PM +1100, Peter Jeremy wrote:
> >No.  I want a binary update mechanism.  Obviously if we have local
> >configuration options we'll have to compile our own binaries.  But doing
> >the work of tracking system updates currently requires us to build our own
> >patch tracking mechanism, and then re-write it for every new release.

> On Thu, 2006-Jan-05 01:37:27 -0800, Jo Rhett wrote:
> If you're willing to do your own compiles:
> 1) CVSup or cvs update to whatever branch you want
> 2) make build{world,kernel}
> 3) make DESTDIR=/updates install{world,kernel}
> 4) mergemaster -D /updates
> 5) rsync or similar

Hm.  So how do I know which systems need the upgrade?

So what occurs if the wrong version is rsynced to the wrong system?

What do I do if a kernel module upgrade fails?  How do I restore state?

This problem is solved fairly well in every other OS I can think of.  But
for FreeBSD we're currently solving it with very complex cfengine
management tied to lots of local databases and thousands of lines of our
own code.  It's all the long way around a problem that is very simple to
solve in the core.

> It seems fairly obvious that you are frustrated by FreeBSD's inability
> to meet your needs as far as updating is concerned.  I suspect I'm not
> alone in being uncertain exactly what your requirements are and what
> additional features FreeBSD needs to satisfy you.

Some implementation (any!) that versions the core.  Something you can query
to ask what is, update to say what you've done, and revert to restore a
previous state.

> How would you like
> to write a formal requirements specification and post it here (or in
> -arch).

This has been written many times, by people better at explaining the issues
than I am.  I'll find someone elses and forward it to you.

> Have you looked at tools like Bcfg2 ( http://www.mcs.anl.gov/cobalt/bcfg2/ )?

I haven't compared bcfg2 to what we're doing now (cfengine) but it would
likely have all of the same problems.  Namely, we'd have to build and
maintain a database of all possible software combinations, and what systems
are running which patches, and then write scripts that do the right updates 
to the right systems.

Again, thousands of lines of perl/ruby/shell to work around a very well 
known limitation in freebsd.

-- 
Jo Rhett
senior geek
SVcolo : Silicon Valley Colocation
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: FreeBSD Update is the binary update solution [Re: HEADS UP: Release schedule for 2006]

On Thu, Jan 05, 2006 at 01:26:12PM -0500, Ender wrote:
> I think what "integrated with the core OS" means from a user standpoint 
> is: from a fresh minimum install of freebsd I can type 
> "freebsd-update-whatever" and it will update my system.

Just "freebsd-update" ;-)

That works fairly well with the current freebsd-update (or bsdupdates.com)
solutions.  For most GENERIC installed systems, it works fairly well.  I use
on 3 systems at my home for this, and I'm pretty happy with it.

It doesn't work very well in environments with compiled options, custom
kernels, and other situations.  That's what I'm trying to tackle here.

-- 
Jo Rhett
senior geek
SVcolo : Silicon Valley Colocation
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: FreeBSD Update is the binary update solution [Re: HEADS UP: Release schedule for 2006]

On Thu, Jan 05, 2006 at 09:11:58PM +1030, Daniel O'Connor wrote:
> On Thu, 5 Jan 2006 20:02, Jo Rhett wrote:
> > On Fri, Dec 23, 2005 at 11:26:44AM +1030, Daniel O'Connor wrote:
> > > How do you expect these two to be handled in a binary upgrade?
> > > I can't see how it's possible..
> >
> > Look around.  Every major commercial OS does it just fine.  Most of the
> > open source OSes do it just fine.  Debian had probably the easiest to use
> > system, and they've risen, owned the world and fallen all while FreeBSD has
> > been debating this issue.
> 
> You appear to be misunderstanding what I said.
> 
> I'm not arguing binary upgrades shouldn't be done but I'm suggesting that it 
> isn't NECESSARY to version and package the base install to do it.

Whether or not the core is 'packaged' is an implementation detail.  I've
heard good arguements either way.  But some sort of versioning is required.
How do you know what to update?  How do you know if it has been updated
already?  Checksum analysis is the VERY long way around and incredibly CPU
intensive. And it requires an extensive database of all possible combinations.

> > > I don't think integrating it with the core OS (whatever that means) will
> > > magically fix this.
> >
> > If you knew what it meant, you would understand why it would help.
> 
> Ah what a great explanation of what is meant.
> There are several people who don't know what is meant here and I haven't seen 
> a decent explanation forthcoming.

I had explained it several times in other replies, and wasn't going to
repeat it again.  Especially not against a global wide open "I don't think
it will help" without any backing arguements or qualifications to the
statement.  It's just too broad to work with.

In short, not trying to be rude but would prefer to focus on solutions that
explain the 10k view.

> Just because I don't run jails doesn't mean I don't know the pain of 
> upgrading 
> a system.

Just because you've upgraded a system doesn't mean you understand or even
grasp the issues involved in managing jails.

You can tell me that driving a car should give you the experience to argue
riding motorcycles with me, but I'm going to have trouble taking you
seriously ;-)  (no offense intended, really... just trying to be clear)

-- 
Jo Rhett
senior geek
SVcolo : Silicon Valley Colocation
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: rpcbind lingering on IP no longer specified on command line

2006-01-06 Thread Ceri Davies

On Wed, Jan 04, 2006 at 10:46:06PM +0300, Dmitry Morozovsky wrote:
> On Wed, 4 Jan 2006, Vivek Khera wrote:
> 
> VK> I had rpcbind running with on two interfaces like this:
> VK> 
> VK> rpcbind -h 192.168.100.200 -h 10.0.0.9
> VK> 
> VK> Now, I changed rpcbind_flags in /etc/rc.conf to just have the first 
> address,
> VK> and I restarted rpcbind.  the process list from ps shows it is running 
> like
> VK> this:
> VK> 
> VK> rpcbind -h 192.168.100.200
> VK> 
> VK> Yet nmap on the other address shows rpcbind is still listening on udp 
> there.
> VK> How do I stop that?
> 
> As I sometimes looked into this, rpcbind (formely portmap) listens on all 
> described addresses via udp *and* an tcp:*.111 - I tried to dig why is this 
> but 
> did not succeed much.

Please test this patch.  It's probably a very naive fix, but seems to
work OK.

Ceri
-- 
Only two things are infinite, the universe and human stupidity, and I'm
not sure about the former.-- Einstein (attrib.)
Index: rpcbind.8
===
RCS file: /usr/home/ncvs/src/usr.sbin/rpcbind/rpcbind.8,v
retrieving revision 1.7
diff -u -r1.7 rpcbind.8
--- rpcbind.8   18 Jan 2005 20:02:43 -  1.7
+++ rpcbind.8   6 Jan 2006 10:35:02 -
@@ -83,7 +83,7 @@
 With this option, the name-to-address translation consistency
 checks are shown in detail.
 .It Fl h Ar bindip
-Specify specific IP addresses to bind to for UDP requests.
+Specify specific IP addresses to bind to.
 This option
 may be specified multiple times and is typically necessary when running
 on a multi-homed host.
@@ -95,14 +95,14 @@
 .Dv INADDR_ANY ,
 which could lead to problems on a multi-homed host due to
 .Nm
-returning a UDP packet from a different IP address than it was
+returning a packet from a different IP address than it was
 sent to.
 Note that when specifying IP addresses with
 .Fl h ,
 .Nm
 will automatically add
 .Li 127.0.0.1
-and if IPv6 is enabled,
+and, if IPv6 is enabled,
 .Li ::1
 to the list.
 .It Fl i
Index: rpcbind.c
===
RCS file: /usr/home/ncvs/src/usr.sbin/rpcbind/rpcbind.c,v
retrieving revision 1.14
diff -u -r1.14 rpcbind.c
--- rpcbind.c   7 Nov 2004 04:32:51 -   1.14
+++ rpcbind.c   6 Jan 2006 10:28:10 -
@@ -209,11 +209,11 @@
struct passwd *p;
 
if((p = getpwnam(RUN_AS)) == NULL) {
-   syslog(LOG_ERR, "cannot get uid of daemon: %m");
+   syslog(LOG_ERR, "cannot get uid of %s: %m", RUN_AS);
exit(1);
}
if (setuid(p->pw_uid) == -1) {
-   syslog(LOG_ERR, "setuid to daemon failed: %m");
+   syslog(LOG_ERR, "setuid to %s failed: %m", RUN_AS);
exit(1);
}
}
@@ -272,7 +272,8 @@
 * XXX - using RPC library internal functions. For NC_TPI_CLTS
 * we call this later, for each socket we like to bind.
 */
-   if (nconf->nc_semantics != NC_TPI_CLTS) {
+   if (nconf->nc_semantics != NC_TPI_CLTS &&
+   nconf->nc_semantics != NC_TPI_COTS_ORD) {
if ((fd = __rpc_nconf2fd(nconf)) < 0) {
int non_fatal = 0;
 
@@ -308,7 +309,8 @@
hints.ai_socktype = si.si_socktype;
hints.ai_protocol = si.si_proto;
}
-   if (nconf->nc_semantics == NC_TPI_CLTS) {
+   if (nconf->nc_semantics == NC_TPI_CLTS ||
+   nconf->nc_semantics == NC_TPI_COTS_ORD) {
/*
 * If no hosts were specified, just bind to INADDR_ANY.  
Otherwise
 * make sure 127.0.0.1 is added to the list.
@@ -348,7 +350,7 @@
hints.ai_flags &= AI_NUMERICHOST;
} else {
/*
-* Skip if we have an AF_INET6 adress.
+* Skip if we have an AF_INET6 address.
 */
if (inet_pton(AF_INET6,
hosts[nhostsbak], host_addr) == 1)
@@ -361,7 +363,7 @@
hints.ai_flags &= AI_NUMERICHOST;
} else {
/*
-* Skip if we have an AF_INET adress.
+* Skip if we have an AF_INET address.
 */
if (inet_pton(AF_INET, hosts[nhostsbak],
host_addr) == 1)


pgpcOPKf0MNey.pgp
Description: PGP signature

Re: FreeBSD Update is the binary update solution [Re: HEADS UP: Release schedule for 2006]