Re: aout support not working on todays -current

[joseph]

Hi Bob,

Go into your kernel of choice and
build it with the following:

options COMPAT_AOUT 

now to enable AOUT binaries from the kernel loader.
Make and Install and reboot the about new kerenl
and aout will now work for you.
:) joseph


AOUT binaries... elf is the all around executable format for most 
loadable binaries.. 
On Tue, 2003-01-21 at 08:36, Bob Willcox wrote:
> I cvsup'd and built and installed a new -current system and kernel this
> morning and immediately noticed that my setiathome processes no longer
> ran. It appears that aout support is no longer working in -current.
> 
> Note that I do have the COMPAT_AOUT option set in my kernel config file
> (it is the same config file that I used to build with about a week ago
> and that kernel runs aout files just fine).
> 
> Anybody have any clues as to what happened?
> 
> Thanks,
> Bob


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: make release.9 fails ... ?

[joseph]

Hi Marc,
It Should be dhclient-script.sh (a bug in the release builder?)
then it works... :) Joseph

On Wed, 2003-01-22 at 19:06, Marc G. Fournier wrote:
> Evening ...
> 
>   I found the release man page this evening, after more searching, and
> understand from it that a simple:
> 
> cd /usr/src
> make buildworld
> cd release
> make floppies
> 
>   Should give me what I need ...
> 
>   But, when I try, the release.9 stage gives:
> 
> atelier# make release.9
> rm -rf /R/stage/mfsfd
> mkdir /R/stage/mfsfd
> cd /R/stage/mfsfd &&  mkdir -p etc/defaults dev mnt stand/etc/defaults stand/help
> ( cd /R/stage/mfsfd &&  for dir in bin sbin ; do  ln -sf /stand $dir;  done )
> cp /R/stage/trees/base/sbin/dhclient-script /R/stage/mfsfd/stand
> cp: /R/stage/trees/base/sbin/dhclient-script: No such file or directory
> *** Error code 1
> 
>   Known bug, or is there another step that I need to run first?
> 
> Thanks ...
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

su and SIGHUP problem

[TOMITA Yoshinori]

On 5.0-CURRENT cvsuped recently, I am seenig very similar problem
discussed in the following.

Subject:   zsh exits upon ^C after su'ing to root with zsh as its shell
http://docs.freebsd.org/cgi/getmsg.cgi?fetch=368539+0+archive/2002/freebsd-current/20020602.freebsd-current

Subject:   su gets SIGHUP randomly on startup with latest current
http://docs.freebsd.org/cgi/getmsg.cgi?fetch=673722+0+archive/2002/freebsd-current/20020630.freebsd-current


This is what I did. Anybody can reproduce this ?

% su
Password:
# suspend

Suspended (signal)
% fg
su
# suspend

Suspended (signal)
 repeat suspend and fg several times,
 and finaly shell(tcsh) gets SIGHUP

% fg
su

Suspended (tty output)
 SIGHUP occured here !


-- 
---
TOMITA Yoshinori

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Another take on adduser

[Lyndon Nerenberg {VE6BBM}]

A couple of months ago I wrote a shell implementation of adduser.
One of the things that bothered me about the old version was the
way its policy and configuration pretty much duplicated that of pw(8).
Being able to set inconsistent policy like this is not good. Also,
pw already implemented all of the functionality adduser required, so
why reinvent this?

My adduser simply presents a (somewhat) user-friendly front end to
pw. It prompts for the data, does some very simple validation on it,
then invokes pw to do the real work. It reads policy information from
pw.conf rather than having its own configuration file, and it takes no
command line arguments what so ever. (If you're smart enough to start
specifying the types of arguments the old adduser supported, you're
smart enough to just use pw. Ditto with the batch functionality.)

If anyone is interested in exploring an alternative implementation, the
code is at ftp://orthanc.ab.ca/lyndon/freebsd/usr.sbin/adduser/.  It's
functional, but still needs edge case testing and some code cleanup.

--lyndon

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Simple way to build boot disks?

[joseph]

Hi Marc...:)

Just build your kernel and do a make release... just takes a little time
then run the script /usr/src/release/i386/mkisoimages.sh
--- READ the info about this in the shell script so you
build what you want and you can even set up drives to be mounted
... YOU can build a bootable CD with your custom kernel...
Then burn this iso image file to a CD and it will boot your kernel...
everytime...

joseph

On Wed, 2003-01-22 at 12:36, Marc G. Fournier wrote:
> G'day ...
> 
>   I'm having a bugger of a time getting my laptop with a third-party
> ethernet adapter installed with 5.0, since it won't properly configure the
> adapter ...
> 
>   what I'd like to do is build a custom boot kernel, that gets rid of
> everything but what I require for that laptop, so that the onboard doesn't
> conflict with the 3rd party one ...
> 
>   all I can find so far on how to do this is to go through the whole 'make
> release' procedure ... is there an easier way of doing this that I'm not
> finding?
> 
> thanks ...
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: make release.9 fails ... ?

[Makoto Matsushita]

scrappy>   I found the release man page this evening, after more searching, and
scrappy> understand from it that a simple:

>From release(7):

 floppies   Generate a new set of boot floppies.  This will call the
release.5, release.9, and release.10 targets to re-generate
the floppy images of a previous ``make release''.  This is
most often used to build custom boot floppies.

Be aware the word "re-generate" (not "generate"); you'll need to run
"make release" first.  In theory, you can use "floppies" target after
you've run release.[1-4] (and doc.[12] if you want RELNOTESng documents).

scrappy>   Known bug, or is there another step that I need to run first?

Maybe a bug, but it is an expected behavior.

-- -
Makoto `MAR' Matsushita

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: psm0 not found on a Sony Vaio w/ 5.0-RELEASE

[M. Warner Losh]

In message: 
Ben Hockenhull <[EMAIL PROTECTED]> writes:
: I recently installed 5.0-RELEASE on a Sony Vaio R505EC laptop and it's
: working pretty well, save for the fact that i can run X because my touchpad
: isn't found upon boot probe.
: 
: It used to be /dev/psm0 under 4.x-STABLE.  I understand I may need to edit
: sys/isa/psm.c and add my device, but I'm not sure what to put there.  Is
: there something analogous to pciconf that'll dump this device's
: descriptors?  Is there another way?

Is psm failing because it can't get irq 12?

Warner

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: vm panic

[David Xu]

- Original Message - 
From: "Jake Burkholder" <[EMAIL PROTECTED]>
To: "David Xu" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, January 23, 2003 12:33 PM
Subject: Re: vm panic
>...
> Don't know if this is the problem or not but the lockmgr code uses the
> pid as the lock cookie, so it can't distinguish 2 threads from the same
> process acquiring a lock.
> 

Thank you,  this makes sense to me,  and a bad news. :(

> I noticed that netbsd has fixed this for lwps.
> 
> Jake
> 

èR{.nÇ+‰·¬zwfj)m¢f£¢·hškyàRŠàÂ+aº{.nÇ+‰·Ÿ­ç›±×.®·§¶)í…æèw*¶¦zˁ

Re: first snag with 5.0 - XFree86 4 (fwd)

[joseph]

Recompile and install the with X*4-Server from /usr/ports/x11-servers.
Your X server was built on a RC kernel base not the RELEASE the /dev/io
mappings are slightly different. 

The following is the offending line in your snippet

Build Operating System: FreeBSD 5.0-RC i386 [ELF]

It should say 

Build Operating System: FreeBSD 5.0-RELEASE i386 [ELF]

It will then work and make sure you do a make buildworld if you upgraded
to make sure all your libs are also RELEASE not RC

:)oseph 

On Tue, 2003-01-21 at 10:41, fingers wrote:
> hi
> 
> it's been suggested that i send this to current@. Please let me know what
> info you'd like to carry on debugging this.
> 
> Regards
> 
> --Rob
> 
> -- Forwarded message --
> Date: Tue, 21 Jan 2003 16:05:34 +0200 (SAST)
> From: fingers <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: first snag with 5.0 - XFree86 4
> 
> howdie
> 
> built X 4 from source or using package I'm getting:
> 
> 
> XFree86 Version 4.2.1 / X Window System
> (protocol Version 11, revision 0, vendor release 6600)
> Release Date: 3 September 2002
> If the server is older than 6-12 months, or if your card is
> newer than the above date, look for a newer version before
> reporting problems.  (See http://www.XFree86.Org/)
> Build Operating System: FreeBSD 5.0-RC i386 [ELF]
> Module Loader present
> Markers: (--) probed, (**) from config file, (==) default setting,
>  (++) from command line, (!!) notice, (II) informational,
>  (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
> (==) Log file: "/var/log/XFree86.0.log", Time: Tue Jan 21 11:15:10 2003
> (--) Using syscons driver with X support (version 2.0)
> (--) using VT number 9
> 
> 
> Fatal server error:
> xf86EnableIO: Failed to open /dev/io for extended I/O
> 
> 
> when trying something like XFree86 -config. I trolled xfree86.org, found 1
> hit but don't see any response to it.
> 
> fresh install of 5.0-RELEASE using Riva 128. Was previously working on
> 5.0-CURRENT (build of about 2 weeks ago).
> 
> /dev/io seems to exist. wrapper is installed. xf86cfg gives same error.
> 
> any ideas? pnpinfo gives me "can't get i/o privelege" which doesn't seem
> right.
> 
> have tried 'hint.acpi.0.disabled=1' with same results. I'd think it was
> XFree86 specific initially if it wasn't for the pnpinfo error.
> 
> any suggestions appreciated.
> 
> Regards
> 
> --Rob
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-questions" in the body of the message
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: vm panic

[Jake Burkholder]

Apparently, On Thu, Jan 23, 2003 at 11:45:13AM +0800,
David Xu said words to the effect of;

> panic: lockmgr: locking against myself
> Debugger("panic")
> Stopped at Debugger+0x54: xchgl %ebx,in_Debugger.0
> db>trace
> Debugger(c0381630,c03e4ee0,c037fd14,da447c28,1) at Debugger+0x54
> panic(c037fd14,0,c037fc88,eb,1fb) at panic+0xab
> lockmgr(c138e85c,2,0,c3c150e0,c3c1514) at lockmgr+0x512
> _vm_map_lock_read(c138e280,c039bc27,896,238d3c,527) at _vm_map_lock_read+0x5a
> vm_map_check_protection(c138e80,826400,826500,2,c03b1980) at 
>vm_map_check_protection+0x31
> useracc(8264fc4,8,2,1,c038b1f) at useracc+0x7d
> nanosleep(c3c150e0,da447d10,c039f3e,407,2) at nonosleep+0x53
> syscall(bfbf002f,804002f,826002f,bfbffbe0,804a420) at syscall+0x28e
> Xint0x80_syscall() at Xint0x80_syscall+0x1d
> --- syscall (240, FreeBSD ELF32, nanosleep), eip = 0x280b0853, esp = 0x8264fb8, ebp 
>= 0x8264fd4
> 
> At the time, I am running ksetest, a kse based threaded program.
> Is the vm still not safe to run threaded program?
> 
> David Xu
> 

Don't know if this is the problem or not but the lockmgr code uses the
pid as the lock cookie, so it can't distinguish 2 threads from the same
process acquiring a lock.

I noticed that netbsd has fixed this for lwps.

Jake

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

vm panic

[David Xu]

panic: lockmgr: locking against myself
Debugger("panic")
Stopped at Debugger+0x54: xchgl %ebx,in_Debugger.0
db>trace
Debugger(c0381630,c03e4ee0,c037fd14,da447c28,1) at Debugger+0x54
panic(c037fd14,0,c037fc88,eb,1fb) at panic+0xab
lockmgr(c138e85c,2,0,c3c150e0,c3c1514) at lockmgr+0x512
_vm_map_lock_read(c138e280,c039bc27,896,238d3c,527) at _vm_map_lock_read+0x5a
vm_map_check_protection(c138e80,826400,826500,2,c03b1980) at 
vm_map_check_protection+0x31
useracc(8264fc4,8,2,1,c038b1f) at useracc+0x7d
nanosleep(c3c150e0,da447d10,c039f3e,407,2) at nonosleep+0x53
syscall(bfbf002f,804002f,826002f,bfbffbe0,804a420) at syscall+0x28e
Xint0x80_syscall() at Xint0x80_syscall+0x1d
--- syscall (240, FreeBSD ELF32, nanosleep), eip = 0x280b0853, esp = 0x8264fb8, ebp = 
0x8264fd4

At the time, I am running ksetest, a kse based threaded program.
Is the vm still not safe to run threaded program?

David Xu

¡Iì¹»®&Þ±éݙ¨¥¶‰šŽŠÝ¢j­çH:+ƒ­†éì¹»®&Þ~·žnÇ\ººÞžØ§¶›¡Ü¨~Ø^™ë,j

make release.9 fails ... ?

[Marc G. Fournier]

Evening ...

  I found the release man page this evening, after more searching, and
understand from it that a simple:

cd /usr/src
make buildworld
cd release
make floppies

  Should give me what I need ...

  But, when I try, the release.9 stage gives:

atelier# make release.9
rm -rf /R/stage/mfsfd
mkdir /R/stage/mfsfd
cd /R/stage/mfsfd &&  mkdir -p etc/defaults dev mnt stand/etc/defaults stand/help
( cd /R/stage/mfsfd &&  for dir in bin sbin ; do  ln -sf /stand $dir;  done )
cp /R/stage/trees/base/sbin/dhclient-script /R/stage/mfsfd/stand
cp: /R/stage/trees/base/sbin/dhclient-script: No such file or directory
*** Error code 1

  Known bug, or is there another step that I need to run first?

Thanks ...


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

psm0 not found on a Sony Vaio w/ 5.0-RELEASE

[Ben Hockenhull]

I recently installed 5.0-RELEASE on a Sony Vaio R505EC laptop and it's
working pretty well, save for the fact that i can run X because my touchpad
isn't found upon boot probe.

It used to be /dev/psm0 under 4.x-STABLE.  I understand I may need to edit
sys/isa/psm.c and add my device, but I'm not sure what to put there.  Is
there something analogous to pciconf that'll dump this device's
descriptors?  Is there another way?

thanks

ben



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: 5.0 and Thinkpad T20: ACPI related panics

[Lukas Ertl]

Hi -current,

just FYI regarding my suspend/resume problem on the T20 (seems like other
people have the same problem):

> On Wed, 22 Jan 2003, Lukas Ertl wrote:
>
> > I think I've found the culprit: it's the sound device. If I remove "device
> > pcm" from the kernel, I can suspend/resume after switching to a different
> > vty (suspend in X still deadlocks, though).
>
> Ok guys,
>
> I now have a partial solution for this problem. Please take a look at
> .
>
> As you can see, there was a code change in rev. 1.24 that was MFC'd later,
> but the merged code was removed from the stable tree because it caused
> panics. That's exactly what has hit me. I removed the few lines from
> csa.c, and now I can happily suspend/resume, but only if I
>
> 1) switch to a non-X vty (easy with the vidcontrol/ampd.conf hack)
> 2) suspend by either pushing the suspend button or closing the lid.
>
> Using "zzz" from an xterm or using wmapm to suspend still locks the box
> up, I don't know why.
>
> So I ask if it is possible to revert csa.c to rev. 1.23?
>
> best regards,
> le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX-Systemadministrator   Tel.:  (+43 1) 4277-14073
Zentraler Informatikdienst (ZID)   Fax.:  (+43 1) 4277-9140
der Universität Wien   http://mailbox.univie.ac.at/~le/

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: How to build -current and install to empty slice?

[Darren Pilgrim]

Ray Kohler wrote:

On Sun, Jan 19, 2003 at 05:05:37PM -0800, Darren Pilgrim wrote:


How do tell make to use /5/usr/obj instead of /usr/obj?  Will 
MAKEOBJDIRPREFIX=/5/usr/obj do this?

I have more questons:

Can I force make to ignore /etc/make.conf and
/etc/defaults/make.conf and read another set of config files?
Would it be safe to use /5/usr/src/etc/defaults/make.conf?

Will DESTDIR=/5 cause the new build tools to install under /5 as 
well, or do I need to set something else to avoid having my 4.7p3
build tools clobbered?

So far I have this set of commands:

# cd /5/usr/src && MAKEOBJDIRPREFIX=/5/usr/obj DESTDIR=/5 make buildworld
>> # MAKEOBJDIRPREFIX=/5/usr/obj DESTDIR=/5 make kernel

The buildkernel portion worked just fine, but the installkernel portion 
stopped with an error about the lack of a /5/boot/device.hints.  Copying 
that file from sys/i386/conf/GENERIC.hints worked.  The relevant output 
is attached as error1.

Then I got another error saying /5/boot/defaults/loader.conf didn't 
exist and that I needed to activate device.hints.  I copied 
sys/boot/forth/loader.conf to /5/boot/defaults/loader.conf and was then 
able to make installkernel.  The output for this error is attached as 
error2.

Is there a make target to build up ${DESTDIR}/boot, or should I keep 
this in my notes as a normal part of the process when installing to an 
empty disk?
--
>>> Kernel build for GENERIC completed on Wed Jan 22 04:43:24 PST 2003
--
cd /5/usr/obj/5/usr/src/sys/GENERIC;  MAKEOBJDIRPREFIX=/5/usr/obj  MACHINE_ARCH=i386  
MACHINE=i386  CPUTYPE=p3  GROFF_BIN_PATH=/5/usr/obj/5/usr/src/i386/usr/bin  
GROFF_FONT_PATH=/5/usr/obj/5/usr/src/i386/usr/share/groff_font  
GROFF_TMAC_PATH=/5/usr/obj/5/usr/src/i386/usr/share/tmac 
PATH=/5/usr/obj/5/usr/src/i386/usr/sbin:/5/usr/obj/5/usr/src/i386/usr/bin:/5/usr/obj/5/usr/src/i386/usr/games:/5/usr/obj/5/usr/src/make.i386:/sbin:/bin:/usr/sbin:/usr/bin
  make KERNEL=kernel install
You must set up a /5/boot/device.hints file first.
*** Error code 1

Stop in /5/usr/obj/5/usr/src/sys/GENERIC.
*** Error code 1

Stop in /5/usr/src.
*** Error code 1

Stop in /5/usr/src.


# MAKEOBJDIRPREFIX=/5/usr/obj DESTDIR=/5 make installkernel
Running test variables
PASS: Test variables detected no regression, output matches.
Running test targets
PASS: Test targets detected no regression.
Running test sysvmatch
PASS: Test sysvmatch detected no regression.
Running test lhs_expn
PASS: Test lhs_expn detected no regression.
Running test notdef
PASS: Test notdef detected no regression.
Running test modifiers
PASS: Test modifiers detected no regression.
Running test funny_targets
PASS: Test funny_targets detected no regression.
cd /5/usr/obj/5/usr/src/sys/GENERIC;  MAKEOBJDIRPREFIX=/5/usr/obj  MACHINE_ARCH=i386  
MACHINE=i386  CPUTYPE=p3  GROFF_BIN_PATH=/5/usr/obj/5/usr/src/i386/usr/bin  
GROFF_FONT_PATH=/5/usr/obj/5/usr/src/i386/usr/share/groff_font  
GROFF_TMAC_PATH=/5/usr/obj/5/usr/src/i386/usr/share/tmac 
PATH=/5/usr/obj/5/usr/src/i386/usr/sbin:/5/usr/obj/5/usr/src/i386/usr/bin:/5/usr/obj/5/usr/src/i386/usr/games:/5/usr/obj/5/usr/src/make.i386:/sbin:/bin:/usr/sbin:/usr/bin
  make KERNEL=kernel install
grep: /5/boot/defaults/loader.conf: No such file or directory
You must activate /boot/device.hints in loader.conf.
*** Error code 1

Stop in /5/usr/obj/5/usr/src/sys/GENERIC.
*** Error code 1

Stop in /5/usr/src.
*** Error code 1

Stop in /5/usr/src.

Re: vinum root [Was: I want a sysctl kern.allow_shooting_into_my_foot!]

[Joerg Wunsch]

[EMAIL PROTECTED] (Joerg Wunsch) wrote:

> The biggest problem of all this is, of course, the bootstrapping
> step.  The bootstrap still needs an `a' partition in order to read
> at least /boot/loader etc. from.  The solution is to produce a faked
> overlay `a' partition that sits at exactly the point where the
> corresponding vinum subdisk of the root device is located.

Here's the first cut of a script that would set this up.
-- 
cheers, J"org   .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
#!/usr/bin/perl -w
#
# Copyright (c) 2003 Joerg Wunsch
#
# All rights reserved.
#
# Redistribution and use in source and binary forms, with or without
# modification, are permitted provided that the following conditions
# are met:
# 1. Redistributions of source code must retain the above copyright
#notice, this list of conditions and the following disclaimer.
# 2. Redistributions in binary form must reproduce the above copyright
#notice, this list of conditions and the following disclaimer in the
#documentation and/or other materials provided with the distribution.
#
# THIS SOFTWARE IS PROVIDED BY THE DEVELOPERS ``AS IS'' AND ANY EXPRESS OR
# IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
# OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
# IN NO EVENT SHALL THE DEVELOPERS BE LIABLE FOR ANY DIRECT, INDIRECT,
# INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
# NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
# DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
# THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
# THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
#
# $FreeBSD$
#

# Create overlay partition `a' for all devices that are part of the
# named vinum root volume.

$ENV{PATH} = "/sbin:/bin:/usr/sbin:/usr/bin";
if (defined($ENV{TMPDIR})) {
$tmpdir = $ENV{TMPDIR};
} else {
$tmpdir = "/tmp";
}
$tempname = "${tmpdir}/vinum-a-part.$$";

die "usage: $0 \n" unless $#ARGV == 0;

$rootvol = $ARGV[0];
$nsds = $nlines = 0;

# First, find out the components of our ${rootvol}.  Make sure all our
# plexes have only one subdisks, and are of type "concat".  Remember
# the subdisks found for step #2.

open(V, "vinum l -r $rootvol|") || die "Cannot start vinum(8)\n";
while () {
chomp;
if (/^P/) {
/^P\s+(\S+)\s+([CSR5]+)\s+.*Subdisks:\s+(\d+)/;
$pname = $1;
$org = $2;
$nsd = $3;
$nsd > 1 && die "Plex $pname has more than one subdisk.\n";
$org ne "C" && die "Plex $pname is not a concat plex.\n";
} elsif (/^S/) {
/^S\s+(\S+)\s/;
$sdnames[$nsds++] = $1;
}
$nlines++;
}
close(V);
die "Volume $rootvol not found.\n" unless $nlines > 0;
die "Volume $rootvol has no subdisks.\n" unless $nsds > 0;

# Now, for each of the subdisks found, determine size and offset
# inside the vinum drive.  Then figure out the disk device (and
# perhaps slice) it belongs to.  Analyze the label of that device, to
# see whether the vinum partition is really there.

# If there is already an `a' partition, analyze it.  If it already
# matches our expectations, just proceed.  If it is inside the vinum
# partition but has wrong parameters, leave it to the operator for a
# manual fix, and proceed.  If it is outside vinum, try moving it into
# one of the partition slots `d' through `h'.  Failing this, proceed
# to the next subdisk.

# If successful, create a new label with our new `a' partition.

foreach $sd (@sdnames) {
open(V, "vinum l -v $sd 2>/dev/null |") || die "Cannot start vinum(8)\n";
$size = $offset = 0;
$devname = $dev = $part = "";
while () {
if (/Size:\s+(\d+)\s+bytes/) {
$size = $1;
} elsif (/Drive\s+\S+\s+[(](\S+)[)].*offset\s+(\d+)/) {
$devname = $1;
$offset = $2;
}
}
close(V);
die "Cannot find parameters for sd $sd.\n" unless
$size > 0 && $offset > 0 && $devname ne "";
$devname =~ s,^/dev/,,;
$devname =~ m|^([a-z]+\d+(s\d+)?)([a-h])$|;
$dev = $1;
$part = $3;
die "Cannot figure out device and partition from $devname.\n"
unless $dev ne "" && $part ne "";
$size /= 512;
$offset /= 512;

system("disklabel $dev > $tempname") &&
die "Cannot run disklabel(8)\n";

%parts = ();
$blurb = "";
open(L, $tempname) || die "Cannot read temp file $tempname\n";
while () {
if (/^\s+([a-h]):/) {
chomp;
$parts{$1} = $_;
} else {
$blurb .= $_;
}
}
close(L);
unlink $tempname;

die "Vinum partition ${part} not found on ${dev}\n"
unless defined($parts{$part});
$parts{$part} =~ /

an0: record length mismatch

[Lars Eggert]

Hi,

just upgraded my laptop to yesterday's -current, and I keep seeing

an0: record length mismatch -- expected 104, got 852 for Rid ff11
an0: record length mismatch -- expected 132, got 172 for Rid ff00
an0: record length mismatch -- expected 156, got 158 for Rid ff10

together with

an0: device timeout
root: FAIL an0

and then the machine freezes for about a second or so, then returns to 
normal. The card is a Cisco Aironet 350, running what I think is the 
latest firmware.

Any ideas?

Lars
--
Lars Eggert <[EMAIL PROTECTED]>   USC Information Sciences Institute


smime.p7s
Description: S/MIME Cryptographic Signature

5.0 ufs read-only mount bug

[David Bein]

Hi ...

  I have recently been upgrading to 5.0 [now on RELEASE!] and
I have one patch I've been applying which solves a problem
introduced by a change in ffs_mountfs() where a read-only
mount request insists on opening the device in R/W mode.
This is fine for the reasons it was done, but it means
you can't mount -o ro a ufs filesystem which is on a
read-only medium [e.g. a network disk replica or perhaps
a ufs filesystem on a CDROM]. Enclosed are suggested patches
which preserve the intent of the changes as of 5.0, but
allow a read-only mount on a read-only device to work as
well. If a mount is done with this, then mount -u -o rw is
not allowed. Needless to say, if you really want to mount
it for writing, you need to copy the image to a writable
medium. Enclosed are diffs [relative to 5.0-RELEASE].

--David

# diff -c ufs/ufs/ufsmount.h.orig ufs/ufs/ufsmount.h
*** ufs/ufs/ufsmount.h.orig Sun Dec 29 09:54:20 2002
--- ufs/ufs/ufsmount.h  Wed Jan 15 12:10:43 2003
***
*** 84,90 
--- 84,93 
int (*um_valloc)(struct vnode *, int, struct ucred *, struct vnode **);
int (*um_vfree)(struct vnode *, ino_t, int);
void(*um_ifree)(struct ufsmount *, struct inode *);
+   int um_fmode;   /* FREAD or FREAD|FWRITE */
  };
+ 
+ #define __UFSMOUNT_FMODE__
  
  #define UFS_BALLOC(aa, bb, cc, dd, ee, ff) VFSTOUFS((aa)->v_mount)->um_balloc(aa, 
bb, cc, dd, ee, ff)
  #define UFS_BLKATOFF(aa, bb, cc, dd) VFSTOUFS((aa)->v_mount)->um_blkatoff(aa, bb, 
cc, dd)

# diff -c ufs/ffs/ffs_vfsops.c.orig ufs/ffs/ffs_vfsops.c
*** ufs/ffs/ffs_vfsops.c.orig   Sun Dec 29 09:54:19 2002
--- ufs/ffs/ffs_vfsops.cWed Jan 15 12:14:33 2003
***
*** 244,249 
--- 244,256 
(error = ffs_reload(mp, ndp->ni_cnd.cn_cred, td)) != 0)
return (error);
if (fs->fs_ronly && (mp->mnt_kern_flag & MNTK_WANTRDWR)) {
+ #if defined(__UFSMOUNT_FMODE__)
+   /*
+* Disallow this if devvp is read-only ...
+*/
+   if (ump->um_fmode != (FREAD|FWRITE))
+   return(EROFS);
+ #endif/* defined(__UFSMOUNT_FMODE__) */
/*
 * If upgrade to read-write by non-root, then verify
 * that user has necessary permissions on the device.
***
*** 569,574 
--- 576,584 
struct ucred *cred;
size_t strsize;
int ncount;
+ #if defined(__UFSMOUNT_FMODE__)
+   int um_fmode = 0;
+ #endif/* defined(__UFSMOUNT_FMODE__) */
  
dev = devvp->v_rdev;
cred = td ? td->td_ucred : NOCRED;
***
*** 607,612 
--- 617,638 
  
ronly = (mp->mnt_flag & MNT_RDONLY) != 0;
vn_lock(devvp, LK_EXCLUSIVE | LK_RETRY, td);
+ #if defined(__UFSMOUNT_FMODE__)
+   /*
+* Try to open R/W, but if that fails, try just for read
+* but only if this is a read-only mount. We remember how
+* we did this so that we can disallow upgrades to R/W
+* if ump->um_fmode == FREAD.
+*/
+   um_fmode = FREAD|FWRITE;
+ again:
+   if ((error = VOP_OPEN(devvp, um_fmode, FSCRED, td)) != 0) {
+   if ((um_fmode != FREAD) && (ronly != 0)) {
+   um_fmode = FREAD;
+   goto again;
+   }
+   }
+ #else /* !defined(__UFSMOUNT_FMODE__) */
/*
 * XXX: We don't re-VOP_OPEN in FREAD|FWRITE mode if the filesystem
 * XXX: is subsequently remounted, so open it FREAD|FWRITE from the
***
*** 617,622 
--- 643,649 
  #else
error = VOP_OPEN(devvp, FREAD|FWRITE, FSCRED, td);
  #endif
+ #endif/* !defined(__UFSMOUNT_FMODE__) */
VOP_UNLOCK(devvp, 0, td);
if (error)
return (error);
***
*** 687,692 
--- 714,722 
fs->fs_pendinginodes = 0;
}
ump = malloc(sizeof *ump, M_UFSMNT, M_WAITOK | M_ZERO);
+ #if defined(__UFSMOUNT_FMODE__)
+   ump->um_fmode = um_fmode;
+ #endif/* defined(__UFSMOUNT_FMODE__) */
ump->um_fs = malloc((u_long)fs->fs_sbsize, M_UFSMNT,
M_WAITOK);
if (fs->fs_magic == FS_UFS1_MAGIC) {
***
*** 829,839 
--- 859,873 
if (bp)
brelse(bp);
/* XXX: see comment above VOP_OPEN */
+ #if defined(__UFSMOUNT_FMODE__)
+   (void)VOP_CLOSE(devvp, um_fmode, cred, td);
+ #else /* !defined(__UFSMOUNT_FMODE__) */
  #ifdef notyet
(void)VOP_CLOSE(devvp, ronly ? FREAD : FREAD|FWRITE, cred, td);
  #else
(void)VOP_CLOSE(devvp, FREAD|FWRITE, cred, td);
  #endif
+ #endif/* !defined(__UFSMOUNT_FMODE__) */
if (ump) {
free(ump->um_fs, M_UFSMNT);
free(ump, M_UFSMNT);
***
*** 988,993 
--- 1022,1030 
ump->um_devv

RE: ran out of room on / while installing the world

[John Baldwin]

On 22-Jan-2003 Kirk R. Wythers wrote:
> I just ran into a problem trying to a 'make installworld' while going
> from 4.7 to 5.0-R. I thought I checked and had 30M free on / before I
> started this. However, after building, the world, building the kernel,
> installing the kernel, running mergemaster -p, I went to install the
> world and got the error 'out of space on /' 
> 
> I need to find some room, but I'm a little nervous about what I can rm.
> Here is what I'm looking at:
> 
> 1) / partition is 79M, 64M are used (I was almost sure there was more
> room than that on / before I satarted). 
> 2) /tmp is on it's own partition
> 3) du -h on subdirectories breakdown like this. 
>   a.   18M /boot
>   b.   1.4M /etc
>   c.   3.7M /kernel
>   d.   3.9M /kern.GENERIC
>   e.   6M /modules
>   f.   21M /sbin
>   g.   2.1M /stand
> 
> as you can see that pretty much accounts for it. The rest of the stuff
> is pretty small.
> 
> I need to know if I can delete any of this stuff and still successfully
> do a 'make installworld'? Particularly, is there anything in /boot or
> /sbin that can be deleted while up in single user mode before 'make
> installworld' (assuming that it is not needed for the install and will
> be replaced by the install process)?

You can blow away /kern.GENERIC for now and once you are upgraded you
can blow away /kernel.  5.0 puts kernels in /boot/ and
each kernel includes its own set of modules rather than having
/ and a set of shared modules under /modules.  You can
also blow away modules you aren't using in /modules right now and
once the installworld is done blow away all modules in /modules that
aren't 3rd party modules.

-- 

John Baldwin <[EMAIL PROTECTED]>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

ran out of room on / while installing the world

[Kirk R. Wythers]

I just ran into a problem trying to a 'make installworld' while going
from 4.7 to 5.0-R. I thought I checked and had 30M free on / before I
started this. However, after building, the world, building the kernel,
installing the kernel, running mergemaster -p, I went to install the
world and got the error 'out of space on /' 

I need to find some room, but I'm a little nervous about what I can rm.
Here is what I'm looking at:

1) / partition is 79M, 64M are used (I was almost sure there was more
room than that on / before I satarted). 
2) /tmp is on it's own partition
3) du -h on subdirectories breakdown like this. 
a.   18M /boot
b.   1.4M /etc
c.   3.7M /kernel
d.   3.9M /kern.GENERIC
e.   6M /modules
f.   21M /sbin
g.   2.1M /stand

as you can see that pretty much accounts for it. The rest of the stuff
is pretty small.

I need to know if I can delete any of this stuff and still successfully
do a 'make installworld'? Particularly, is there anything in /boot or
/sbin that can be deleted while up in single user mode before 'make
installworld' (assuming that it is not needed for the install and will
be replaced by the install process)?

Thanks,

Kirk


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: I want a sysctl kern.allow_shooting_into_my_foot!

[Joerg Wunsch]

"Daniel C. Sobral" <[EMAIL PROTECTED]> wrote:

>> You can turn this debugging off from userland with:
>>  sysctl kern.geom.debugflags=0
> 
> Why not make it a loader tunable?

Why should it?  It's a debugging flag, so it's IMHO sufficient that it
can be set from DDB (that's what i did).

-- 
cheers, J"org   .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Simple way to build boot disks?

[Marc G. Fournier]

G'day ...

  I'm having a bugger of a time getting my laptop with a third-party
ethernet adapter installed with 5.0, since it won't properly configure the
adapter ...

  what I'd like to do is build a custom boot kernel, that gets rid of
everything but what I require for that laptop, so that the onboard doesn't
conflict with the 3rd party one ...

  all I can find so far on how to do this is to go through the whole 'make
release' procedure ... is there an easier way of doing this that I'm not
finding?

thanks ...

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: background fsck did not create lost+found

[Garrett Wollman]

< 
said:

> Unfortunately, I think it is possible that the unreferenced inode
> has not been initialized, even though it is allocated in the inode
> bitmap, so you could potentially get random junk.

That is definitely true on UFS2, which I had forgotten.  UFS2 inodes
are only initialized when they are used.

-GAWollman


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: vinum & growfs

[Joerg Wunsch]

Alex Deiter <[EMAIL PROTECTED]> wrote:

> Say me please, sometime growfs will learn to work with vinum
> volumes?

The growfs maintainers know about the problem, and are working on a
solution.  We learned about that problem too late before 5.0R was due,
so since a quick fix couldn't be produced in time, i think they are
now looking for an overall better integration of growfs and newfs
(which are very similar in nature).

-- 
cheers, J"org   .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: vinum root [Was: I want a sysctl kern.allow_shooting_into_my_foot!]

[Joerg Wunsch]

Ollivier Robert <[EMAIL PROTECTED]> wrote:

>> Oh, i should add: in my case, it's loaded before mounting the
>> root (root is on vinum).

> And how did you achieved this ? I thought vinum isn't able to do
> that...

Well, the patch for -current is currently only sitting here on my
machine(s).  Greg wanted to review it before i commit it, but i'll
append it in case someone else wants to have a look at it.  Under
-current, the generic part of the kernel (namely mountroot() and its
related functions) is already clean enough so no changes are needed
there, only vinum needs a patch.

Under -stable, the patch is already in the tree.  Since mountroot()
employs a very simple scheme to derive the dev_t of the root device
from the given device name there, a patch to it was required, and all
this is not very clean, but it works (see below).

The basic concept is that you need to have the loader load the vinum
module for you, and vinum needs to be told to configure itself early.
Under -current (with the patch), put the following into
/boot/loader.conf:

vinum_load="YES"
vinum.autostart="YES"

Your /etc/fstab needs to have /dev/vinum/root (or whatever you name
it) for the / filesystem; the loader will read this file, and pass the
device name as the default root device to mountroot().  mountroot()
then asks the drivers (by the trick of calling the undocumented event
handler for disk_clone) to get a dev_t for the given name.
Alternatively, any name entered after boot -a will be resolved the
same way.  So what the patch does is:

. implement the logic to start vinum early

. implement an event handler for dev_clone so vinum will get asked,
  too

Under 4.x, put the following into loader.conf:

vinum_load="YES"
vinum.drives="/dev/da0 /dev/da1 /dev/da2"
vinum.root="root"

The logic to have vinum auto-scan the available disks is not yet
there, so you explicitly need to name the devices to scan.  (This part
of the patch has been implemented first here under -current, but can
perhaps be MFC'ed, too.  The vinum.drives approach will also still
work with the -current patch but is less convenient.)

Also, since mountroot() has no way to ask the drivers to translate the
given name into the corresponding dev_t, the trick with vinum.root is
used; if this environment variable is set, vinum will pre-allocate the
variable rootdev with the appropriate dev_t if the volume named by
this has been found.  The generic code will trust this value if the
major # of the driver as figured out from the root device name matches
the major # of the pre-allocated rootdev.  I. e., it still gets
/dev/vinum/root from the loader, strips the /dev/ (not needed at all
inside the kernel), then scans until the first digit or slash,
yielding "vinum" in that case.  Now, if the major number of the preset
rootdev matches the major # of vinum, the value will be taken.  If
rootdev has not been set, the traditional approach by deriving the
minor # from the unit #, slice #, and partition name will be taken
(using a hardcoded algorithm for this which is independent of the
actual driver).  All this gives the illusion that mountroot() would
know how to handle /dev/vinum/root. ;-)  Of course, what you cannot do
is to boot -a, then enter an invalid name (so you'll get asked again),
and then enter ufs:/dev/vinum/root: the previous invalid name has
destroyed the preset rootdev value.  At that point, you either need to
abort or to enter a valid slice/partition.

The biggest problem of all this is, of course, the bootstrapping step.
The bootstrap still needs an `a' partition in order to read at least
/boot/loader etc. from.  The solution is to produce a faked overlay
`a' partition that sits at exactly the point where the corresponding
vinum subdisk of the root device is located.  Another solution would
be to setup a mini-root that only contains a boot/ directory in it,
and use that one for partition `a', but that'll only cause other
trouble (like "make install" not doing the right thing).  While
/boot/loader could perhaps be taught how to read something from a
vinum volume, there's always the problem how to get at /boot/loader
itself, so i have no other idea for this.  A script could be provided
that creates the faked `a' entry.

-- 
cheers, J"org   .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
Index: vinum.c
===
RCS file: /home/ncvs/src/sys/dev/vinum/vinum.c,v
retrieving revision 1.49
diff -u -u -r1.49 vinum.c
--- vinum.c 1 Apr 2002 21:30:36 -   1.49
+++ vinum.c 13 Jan 2003 21:13:33 -
@@ -66,6 +66,8 @@
 
 STATIC int vinum_modevent(module_t mod, modeventtype_t type, void *unused);
 
+STATIC void vinum_clone(void *arg, char *name, int namelen, dev_t *dev);
+
 struct _vinum_conf vinum_conf; /* configuration 
information */
 
 dev_t vinum_dae

Re: background fsck did not create lost+found

[Max Khon]

hi, there!

On Wed, Jan 22, 2003 at 02:43:37PM -0500, Garance A Drosihn wrote:

> >  > > > Would that be a big problem to allow some fsck option not
> >  > > > to erase all these softupdates-pending inodes, but to put
> >  > > > them in lost+found as usual?
> >  > >
> >  > > It certainly couldn't be done with the background fsck,
> >  > > because background fsck works on a snapshot and not the
> >  > > running filesystem; thus, it cannot make any allocations -- it
> >  > > can only deallocate things.
> >  >
> >  > Still, in case you know some of your important files can be lost,
> >  > you can boot the system to single user and run foreground fsck.
> >
> >this is not an option if the system was rebooted because of power
> >loss or kernel panic
> 
> Can't you just set the rc.conf option to not-do the background fsck?

I can but the whole purpose of background fsck (faster startup times)
will be lost.

/fjoe


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: kernel panic with today's CURRENT on sparc64 at boot

[Thomas Moestl]

On Tue, 2003/01/21 at 17:33:42 +, [EMAIL PROTECTED] wrote:
> Hi
> 
> cvsup'd to . today on an E220R, single CPU with two Symbios scsi cards.
> Box had been running fine with RC3, but would not boot with -CURRENT
> kernel:
> 
> Current:
> 
> hme4: Ethernet address: 08:00:20:b7:ef:44
> miibus4:  on hme4
> ukphy3:  on miibus4
> ukphy3:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
> sym0: <875> port 0x1000-0x10ff mem 0x1090a000-0x1090afff,0x10908000-0x109080ff i
> rq 32 at device 3.0 on pci0
> panic: trap: fast data access mmu miss
> cpuid = 0;
> Debugger("panic")
> Stopped at  Debugger+0x1c:  ta  %xcc, 1

Can you please cvsup again to pick up some changes that were made
yesterday and try again?

- Thomas

-- 
Thomas Moestl <[EMAIL PROTECTED]> http://www.tu-bs.de/~y0015675/
  <[EMAIL PROTECTED]> http://people.FreeBSD.org/~tmm/
PGP fingerprint: 1C97 A604 2BD0 E492 51D0  9C0F 1FE6 4F1D 419C 776C

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: I want a sysctl kern.allow_shooting_into_my_foot!

[Daniel C. Sobral]

[EMAIL PROTECTED] wrote:


Hmm, since this happens during boot, you cannot set the debug flag
with sysctl in time, so you have to compile a custom kernel for it:

in sys/geom/geom_kern.c change:

	int g_debugflags;

to
	int g_debugflags = G_T_ACCESS;

and recompile + reboot.

This will make GEOM printf all "access" (ie: open/close) changes and
you should hopefully be able to deduce where the open of your MO comes
from.

If this is not enough, you can try to set

	int g_debugflags = G_T_ACCESS | G_T_TOPOLOGY;

But that will result in much more debugging output.

You can turn this debugging off from userland with:
	sysctl kern.geom.debugflags=0


Why not make it a loader tunable?

--
Daniel C. Sobral   (8-DCS)
Gerencia de Operacoes
Divisao de Comunicacao de Dados
Coordenacao de Seguranca
TCO
Fones: 55-61-313-7654/Cel: 55-61-9618-0904
E-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]

Outros:
	[EMAIL PROTECTED]
	[EMAIL PROTECTED]
	[EMAIL PROTECTED]

Art is anything you can get away with.
		-- Marshall McLuhan.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: background fsck did not create lost+found

[Garance A Drosihn]

At 12:53 AM +0600 1/23/03, Max Khon wrote:


On Wed, Jan 22, 2003 at 07:18:44PM +0100, Jan Srzednicki wrote:

 > > > Would that be a big problem to allow some fsck option not
 > > > to erase all these softupdates-pending inodes, but to put
 > > > them in lost+found as usual?
 > >
 > > It certainly couldn't be done with the background fsck,
 > > because background fsck works on a snapshot and not the
 > > running filesystem; thus, it cannot make any allocations -- it
 > > can only deallocate things.
 >
 > Still, in case you know some of your important files can be lost,
 > you can boot the system to single user and run foreground fsck.

this is not an option if the system was rebooted because of power
loss or kernel panic


Can't you just set the rc.conf option to not-do the background fsck?

--
Garance Alistair Drosehn=   [EMAIL PROTECTED]
Senior Systems Programmer   or  [EMAIL PROTECTED]
Rensselaer Polytechnic Instituteor  [EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: background fsck did not create lost+found

[David Schultz]

Thus spake Garrett Wollman <[EMAIL PROTECTED]>:
> <<[EMAIL PROTECTED]> said:
> 
> > Would that be a big problem to allow some fsck option not to erase all
> > these softupdates-pending inodes, but to put them in lost+found as usual?
> 
> It certainly couldn't be done with the background fsck, because
> background fsck works on a snapshot and not the running filesystem;
> thus, it cannot make any allocations -- it can only deallocate things.

Actually, that should work just fine.  When background fsck
notices an unreferenced inode in the snapshot, it could create a
file in the underlying filesystem.  The easy way to do this is to
copy the data with the standard open(2)/write(2)/close(2)
interfaces.  After the copy, the original data blocks are
deallocated as usual.  A more efficient implementation might
require a special kernel interface that creates a directory entry,
given an inode number and path.  Unfortunately, I think it is
possible that the unreferenced inode has not been initialized,
even though it is allocated in the inode bitmap, so you could
potentially get random junk.

Such a feature sounds reasonable, although I'm not sure how useful
it would really be.  If you have software that introduces a race
window where you can lose data because it does updates
incorrectly, hacking the operating system to make the race window
slightly smaller is not the best solution.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: background fsck did not create lost+found

[Max Khon]

hi, there!

On Wed, Jan 22, 2003 at 07:18:44PM +0100, Jan Srzednicki wrote:

> > > Would that be a big problem to allow some fsck option not to erase all
> > > these softupdates-pending inodes, but to put them in lost+found as usual?
> >
> > It certainly couldn't be done with the background fsck, because
> > background fsck works on a snapshot and not the running filesystem;
> > thus, it cannot make any allocations -- it can only deallocate things.
> 
> Still, in case you know some of your important files can be lost, you can
> boot the system to single user and run foreground fsck.

this is not an option if the system was rebooted because of power loss
or kernel panic

/fjoe


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Adduser difference between 5.0 and earlier versions

[Scot Hetzel]

Use this patch, as it fixes the value of uidstart to be the next
available uid, instead of the uid of the previously added user.

Scot

Index: adduser.sh
===
RCS file: /home/ncvs/src/usr.sbin/adduser/adduser.sh,v
retrieving revision 1.3
diff -u -r1.3 adduser.sh
--- adduser.sh  3 Dec 2002 05:41:09 -   1.3
+++ adduser.sh  22 Jan 2003 18:12:02 -
@@ -871,4 +871,23 @@
fi
 else
input_interactive
+   while : ; do
+   echo -n "Add another user? (yes/no): "
+   read _input
+#  [ -z "$_input" ] && _input="No"
+   case $_input in
+   [Yy][Ee][Ss]|[Yy][Ee]|[Yy])
+   uidstart=`get_nextuid $uidstart`
+   input_interactive
+   continue
+   ;;
+   [Nn][Oo]|[Nn])
+   echo "Goodbye!"
+   ;;
+   *)
+   continue
+   ;;
+   esac
+   break
+   done
 fi

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: background fsck did not create lost+found

[Jan Srzednicki]

On Wed, 22 Jan 2003, Garrett Wollman wrote:

> > Would that be a big problem to allow some fsck option not to erase all
> > these softupdates-pending inodes, but to put them in lost+found as usual?
>
> It certainly couldn't be done with the background fsck, because
> background fsck works on a snapshot and not the running filesystem;
> thus, it cannot make any allocations -- it can only deallocate things.

Still, in case you know some of your important files can be lost, you can
boot the system to single user and run foreground fsck.

-- 
  -- wrzask --= v =-- Winfried --=-- GG# 3838383 --=-- JS500-RIPE --
-- [EMAIL PROTECTED] --- [EMAIL PROTECTED] --===-- http://violent.dream.vg/ ---
--=< Ride the wild wind - push the envelope, don't sit on the fence, ---
  -- Ride the wild wind - live life on the razor's edge! >=-- Queen --


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: background fsck did not create lost+found

[Garrett Wollman]

< said:

> Would that be a big problem to allow some fsck option not to erase all
> these softupdates-pending inodes, but to put them in lost+found as usual?

It certainly couldn't be done with the background fsck, because
background fsck works on a snapshot and not the running filesystem;
thus, it cannot make any allocations -- it can only deallocate things.

-GAWollman


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Mounting Other *BSD Partitions

[Crist J. Clark]

I've got a test box that boots Windows, NetBSD, and both FreeBSD
STABLE and CURRENT. The FreeBSD CURRENT system is having trouble
mounting the NetBSD partitions. The STABLE system has no problem with
the NetBSD slice and its partitions.

Have all of the CURRENT changes made it impossible to mount some old
NetBSD partitions? Or is there some magical incantation to get this to
work?
-- 
Crist J. Clark | [EMAIL PROTECTED]
   | [EMAIL PROTECTED]
http://people.freebsd.org/~cjc/| [EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: adduser(8) in 5.0-R

[Bruce A. Mah]

If memory serves me right, Mike Makonnen wrote:

> I have cc'ed bmah, because I think it should be in the errata.

Done.  Thanks!

Bruce.





msg50715/pgp0.pgp
Description: PGP signature

LOR: arp mutex/radix node head

[Lars Eggert]

On yesterday's -current:

lock order reversal
 1st 0xc03d2740 arp mutex (arp mutex) @ /usr/src/sys/netinet/if_ether.c:151
 2nd 0xc64c6b7c radix node head (radix node head) @ 
/usr/src/sys/net/route.c:549

Will try to get a trace next time it happens.

Lars
--
Lars Eggert <[EMAIL PROTECTED]>   USC Information Sciences Institute


smime.p7s
Description: S/MIME Cryptographic Signature

Re: 4.7-amd cannot mount exports from 5.0-RELEASE

[Michael Nottebrock]

Masafumi NAKANE wrote:
> On Mon, 20 Jan 2003 09:15:40 +0100,
> Michael Nottebrock <[EMAIL PROTECTED]> wrote:
>
>>Yes, that's exactly what I'm experiencing here... uhoh. First
>>errata-topic discovered 2 hours after the release? :}
>
>
> Well, not so quick.  I took another -CURRENT box and the problem was
> not reproduceable on this box.  I can't quite figure out what the
> differences between these two boxes are, though.

Could others check this please with 5.0-RELEASE? I was (and still am)
willing to continue running RELENG_5_0 on that server, but I would
rather not try and run -CURRENT. If this a common problem with 5.0-R, it
would surely warrant a 'critical bugfix'.

--
Regards,
	Michael Nottebrock



msg50713/pgp0.pgp
Description: PGP signature

RE: Fatal trap 12: page fault while in kernel mode

[John Baldwin]

On 22-Jan-2003 Peter Kostouros wrote:
> Hi
> 
> I am having a similar problem to what has been reported previously
> regarding X. Basically I get a fatal trap 12. (cvsup'ed about one hour
> ago.) I have attached a backtrace I hope is useful.
> 
> When I started X within gdb, I received the following:
> 
> Program received signal SIGUSR1. User defined signal 1
> 0x2818b1a3 in sigsuspend() from /usr/lib/libc.so.5.

Unfortunately the bug is in a kernel module (the ?? lines
in your backtrace).  Could you possibly compile a custom
kernel that has everything you use in it and then reproduce
this bug and get a trace?

> Peter

-- 

John Baldwin <[EMAIL PROTECTED]>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

RE: acpi_cpu printf

[John Baldwin]

On 21-Jan-2003 Nate Lawson wrote:
> How is this?
> 
> --- acpi_cpu.c  16 Oct 2002 17:28:52 -  1.14
> +++ acpi_cpu.c  21 Jan 2003 06:07:43 -
> @@ -295,8 +295,10 @@
>  /* set initial speed */
>  acpi_cpu_power_profile(NULL);
>  
> -printf("acpi_cpu: CPU throttling enabled, %d steps from 100%% to %d.%d%%\n",
> -  CPU_MAX_SPEED, CPU_SPEED_PRINTABLE(1));
> +printf("acpi_cpu: throttling enabled, %d steps from 100%% to %d.%d%%, " 
> +  "currently %d.%d%%\n"
> +  CPU_MAX_SPEED, CPU_SPEED_PRINTABLE(1),
> +  CPU_SPEED_PRINTABLE(cpu_current_state));
>  }

Looks ok to me.  Thanks.

-- 

John Baldwin <[EMAIL PROTECTED]>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Adduser difference between 5.0 and earlier versions

[Scot Hetzel]

Here's the requested changes to make it re'ask the question on
an invalid input.

I left the code in for the default answer, but commented out.

Scot

Index: adduser.sh
===
RCS file: /home/ncvs/src/usr.sbin/adduser/adduser.sh,v
retrieving revision 1.3
diff -u -r1.3 adduser.sh
--- adduser.sh  3 Dec 2002 05:41:09 -   1.3
+++ adduser.sh  22 Jan 2003 15:38:02 -
@@ -871,4 +871,22 @@
fi
 else
input_interactive
+   while : ; do
+   echo -n "Add another user? (yes/no): "
+   read _input
+#  [ -z "$_input" ] && _input="No"
+   case $_input in
+   [Yy][Ee][Ss]|[Yy][Ee]|[Yy])
+   input_interactive
+   continue
+   ;;
+   [Nn][Oo]|[Nn])
+   echo "Goodbye!"
+   ;;
+   *)
+   continue
+   ;;
+   esac
+   break
+   done
 fi

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: first snag with 5.0 - XFree86 4 (fwd)

[fingers]

thanks all, securelevel was 2


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: I want a sysctl kern.allow_shooting_into_my_foot!

[Joerg Wunsch]

As [EMAIL PROTECTED] wrote:

> >You are saying that the close should read?
> >error = (*devsw(drive->dev)->d_close) (drive->dev, FWRITE | FREAD, 0, NULL);
> 
> Yes, d_close should match whatever the corresponding d_open is called with.

Thanks for pointing this out, this indeed seems to fix this case, fix already
committed. ;-)
-- 
cheers, J"org   .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: I want a sysctl kern.allow_shooting_into_my_foot!

[phk]

In message <[EMAIL PROTECTED]>, Bernd Walter writes:

>> da1a closed but without FREAD|FWRITE, which turns the close into a no-op.
>
>[125]cicely5# grep d_open *
>grep: CVS: Operation not permitted
>vinumext.h:d_open_t vinumopen;
>vinumio.c:  drive->lasterror = (dsw->d_open) (drive->dev, FWRITE | FREAD, 0, 
>NULL);
>Exit 2
>[126]cicely5# grep d_close *
>grep: CVS: Operation not permitted
>vinumext.h:d_close_t vinumclose;
>vinumio.c:error = (*devsw(drive->dev)->d_close) (drive->dev, 0, 0, NULL);
>Exit 2
>
>You are saying that the close should read?
>error = (*devsw(drive->dev)->d_close) (drive->dev, FWRITE | FREAD, 0, NULL);

Yes, d_close should match whatever the corresponding d_open is called with.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: I want a sysctl kern.allow_shooting_into_my_foot!

[Bernd Walter]

On Wed, Jan 22, 2003 at 02:40:28PM +0100, [EMAIL PROTECTED] wrote:
> In message <[EMAIL PROTECTED]>, Joerg Wunsch writes:
> 
> >Here's the result.  What does it mean to me?  (debug flag set from
> >DDB, and turned off in single-user again.)
> 
> Here's the bug:
> 
>   g_dev_open(da1a, 3, 0, 0)
> 
> da1a opened (FREAD|FWRITE)
> 
>   g_access_rel(0xc1178a40(da1a), 1, 1, 0)
>   open delta:[r1w1e0] old:[r0w0e0] provider:[r0w0e0] 0xc11d4f00(da1a)
>   g_post_event(2, 0, 0, 0xc11d4f00, 0xc1178a40)
>   g_access_rel(0xc1178f40(da1), 1, 1, 1)
>   open delta:[r1w1e1] old:[r0w0e0] provider:[r0w0e0] 0xc1194d00(da1)
>   g_post_event(2, 0, 0, 0xc1194d00, 0xc1178f40)
>   g_disk_access(da1, 1, 1, 1)
>   g_do_event(0xc1178780) 2 m:0 g:0 p:0xc11d4f00 c:0xc1178a40 - 
>   EV_SPOILED(0xc11d4f00(da1a),0xc1178a40)
>   g_do_event(0xc1178740) 2 m:0 g:0 p:0xc1194d00 c:0xc1178f40 - 
>   EV_SPOILED(0xc1194d00(da1),0xc1178f40)
>   spoiling 0xc1178e40 (da1) (0)
>   g_dev_close(da1a, 0, 0, 0)
> 
> da1a closed but without FREAD|FWRITE, which turns the close into a no-op.

[125]cicely5# grep d_open *
grep: CVS: Operation not permitted
vinumext.h:d_open_t vinumopen;
vinumio.c:  drive->lasterror = (dsw->d_open) (drive->dev, FWRITE | FREAD, 0, NULL);
Exit 2
[126]cicely5# grep d_close *
grep: CVS: Operation not permitted
vinumext.h:d_close_t vinumclose;
vinumio.c:error = (*devsw(drive->dev)->d_close) (drive->dev, 0, 0, NULL);
Exit 2

You are saying that the close should read?
error = (*devsw(drive->dev)->d_close) (drive->dev, FWRITE | FREAD, 0, NULL);

-- 
B.Walter  COSMO-Project http://www.cosmo-project.de
[EMAIL PROTECTED] Usergroup   [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

ACPI features in FreeBSD 5.0

[Gerald Mixa]

Hi,

I have got a Sony Vaio PCG FX-705 Laptop (Athlon Based). I have Installed 
FreeBSD 5.0 on.
Now what has happend:
Yesterday evening I have turned off my Laptop as root using halt
(everything) worked fine.
Today when I went intu my office. My Laptop was turned on and hanged during 
boot time.
And something like:
Correcting VIA ACPI Bug was displayed.
I am nearly 100% sure, that nobody touched this Computer during the whole 
night.
Of course the Laptop was equiped with a battery and connected to AC/DC.
Now my question:
Did i make something worng when turning down my Laptop?
Did anyone else hav this behaviour?
And btw: The following ACPI errer codes are reported during boot time:
ACPI-0432
ACPI-1287

Sincerley

Gerald Mixa

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Linux-base version with 5.0 floppy install

[local.freebsd.current]

I'm just installing 5.0-RELEASE from the floppies.

Answering yes to "do you want Linux binary compatibility"
during sysinstall causes it to fetch linux_base-6.1 - I
rather thought it would install 7.1.

The package retrieval (from ftp.uk.freebsd.org) goes OK but
then the pkg_add fails. Sysinstall says "add of package aborted,
error code 1". The alt-F2 screen reveals that it is trying to
do a kldload of the kernel module and this fails with a
"kldload: can't load linux: no such file or directory".

Also it couldn't fetch the ports collection from the above
server - not a problem since I can always get it with cvsup.

jim

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: I want a sysctl kern.allow_shooting_into_my_foot!

[phk]

In message <[EMAIL PROTECTED]>, Joerg Wunsch writes:

>Here's the result.  What does it mean to me?  (debug flag set from
>DDB, and turned off in single-user again.)

Here's the bug:

g_dev_open(da1a, 3, 0, 0)

da1a opened (FREAD|FWRITE)

g_access_rel(0xc1178a40(da1a), 1, 1, 0)
open delta:[r1w1e0] old:[r0w0e0] provider:[r0w0e0] 0xc11d4f00(da1a)
g_post_event(2, 0, 0, 0xc11d4f00, 0xc1178a40)
g_access_rel(0xc1178f40(da1), 1, 1, 1)
open delta:[r1w1e1] old:[r0w0e0] provider:[r0w0e0] 0xc1194d00(da1)
g_post_event(2, 0, 0, 0xc1194d00, 0xc1178f40)
g_disk_access(da1, 1, 1, 1)
g_do_event(0xc1178780) 2 m:0 g:0 p:0xc11d4f00 c:0xc1178a40 - 
EV_SPOILED(0xc11d4f00(da1a),0xc1178a40)
g_do_event(0xc1178740) 2 m:0 g:0 p:0xc1194d00 c:0xc1178f40 - 
EV_SPOILED(0xc1194d00(da1),0xc1178f40)
spoiling 0xc1178e40 (da1) (0)
g_dev_close(da1a, 0, 0, 0)

da1a closed but without FREAD|FWRITE, which turns the close into a no-op.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

subscribe

[Gerald Mixa]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: PS/2 mouse problems with -CURRENT

[Igor Roboul]

On Wed, Jan 22, 2003 at 12:49:04AM -0600, Chip Norkus wrote:
> But try disabling ACPI and see if your PS/2 mouse suddenly works. ;)
As you can see from my first post
>> Same part of newer -CURRENT (I have disable ACPI, but I get same
>> result with ACPI too):
 
>> atkbdc0:  at port 0x64,0x60 on isa0
>> atkbd0:  flags 0x1 irq 1 on atkbdc0
>> kbd0 at atkbd0
>> psm0:  irq 12 on atkbdc0
>> psm0: model NetMouse/NetScroll Optical, device ID 0
first thing I have tried was disabling ACPI :-(. I'll try today (maybe
I have mistyped something).


-- 
Igor Roboul, System administrator at Speech Technology Center
http://www.speechpro.com http://www.speechpro.ru

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Statement regarding FreeBSD release ISO images

[Kirill Pisman]

> Thanks, and go buy some 5.0 CD's =-)
>
Of course ! MediaHouse in russia had a litle bit  of delay - about a 2-3
monts !!!


Realy im think that needed only one disk . Tere is no need to very fast
updates in home , where realy ussing 4 disks.



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

subscribe

[john]

-- 
wbr, andris, dc jelgava

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: I want a sysctl kern.allow_shooting_into_my_foot!

[Ollivier Robert]

According to Joerg Wunsch:
> Oh, i should add: in my case, it's loaded before mounting the
> root (root is on vinum).

And how did you achieved this ? I thought vinum isn't able to do that...

-- 
Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- [EMAIL PROTECTED]
FreeBSD keltia.freenix.fr 5.0-CURRENT #80: Sun Jun  4 22:44:19 CEST 2000

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: I want a sysctl kern.allow_shooting_into_my_foot!

[Joerg Wunsch]

As Bernd Walter wrote:

> Now that you say it - vinum isn't loaded before going multiuser.

Oh, i should add: in my case, it's loaded before mounting the
root (root is on vinum).
-- 
cheers, J"org   .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: I want a sysctl kern.allow_shooting_into_my_foot!

[Joerg Wunsch]

As [EMAIL PROTECTED] wrote:

> If this is not enough, you can try to set
> 
>   int g_debugflags = G_T_ACCESS | G_T_TOPOLOGY;
> 
> But that will result in much more debugging output.

Here's the result.  What does it mean to me?  (debug flag set from
DDB, and turned off in single-user again.)
-- 
cheers, J"org   .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)

Copyright (c) 1992-2003 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 5.0-CURRENT #11: Tue Jan 14 15:44:49 CET 2003
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/UNCLE
Preloaded elf kernel "/boot/kernel/kernel" at 0xc0463000.
Preloaded elf module "/boot/kernel/vinum.ko" at 0xc04630b4.
Timecounter "i8254"  frequency 1193182 Hz
Timecounter "TSC"  frequency 166194348 Hz
CPU: Pentium/P54C (166.19-MHz 586-class CPU)
  Origin = "GenuineIntel"  Id = 0x52c  Stepping = 12
  Features=0x1bf
real memory  = 33554432 (32 MB)
avail memory = 28098560 (26 MB)
Initializing GEOMetry subsystem
g_add_class(DEV)
g_add_class(BSD)
g_add_class(MBR)
g_add_class(MBREXT)
g_add_class(DISK)
g_add_class(GEOMCTL)
g_call_me(0xc01798e4, 0
npx0:  on motherboard
npx0: INT 16 interface
pcib0:  at pcibus 0 on motherboard
pci0:  on pcib0
isab0:  at device 7.0 on pci0
isa0:  on isab0
pci0:  at device 7.1 (no driver attached)
ahc0:  port 0xe000-0xe0ff mem 0xfb00-0xfb000fff 
irq 10 at device 9.0 on pci0
aic7860: Ultra Single Channel A, SCSI Id=7, 3/253 SCBs
xl0: <3Com 3c900-COMBO Etherlink XL> port 0xd800-0xd83f irq 11 at device 10.0 on pci0
xl0: Ethernet address: 00:60:97:52:77:3a
xl0: selecting 10baseT transceiver, half duplex
orm0:  at iomem 0xc8000-0xcc7ff on isa0
atkbdc0:  at port 0x64,0x60 on isa0
atkbd0:  flags 0x1 irq 1 on atkbdc0
kbd0 at atkbd0
fdc0:  at port 
0x3f7,0x3f0-0x3f5 irq 6 drq 2 on isa0
fdc0: FIFO enabled, 8 bytes threshold
fd0: <1440-KB 3.5" drive> on fdc0 drive 0
fd1: <1200-KB 5.25" drive> on fdc0 drive 1
sc0:  at flags 0x100 on isa0
sc0: MDA <16 virtual consoles, flags=0x100>
sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0
sio0: type 16550A, console
sio1: reserved for low-level i/o
vga0:  at port 0x3b0-0x3bb iomem 0xb-0xb7fff on isa0
unknown:  can't assign resources (port)
sio2: <16550A-compatible COM port> at port 0x2f8-0x2ff irq 3 on isa0
sio2: type 16550A
unknown:  can't assign resources (port)
unknown:  can't assign resources (port)
Timecounters tick every 10.000 msec
g_do_event(0xc10c0100) 3 m:0 g:0 p:0 c:0 - 
g_post_event(1, 0, 0, 0xc11ac000, 0)
g_do_event(0xc11cd480) 1 m:0 g:0 p:0xc11ac000 c:0 - 
EV_NEW_PROVIDER(geom.ctl)
dev_taste(DEV,geom.ctl)
g_call_me(0xc017ad24, 0xc11a5900
g_call_me(0xc017ad24, 0xc110f400
g_do_event(0xc11cd380) 3 m:0 g:0 p:0 c:0 - 
g_post_event(1, 0, 0, 0xc11ac280, 0)
g_do_event(0xc11cd340) 3 m:0 g:0 p:0 c:0 - 
g_post_event(1, 0, 0, 0xc1194d00, 0)
g_do_event(0xc11cd300) 1 m:0 g:0 p:0xc11ac280 c:0 - 
EV_NEW_PROVIDER(da0)
g_mbrext_taste(MBREXT,da0)
mbr_taste(MBR,da0)
g_access_rel(0xc11cd240(da0), 1, 0, 0)
open delta:[r1w0e0] old:[r0w0e0] provider:[r0w0e0] 0xc11ac280(da0)
g_disk_access(da0, 1, 0, 0)
g_call_me(0xc017ae84, 0xc090d600
cd0 at ahc0 bus 0 target 2 lun 0
cd0:  Removable CD-ROM SCSI-2 device 
cd0: 4.032MB/s transfers (4.032MHz, offset 15)
cd0: Attempt to query device size failed: NOT READY, Medium not present
da1 at ahc0 bus 0 target 3 lun 0
da1:  Fixed Direct Access SCSI-2 device 
da1: 20.000MB/s transfers (20.000MHz, offset 15)
da1: 2069MB (4238282 512 byte sectors: 255H 63S/T 263C)
da0 at ahc0 bus 0 target 1 lun 0
da0:  Fixed Direct Access SCSI-2 device 
da0: 20.000MB/s transfers (20.000MHz, offset 15), Tagged Queueing Enabled
da0: 4357MB (8925000 512 byte sectors: 255H 63S/T 555C)
g_access_rel(0xc11cd240(da0), -1, 0, 0)
open delta:[r-1w0e0] old:[r1w0e0] provider:[r1w0e0] 0xc11ac280(da0)
g_disk_access(da0, -1, 0, 0)
g_std_spoiled(0xc11cd240)
g_detach(0xc11cd240)
g_destroy_consumer(0xc11cd240)
g_destroy_geom(0xc1194c80(da0))
bsd_taste(BSD,da0)
g_access_rel(0xc11cd180(da0), 1, 0, 0)
open delta:[r1w0e0] old:[r0w0e0] provider:[r0w0e0] 0xc11ac280(da0)
g_disk_access(da0, 1, 0, 0)
g_slice_conf_hot()
g_slice_config(da0, 0, 0)
g_slice_config(da0, 1, 0)
g_slice_config(da0, 2, 0)
g_slice_config(da0, 3, 0)
g_slice_config(da0, 4, 0)
g_slice_config(da0, 5, 0)
g_slice_config(da0, 6, 0)
g_slice_config(da0, 7, 0)
g_slice_config(da0, 0, 1)
g_slice_config(da0, 1, 1)
g_slice_config(da0, 2, 1)
g_post_event(1, 0, 0, 0xc1194c80, 0)
g_slice_config(da0, 3, 1)
g_slice_config(da0, 4, 1)
g_slice_config(da0, 5, 1)
g_slice_config(da0, 6, 1)
g_slice_config(da0, 7, 1)
g_post_event(1, 0, 0, 0xc11d5200, 0)
g_access_rel(0xc11cd180(da0), -1, 0, 0)
open delta:[r-1w0e0] old:[r1w0e0] provider:[r1w0e0] 0xc11ac280(da0)
g_disk_access(da0, -1, 0, 0)
dev_taste(DEV,da0)
g_do_event(0xc11cd2c0) 1 m:0 g:0 p:0xc119

Re: I want a sysctl kern.allow_shooting_into_my_foot!

[Bernd Walter]

On Wed, Jan 22, 2003 at 01:25:59PM +0100, [EMAIL PROTECTED] wrote:
> In message <[EMAIL PROTECTED]>, Bernd Walter writes:
> You can also try this, it's more easily informative:
> 
>   sysctl -n kern.geom.confdot | dot -Tps > _.ps ; gv _.ps
> 
> You need the graphviz and ghostscript ports for this.

Mmmm - it doesn't fit on the page :)
But at least I saw da13 after setting the Papersize to A3.
Nice.

> >I never complained about this, because the system is rather old
> >(2002-11-15) and I believed it was already fixed.
> >But it sounds like Joergs situation may be triggered by the same bug.
> >Mmmm - I'm using vinum too.
> >Is there any way to find out which ones open it was?
> 
> Hmm, since this happens during boot, you cannot set the debug flag
> with sysctl in time, so you have to compile a custom kernel for it:

Now that you say it - vinum isn't loaded before going multiuser.
It should be easy to check the situation in singleuser mode and
then set the required flags.
Thanks for the tips.

-- 
B.Walter  COSMO-Project http://www.cosmo-project.de
[EMAIL PROTECTED] Usergroup   [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Error Mounting /dev/acd0 on /dist: during sysinstall of 5.0-RELEASE

[Paul A. Mayer]

Hi,

I have a similar problem, i.e., a clean installation process for 
5.0-RELEASE produces the error:

"Error Mounting /dev/acd0 on dist: Operation not supported by device (19)"

(I wound up doing a minimal ftp install and then did a binary upgrade 
with the CD as the distribution medium.)

Nate suggests:

>>Does setting hw.ata.atapi_dma=1 help?

How would you do this in the clean installation scenario.  Is there a 
way to pass this setting to the kernel during the boot process, or 
modify the running environment by some other means before sysinstall 
takes over?

Regards,

/Paul

Thomas T. Veldhouse wrote:
I am trying to install from the CD-ROM, so I don't really have the option
unless I do it from the boot loader.  I can say that it is not set for the
installed system (which I installed via FTP) and yet, I can mount a CD just
fine.  It is just a problem from within sysinstall.  Below are the results
of dmesg on my system after I installed from an FTP server.

Copyright (c) 1992-2003 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 5.0-RELEASE #0: Thu Jan 16 22:16:53 GMT 2003
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC
Preloaded elf kernel "/boot/kernel/kernel" at 0xc0673000.
Preloaded elf module "/boot/kernel/acpi.ko" at 0xc06730a8.
Timecounter "i8254"  frequency 1193182 Hz
Timecounter "TSC"  frequency 600024637 Hz
CPU: AMD-K7(tm) Processor (600.02-MHz 686-class CPU)
  Origin = "AuthenticAMD"  Id = 0x612  Stepping = 2

Features=0x81f9ff
  AMD Features=0xc040
real memory  = 402571264 (383 MB)
avail memory = 384110592 (366 MB)
Initializing GEOMetry subsystem
Pentium Pro MTRR support enabled
npx0:  on motherboard
npx0: INT 16 interface
acpi0:  on motherboard
ACPI-0625: *** Info: GPE Block0 defined as GPE0 to GPE15
Using $PIR table, 8 entries at 0xc00f15e0
ACPI-1287: *** Error: Method execution failed, AE_AML_REGION_LIMIT
acpi0: power button is handled as a fixed feature programming model.
Timecounter "ACPI-fast"  frequency 3579545 Hz
ACPI-1287: *** Error: Method execution failed, AE_AML_REGION_LIMIT
acpi_timer0: <24-bit timer at 3.579545MHz> port 0xe408-0xe40b on acpi0
acpi_cpu0:  on acpi0
acpi_button0:  on acpi0
pcib0:  port 0xcf8-0xcff on acpi0
pci0:  on pcib0
agp0:  mem 0xe400-0xe7ff
at device 0.0 on pci0
pcib1:  at device 1.0 on pci0
pci1:  on pcib1
pci1:  at device 0.0 (no driver attached)
isab0:  at device 4.0 on pci0
isa0:  on isab0
atapci0:  port 0xb800-0xb80f at device 4.1 on
pci0
ata0: at 0x1f0 irq 14 on atapci0
ata1: at 0x170 irq 15 on atapci0
uhci0:  port 0xb400-0xb41f irq 5 at device 4.2 on
pci0
usb0:  on uhci0
usb0: USB revision 1.0
uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
uscanner0: Visioneer Visioneer 6100 USB Scanner, rev 1.00/0.00, addr 2
uhci1:  port 0xb000-0xb01f irq 5 at device 4.3 on
pci0
usb1:  on uhci1
usb1: USB revision 1.0
uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub1: 2 ports with 2 removable, self powered
pci0:  at device 11.0 (no driver attached)
pci0:  at device 11.1 (no driver attached)
fxp0:  port 0x8800-0x883f mem
0xd600-0xd60f,0xd680-0xd6800fff irq 5 at device 13.0 on pci0
fxp0: Ethernet address 00:03:47:97:f6:b8
inphy0:  on miibus0
inphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
fdc0:  port
0x3f7,0x3f2-0x3f5 irq 6 drq 2 on acpi0
fdc0: FIFO enabled, 8 bytes threshold
fd0: <1440-KB 3.5" drive> on fdc0 drive 0
ppc0 port 0x778-0x77b,0x378-0x37f irq 7 drq 3 on acpi0
ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode
ppc0: FIFO with 16/16/8 bytes threshold
plip0:  on ppbus0
lpt0:  on ppbus0
lpt0: Interrupt-driven port
ppi0:  on ppbus0
sio0 port 0x3f8-0x3ff irq 4 on acpi0
sio0: type 16550A
sio1 port 0x2f8-0x2ff irq 3 on acpi0
sio1: type 16550A
atkbdc0:  port 0x64,0x60 irq 1 on acpi0
atkbd0:  flags 0x1 irq 1 on atkbdc0
kbd0 at atkbd0
ACPI-1287: *** Error: Method execution failed, AE_AML_REGION_LIMIT
ACPI-1287: *** Error: Method execution failed, AE_AML_REGION_LIMIT
ACPI-1287: *** Error: Method execution failed, AE_AML_REGION_LIMIT
ACPI-1287: *** Error: Method execution failed, AE_AML_REGION_LIMIT
ACPI-1287: *** Error: Method execution failed, AE_AML_REGION_LIMIT
ACPI-1287: *** Error: Method execution failed, AE_AML_REGION_LIMIT
ACPI-1287: *** Error: Method execution failed, AE_AML_REGION_LIMIT
ACPI-1287: *** Error: Method execution failed, AE_AML_REGION_LIMIT
ACPI-1287: *** Error: Method execution failed, AE_AML_REGION_LIMIT
psm0:  irq 12 on atkbdc0
psm0: model IntelliMouse, device ID 3
orm0:  at iomem 0xc-0xcbfff on isa0
pmtimer0 on isa0
sc0:  at flags 0x100 on isa0
sc0: VGA <16 virtual consoles, flags=0x300>
vga0:  at port 0x3c0-0x3df iomem 0xa-0xb on isa0
Timecounters tick every 10.000 msec
acpi_cpu: CPU throttling enabled, 16 steps from 100% to 6.

Re: I want a sysctl kern.allow_shooting_into_my_foot!

[phk]

In message <[EMAIL PROTECTED]>, Bernd Walter writes:
>On Tue, Jan 21, 2003 at 11:06:05PM +0100, [EMAIL PROTECTED] wrote:
>> In message <[EMAIL PROTECTED]>, Joerg Wunsch writes:
>> >As [EMAIL PROTECTED] wrote:
>> >
>> >> Hang on.
>> >> 
>> >> If no disk partitions of any kind are open, there is nothing which
>> >> prevents you from doing a "dd if=/dev/zero of=/dev/da0 bs=64k".
>> >
>> >My guess is that vinum scanned the disks when starting, but found
>> >nothing on it.
>> 
>> And forgot to close them again ?  Well, you know where to look
>> for that bug then :-)
>> 
>> (If you look in the "sysctl -b kern.geom.confxml" output, you will
>> be able to see the read/write/exclusive open counts, look for
>> "r%dw%de%d" strings.)
>
>Interesting sysctl.

Yes, one of the more informative :-)

>
>  
>  r1w1e0
>  da13e
>  652329984
>  1024
>  
>4
>652329984
>1274082
>0
>0
>  
>
>

>If I got it right it tells me, that da13e is opened for read/write.

You can also try this, it's more easily informative:

sysctl -n kern.geom.confdot | dot -Tps > _.ps ; gv _.ps

You need the graphviz and ghostscript ports for this.

>I never complained about this, because the system is rather old
>(2002-11-15) and I believed it was already fixed.
>But it sounds like Joergs situation may be triggered by the same bug.
>Mmmm - I'm using vinum too.
>Is there any way to find out which ones open it was?

Hmm, since this happens during boot, you cannot set the debug flag
with sysctl in time, so you have to compile a custom kernel for it:

in sys/geom/geom_kern.c change:

int g_debugflags;

to
int g_debugflags = G_T_ACCESS;

and recompile + reboot.

This will make GEOM printf all "access" (ie: open/close) changes and
you should hopefully be able to deduce where the open of your MO comes
from.

If this is not enough, you can try to set

int g_debugflags = G_T_ACCESS | G_T_TOPOLOGY;

But that will result in much more debugging output.

You can turn this debugging off from userland with:
sysctl kern.geom.debugflags=0

Poul-Henning

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: I want a sysctl kern.allow_shooting_into_my_foot!

[Bernd Walter]

On Tue, Jan 21, 2003 at 11:06:05PM +0100, [EMAIL PROTECTED] wrote:
> In message <[EMAIL PROTECTED]>, Joerg Wunsch writes:
> >As [EMAIL PROTECTED] wrote:
> >
> >> Hang on.
> >> 
> >> If no disk partitions of any kind are open, there is nothing which
> >> prevents you from doing a "dd if=/dev/zero of=/dev/da0 bs=64k".
> >
> >My guess is that vinum scanned the disks when starting, but found
> >nothing on it.
> 
> And forgot to close them again ?  Well, you know where to look
> for that bug then :-)
> 
> (If you look in the "sysctl -b kern.geom.confxml" output, you will
> be able to see the read/write/exclusive open counts, look for
> "r%dw%de%d" strings.)

Interesting sysctl.
[...]

  
  da13e
  3

  
  
  r1w1e0



  
  da13c
  3

  
  
  r0w0e0


[...]

  
  da13
  2

  
  
  r0w0e0


[...]

  
  da13
  2
  
16384
1024
0
0
  

  
  
  r1w1e1
  
  


  
  r1w1e0
  da13e
  652329984
  1024
  
4
652329984
1274082
0
0
  


  
  r0w0e0
  da13c
  652329984
  1024
  
2
652329984
1274082
0
0
  


[...]

If I got it right it tells me, that da13e is opened for read/write.
da13 is an MO driver and I can't eject the media, because it's locked.
The media was never mounted since booting.
I never complained about this, because the system is rather old
(2002-11-15) and I believed it was already fixed.
But it sounds like Joergs situation may be triggered by the same bug.
Mmmm - I'm using vinum too.
Is there any way to find out which ones open it was?

-- 
B.Walter  COSMO-Project http://www.cosmo-project.de
[EMAIL PROTECTED] Usergroup   [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: background fsck did not create lost+found

[Jan Srzednicki]

On Mon, 20 Jan 2003, David Schultz wrote:

> > First two entries clearly correspond to the missing file, which should
> > have been put in /home/lost+found. But, the poroblem is that no lost+found
> > directory was created, while it should (as fsck_ffs(8) says). I guess its
> > a bug, probably in the background fsck code. Still, is there any way to
> > reclaim the file now, besides running strings(1) on the whole partition?
>
> Consider what happens when you remove a large directory tree.
> Thousands of directory entries may be removed, but in the
> softupdates case, the inodes will stick around a bit longer.  The
> same also applies to files that have been intentionally unlinked
> but are still open.  To avoid a syndrome where all these thousands
> of files end up in lost+found after a crash or power failure, fsck
> just removes them on softupdates-enabled filesystems.

Would that be a big problem to allow some fsck option not to erase all
these softupdates-pending inodes, but to put them in lost+found as usual?
The default behaviour is unchanged, yet there is a way to reclaim lost
files.

-- 
  -- wrzask --= v =-- Winfried --=-- GG# 3838383 --=-- JS500-RIPE --
-- [EMAIL PROTECTED] --- [EMAIL PROTECTED] --===-- http://violent.dream.vg/ ---
--=< Ride the wild wind - push the envelope, don't sit on the fence, ---
  -- Ride the wild wind - live life on the razor's edge! >=-- Queen --


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Fatal trap 12: page fault while in kernel mode

[Peter Kostouros]

Hi

I am having a similar problem to what has been reported previously
regarding X. Basically I get a fatal trap 12. (cvsup'ed about one hour
ago.) I have attached a backtrace I hope is useful.

When I started X within gdb, I received the following:

Program received signal SIGUSR1. User defined signal 1
0x2818b1a3 in sigsuspend() from /usr/lib/libc.so.5.

Peter

Script started on Wed Jan 22 19:55:34 2003
GNU gdb 5.2.1 (FreeBSD)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-undermydesk-freebsd"...
panic: bwrite: buffer is not busy???
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0x308
fault code  = supervisor read, page not present
instruction pointer = 0x8:0xc03a9ce2
stack pointer   = 0x10:0xe09cb66c
frame pointer   = 0x10:0xe09cb678
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 3
current process = 679 (XFree86)
trap number = 12
panic: page fault

syncing disks, buffers remaining... panic: bwrite: buffer is not busy???
Uptime: 8m37s
Dumping 511 MB
ata0: resetting devices ..
ad0: DMA limited to UDMA33, non-ATA66 cable or device
done
 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368 
384 400 416 432 448 464 480 496
---
#0  doadump () at /mnt/cvs/freebsd/usr/src/sys/kern/kern_shutdown.c:232
/mnt/cvs/freebsd/usr/src/sys/kern/kern_shutdown.c:232:6775:beg:0xc025687b
(kgdb) bt
#0  doadump () at /mnt/cvs/freebsd/usr/src/sys/kern/kern_shutdown.c:232
#1  0xc0256d99 in boot (howto=260)
at /mnt/cvs/freebsd/usr/src/sys/kern/kern_shutdown.c:364
#2  0xc0256ff3 in panic ()
at /mnt/cvs/freebsd/usr/src/sys/kern/kern_shutdown.c:531
#3  0xc0299e82 in bwrite (bp=0xcc314d28)
at /mnt/cvs/freebsd/usr/src/sys/kern/vfs_bio.c:798
#4  0xc029b605 in vfs_bio_awrite (bp=0xcc314d28)
at /mnt/cvs/freebsd/usr/src/sys/kern/vfs_bio.c:1650
#5  0xc035390a in ffs_fsync (ap=0xe09cb474)
at /mnt/cvs/freebsd/usr/src/sys/ufs/ffs/ffs_vnops.c:258
#6  0xc0352a37 in ffs_sync (mp=0xc1f8d800, waitfor=2, cred=0xc150ae00, 
td=0xc0436000) at vnode_if.h:612
#7  0xc02afc9b in sync (td=0xc0436000, uap=0x0)
at /mnt/cvs/freebsd/usr/src/sys/kern/vfs_syscalls.c:138
#8  0xc025697c in boot (howto=256)
at /mnt/cvs/freebsd/usr/src/sys/kern/kern_shutdown.c:273
#9  0xc0256ff3 in panic ()
at /mnt/cvs/freebsd/usr/src/sys/kern/kern_shutdown.c:531
#10 0xc03af692 in trap_fatal (frame=0xe09cb62c, eva=0)
at /mnt/cvs/freebsd/usr/src/sys/i386/i386/trap.c:844
#11 0xc03af372 in trap_pfault (frame=0xe09cb62c, usermode=0, eva=776)
at /mnt/cvs/freebsd/usr/src/sys/i386/i386/trap.c:758
#12 0xc03aee60 in trap (frame=
---Type  to continue, or q  to quit---
  {tf_fs = 24, tf_es = 33554448, tf_ds = 16, tf_edi = -1067102624, tf_esi = 
812924928, tf_ebp = -526600584, tf_isp = -526600616, tf_ebx = -1037925756, tf_edx = 
193, tf_ecx = -526598752, tf_eax = 4, tf_trapno = 12, tf_err = 0, tf_eip = 
-1069900574, tf_cs = 8, tf_eflags = 78339, tf_esp = 812924928, tf_ss = 812924928}) at 
/mnt/cvs/freebsd/usr/src/sys/i386/i386/trap.c:445
#13 0xc039f548 in calltrap () at {standard input}:98
#14 0xc06327d6 in ?? ()
#15 0xc0567b8e in ?? ()
#16 0xc05681d1 in ?? ()
#17 0xc055ca70 in ?? ()
#18 0xc056a1d9 in ?? ()
#19 0xc0569e1b in ?? ()
#20 0xc0631b9d in ?? ()
#21 0xc062fec1 in ?? ()
#22 0xc021bc09 in spec_ioctl (ap=0xc0654e60)
at /mnt/cvs/freebsd/usr/src/sys/fs/specfs/spec_vnops.c:349
#23 0xc021b3a8 in spec_vnoperate (ap=0x0)
at /mnt/cvs/freebsd/usr/src/sys/fs/specfs/spec_vnops.c:123
#24 0xc02b8591 in vn_ioctl (fp=0xc1fe02d0, com=3223602724, data=0xe09cbc48, 
active_cred=0xc23b3b00, td=0xc1ef4d20) at vnode_if.h:488
#25 0xc02798f3 in ioctl (td=0xc1ef4d20, uap=0xe09cbd10) at file.h:247
#26 0xc03af9ba in syscall (frame=
  {tf_fs = 47, tf_es = 140574767, tf_ds = -1078001617, tf_edi = 33554946, tf_esi = 
-104118, tf_ebp = -1077938072, tf_isp = -526598796, tf_ebx = -1077938---Type 
 to continue, or q  to quit---
020, tf_edx = 0, tf_ecx = 0, tf_eax = 54, tf_trapno = 12, tf_err = 2, tf_eip = 
673858499, tf_cs = 31, tf_eflags = 12934, tf_esp = -1077938100, tf_ss = 47})
at /mnt/cvs/freebsd/usr/src/sys/i386/i386/trap.c:1033
#27 0xc039f59d in Xint0x80_syscall () at {standard input}:140
---Can't read userspace from dump, or kernel process---

(kgdb) q

Script done on Wed Jan 22 19:55:39 2003

Statement regarding FreeBSD release ISO images

[Scott Long]

All,

There seems to be some confusion created by choices that we made
for the 5.0 release regarding ISO image availability.  To refresh, from
FreeBSD 4.4 to 4.7, we made available 5 iso images for i386 and
alpha.  This consisted of a mini-disc1 that contained only the bits
needed for installing, a full disc1 that contained the mini-disc1
contents plus a collection of high-profile packages, disc2 which
contained a live filesystem plus more packages, and discs 3 and
4 which contained 1.2GB of even more packages.  Starting with
5.0, only 2 or three discs were made available for each architecture.
This included the normal mini-disc1, a disc1 containing packages
from the print-cdrom-packages.sh release script (this was not done
for pc98 and ia64), and a disc2 containing only the live filesystem.

The reasons for this change boil down to this: space and economics.
We have 5 architectures now, so mirroring nearly 3 GB of images
for all 5 becomes quite prohibitive for the donated space and
bandwidth that is our mirror system.  We are all grateful for their
service, so we try to show some consideration in return.

The other reason, economics, is that providing bascially a full
4-disc CD set for free download makes people less likely to buy
from our vendors.  The FreeBSD project would suffer greatly
without those vendors.  So again, we try to show them some
consideration.

Future 5.x releases will follow the same philosophy.  I'm not
leading the 4.x releases so I cannot speak for certain there,
though I suspect that they will follow the same route.

Thanks, and go buy some 5.0 CD's =-)

Scott Long
The Release Engineering Team


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: 4.7-amd cannot mount exports from 5.0-RELEASE

[Nicolas Kowalski]

Masafumi NAKANE <[EMAIL PROTECTED]> writes:

> I've been encountering the exact same problem past a few days.  My
> -CURRENT box is -CURRENT as of 01/18.

I have the same behaviour here.

Additionnal tests show that a Linux client running am-utils (6.0.7)
also hangs (same error message) when trying to mount shares from a
FreeBSD 5.0R server. No problems with autofs.

-- 
Nicolas


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message