On Wed, Apr 24, 2002 at 01:29:49PM -0400, John Baldwin wrote:
>
> On 24-Apr-2002 Christian Flügel wrote:
[snip]
> > make buildworld: works ok.
> > make buildkernel: works ok.
> > copy GENERIC.hints to /boot/device.hints: works ok.
> > make installkernel: stops with error: "kldxref not found"
>
cjc> However, I have (and think I posted somewhere?) some kludgey
cjc> patches that build kldxref(8) as a cross-tool so that it works
cjc> for 4.5 to 5.0 upgrades. But it's not really the "right" fix
cjc> (since it is not a true cross-tool), so I haven't committed it.
Can we add kldxref(8) to bo
Lamont Granquist wrote:
> I just did a cvsup today to -current on a GENERIC+SMP kernel and my uptime
> is showing 8909 days. Motherboard is an ASUS A7M266D with the (possibly
> buggy) 1004 BIOS.
I'm really surprised... I didn't realize ASUS made PDP-11
compatibles. 1977... I also didn't realize
On Sat, Apr 27, 2002 at 03:45:49PM -0700, Lamont Granquist wrote:
>
> I just did a cvsup today to -current on a GENERIC+SMP kernel and my uptime
> is showing 8909 days. Motherboard is an ASUS A7M266D with the (possibly
> buggy) 1004 BIOS.
I'm seeing this too, but I expect it's probably caused b
--- Kris Kennaway <[EMAIL PROTECTED]> wrote:
> I'm seeing this too, but I expect it's probably caused by out of sync
> kernel and world. I haven't yet been able to test this hypothesis.
Just wondering, could this be because of the recent changes made to the
time code by phk? (uh oh, hiten.. you
On Wed, 24 Apr 2002 20:08:56 +0900,
Seigo Tanimura <[EMAIL PROTECTED]> said:
Seigo> I am now working on locking down a socket. (I have heard that Jeffrey
Seigo> Hsu is also doing that, but I have never seen his patch. Has anyone
Seigo> seen that?) My first milestone patch is now available at:
%%%
: iedowse 2002/04/28 03:24:38 PDT
:
: Modified files:
:usr.sbin/pstat pstat.8 pstat.c
: Log:
: Oops, remove references to NLOCKED and NWANTED, now that they no
: longer exist.
%%%
I beleive this unbreaks pstat. :-)
-- Hiten
_
On Thu, 25 Apr 2002 11:04:32 -0700 (PDT),
[EMAIL PROTECTED] (Jeffrey Hsu) said:
hsu> If you compare the two approaches, the BSD/OS approach is simpler
hsu> because it is coarse. You're confusing finer grain locking with
hsu> better.
Well, maybe my patch just seems more fine-grained than BSD/O
On Sun, 28 Apr 2002, Seigo Tanimura wrote:
> On Wed, 24 Apr 2002 20:08:56 +0900,
> Seigo Tanimura <[EMAIL PROTECTED]> said:
>
> Seigo> I am now working on locking down a socket. (I have heard that Jeffrey
> Seigo> Hsu is also doing that, but I have never seen his patch. Has anyone
> Seigo> se
On Sun, 28 Apr 2002, Kris Kennaway wrote:
> On Sat, Apr 27, 2002 at 03:45:49PM -0700, Lamont Granquist wrote:
> >
> > I just did a cvsup today to -current on a GENERIC+SMP kernel and my uptime
> > is showing 8909 days. Motherboard is an ASUS A7M266D with the (possibly
> > buggy) 1004 BIOS.
>
(Matt gets CC'd because he's just unlucky :-)
This system is (as always) a pxeboot'd nfsroot'd dual processor box. This
time, however, it's running straight GENERIC from the main tree instead of
the MAC branch. The box network boots, does a buildkernel -j 8, and then
reboots. It currently has
On Sun, Apr 28, 2002 at 09:31:32AM -0400, Robert Watson wrote:
>
> On Sun, 28 Apr 2002, Kris Kennaway wrote:
>
> > On Sat, Apr 27, 2002 at 03:45:49PM -0700, Lamont Granquist wrote:
> > >
> > > I just did a cvsup today to -current on a GENERIC+SMP kernel and my uptime
> > > is showing 8909 days.
As usual, GENERIC -CURRENT head from last night, from the main tree.
Dual-proc SMP box netbooted using PXE. System usually boots, does a
buildkernel -j 8 over NFS, then reboots and repeats. This time it didn't.
I actually have two boxes doing this, which does seem to double the rate
of panic
It could be this was fixed by Alan's commit last night to fix locking in
VM. In any case, here's the panic anyway. This is from box2, again,
-current from last night, nfs root via pxeboot, GENERIC, spinning {boot,
buildkernel}. I'll update the two boxes when I get back from the hospital
later
Hello,
Yesterday installed current from a snapshot and instantly updated it via
CVS. Today i noticed a strange file in /usr with the name @LongLink.
# cat /usr/@LongLink
ports/java/jdk13/files/patch-..::src::solaris::native::com::sun::media::sound::engine::HAE_API_BSDOS_Capture.c
I containes a
On Sun, 28 Apr 2002, Robert Watson wrote:
> Heh. I'm seeing this during the uptime announcement from the kernel after
> kernel shutdown, which means userland isn't involved:
>
> Uptime: 8909d8h59m52s
>
> Given that the uptime of the box was well less than a minute, that seems a
> little extreme.
:(Matt gets CC'd because he's just unlucky :-)
:
:This system is (as always) a pxeboot'd nfsroot'd dual processor box. This
:time, however, it's running straight GENERIC from the main tree instead of
:the MAC branch. The box network boots, does a buildkernel -j 8, and then
:reboots. It current
--- Matthew Dillon <[EMAIL PROTECTED]> wrote:
> No idea, but the last time someone had a weird swap issue it
> turned out that they had swapon'd the same swap partition twice.
> The system's checks are not sufficient if you swapon the same device
> from different mounts. So check
Hello,
On a fresh current i get this
# truss /bin/echo hello
truss: cannot open /proc/13245/mem: No such file or directory
truss: cannot open /proc/curproc/mem: No such file or directory
Greetings,
Richard.
An OS is like swiss cheese, the bigger it is, the more holes you get!
To Un
On Sun, 28 Apr 2002, Richard Arends wrote:
RA>Hello,
RA>
RA>On a fresh current i get this
RA>
RA># truss /bin/echo hello
RA>truss: cannot open /proc/13245/mem: No such file or directory
RA>truss: cannot open /proc/curproc/mem: No such file or directory
You need to mount procfs.
harti
RA>
R
On Sun, 28 Apr 2002, Hiten Pandya wrote:
> Talking about doing something twice, it reminds me, that there is the same
> type of issue with the md devices, which when they are destroyed twice or
> thrice, they panic the kernel.
Re.v.108 of kern_conf.c fixes similar bugs.
Bruce
To Unsubscribe:
On 28-Apr-2002 (17:56:47/GMT) Harti Brandt wrote:
> RA>On a fresh current i get this
> RA># truss /bin/echo hello
> RA>truss: cannot open /proc/13245/mem: No such file or directory
> RA>truss: cannot open /proc/curproc/mem: No such file or directory
> You need to mount procfs.
Mee too messa
On Sat, 27 Apr 2002, Lamont Granquist wrote:
>
> I just did a cvsup today to -current on a GENERIC+SMP kernel and my uptime
> is showing 8909 days.
cvsup again, this problem should be fixed now.
--
"We have known freedom's price. We have shown freedom's power.
And in this grea
On Sat, 27 Apr 2002, Ruslan Ermilov wrote:
> That was probably a local problem on one of the Brian's fast machines
> where I initially attempted to finally test my patch (unsynched cvsup
> update?). Sorry for the false alarm, I can't check it right now anyway.
You probably caught things
I asked for same problem some time ago to this list and to ports
without answer, anyone out there running bochs on current?
I have installed bochs from ports but I was unable to start any
sample image from support site, all fails with same error:
Event type: PANIC
Device: [APIC0]
Message: [APIC0
On Sun, Apr 28, 2002 at 03:05:47AM -0700, Hiten Pandya wrote:
> --- Kris Kennaway <[EMAIL PROTECTED]> wrote:
> > I'm seeing this too, but I expect it's probably caused by out of sync
> > kernel and world. I haven't yet been able to test this hypothesis.
>
> Just wondering, could this be because
On Sun, 28 Apr 2002, Harti Brandt wrote:
> You need to mount procfs.
Oops youre right... Why isn't it listed in /etc/fstab???
Greetings,
Richard.
An OS is like swiss cheese, the bigger it is, the more holes you get!
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freeb
On Sun, Apr 28, 2002 at 07:46:27PM +0200, Richard Arends wrote:
> Hello,
>
> On a fresh current i get this
>
> # truss /bin/echo hello
> truss: cannot open /proc/13245/mem: No such file or directory
> truss: cannot open /proc/curproc/mem: No such file or directory
procfs is not mounted by d
On Sun, Apr 28, 2002 at 08:11:58PM +0200, Riccardo Torrini wrote:
> On 28-Apr-2002 (17:56:47/GMT) Harti Brandt wrote:
>
> > RA>On a fresh current i get this
> > RA># truss /bin/echo hello
> > RA>truss: cannot open /proc/13245/mem: No such file or directory
> > RA>truss: cannot open /proc/curp
On Sun, 28 Apr 2002, Kris Kennaway wrote:
> procfs is not mounted by default.
New to current (one day old baby :-), so didn't know that. sorry()
Why isn't it mounted by default??
Greetings,
Richard.
An OS is like swiss cheese, the bigger it is, the more holes you get!
To Unsubscribe:
On Sun, 28 Apr 2002, Richard Arends wrote:
> On Sun, 28 Apr 2002, Kris Kennaway wrote:
>
> > procfs is not mounted by default.
>
> New to current (one day old baby :-), so didn't know that. sorry()
>
> Why isn't it mounted by default??
I believe DES has a largely rewritten version of truss t
--
>>> Rebuilding the temporary build tree
--
>>> stage 1: bootstrap tools
--
>>> stage 2: cleaning up the object tree
On Sun, Apr 28, 2002 at 08:49:55PM +0200, Richard Arends wrote:
> On Sun, 28 Apr 2002, Kris Kennaway wrote:
>
> > procfs is not mounted by default.
>
> New to current (one day old baby :-), so didn't know that. sorry()
>
> Why isn't it mounted by default??
Numerous and horrendous security vuln
On Sun, 28 Apr 2002, Matthew Dillon wrote:
>
> :(Matt gets CC'd because he's just unlucky :-)
> :
> :This system is (as always) a pxeboot'd nfsroot'd dual processor box. This
> :time, however, it's running straight GENERIC from the main tree instead of
> :the MAC branch. The box network boots,
On Sun, 28 Apr 2002, Robert Watson wrote:
> The rationale for disabling procfs is that its functionality is largely
> redundant to existing sysctls and debugging mechanisms, and that it has
> been, and will likely continue to be, an important source of system
> security holes.
Okay disable it :-
On Sun, 28 Apr 2002, Richard Arends wrote:
> > I think truss is one of the last stragglers that relies on it --
> > the other is 'ps -e', which gropes through the memory of each process to
> > dig out the environmental variables. This requires that ps both have
> > substantial privilege, and th
unsuscribe
freebsd-current
On Sun, 28 Apr 2002, Robert Watson wrote:
> BTW, 5.0 will also allow (once we commit the MAC framework from the
> TrustedBSD Project) kernel modules to tweak process visibility protections
> in the kernel at runtime. For example, you can kldload a
> mac_seeotheruids.ko policy module, which can l
On Sun, 28 Apr 2002, Richard Arends wrote:
> On Sun, 28 Apr 2002, Robert Watson wrote:
>
> > BTW, 5.0 will also allow (once we commit the MAC framework from the
> > TrustedBSD Project) kernel modules to tweak process visibility protections
> > in the kernel at runtime. For example, you can kld
On Sun, Apr 28, 2002 at 03:59:44PM -0400, Robert Watson wrote:
[snip]
> In FreeBSD 5.0, all this information is exported from the kernel using the
> sysctl() interface, which provides much more information gating, and
> flexibe policy controls. This exists in part in 4.x, but not completely.
>
On Sun, 28 Apr 2002, Kris Kennaway wrote:
> On Sat, Apr 27, 2002 at 03:45:49PM -0700, Lamont Granquist wrote:
> >
> > I just did a cvsup today to -current on a GENERIC+SMP kernel and my uptime
> > is showing 8909 days. Motherboard is an ASUS A7M266D with the (possibly
> > buggy) 1004 BIOS.
>
>
On Sun, 28 Apr 2002, Crist J. Clark wrote:
> On Sun, Apr 28, 2002 at 03:59:44PM -0400, Robert Watson wrote:
> [snip]
>
> > In FreeBSD 5.0, all this information is exported from the kernel using the
> > sysctl() interface, which provides much more information gating, and
> > flexibe policy contr
--- Lamont Granquist <[EMAIL PROTECTED]> wrote:
> > I'm seeing this too, but I expect it's probably caused by out of sync
> > kernel and world. I haven't yet been able to test this hypothesis.
>
> I don't think so, I did:
>
> [...]
Just cvsup again and rebuild your kernel, and that will fix the
On Sun, 28 Apr 2002, Hiten Pandya wrote:
> --- Lamont Granquist <[EMAIL PROTECTED]> wrote:
> > > I'm seeing this too, but I expect it's probably caused by out of sync
> > > kernel and world. I haven't yet been able to test this hypothesis.
> >
> > I don't think so, I did:
> >
> > [...]
>
> Jus
be
fixed?
su-2.05# make release CHROOTDIR=/disk2/r
BUILDNAME=jmb-citrus-snap-20020428 CVSROOT=/home/ncvs
. . . snip . . .
===> usr.bin/size
install -c -s -o root -g wheel -m 555 size /disk2/r/usr/libexec/aout
===> usr.bin/smbutil
install -c -s -o root -g wheel -m 555 smbutil /di
Is there any way to prevent the system from reacting to the lid
being closed? At this time when I close the lid I get the following
messages:
ed1: detached
pccard: card disabled, slot 0
Then after re-opening, I have to press the power button for the
system to wake up.
I'm using Thinkpad A22m.
On Sun, Apr 28, 2002 at 05:11:14PM -0400, Robert Watson wrote:
>
> On Sun, 28 Apr 2002, Crist J. Clark wrote:
>
> > On Sun, Apr 28, 2002 at 03:59:44PM -0400, Robert Watson wrote:
> > [snip]
> >
> > > In FreeBSD 5.0, all this information is exported from the kernel using the
> > > sysctl() inter
I also get an almost identical fault on crash1 involving mdconfig as
opposed to sh:
ray irq 10
NFS ROOT: 192.168.50.1:/cboss/devel/nfsroot/crash1.cboss.tislabs.com
8.50.10 BroadcasP-Address 192.16
t 192.168.50.255
Fatal trap 12: page fault while in kernel mode
cpuid = 1; lapic.id = 0100
faul
:It currently has no swap started at all, which is one reason I was rather
:puzzled to see this panic:
:
:192.168.50.1:/cboss/devel/nfsroot/crash2.cboss.tislabs.com / nfs ro 0
: 0
:proc/proc procfs rw 0 0
:/dev/ad0s1e /mntufs rw 0
On Sun, 28 Apr 2002, Crist J. Clark wrote:
> > Hmm. I'd forgotten that the setgid kmem was removed in 4.x; I was
> > probably thinking of top, which still is setgid in -STABLE. You'll find
> > however, that -e won't work without setgid kmem being turned on.
>
> '-e' for ps(1) seems to work fi
The usual setup: dual process -CURRENT box (crash2) from an hour or two
ago, network booted using pxeboot, with an NFS root. System boots, builds
a kernel, and reboots, repeating until panic. Doesn't take long :-).
This one is weird, as with many of them I suppose, and could mean possible
memo
If I apply the attached diff to the kern_malloc.c, backing out a portion
of kern_malloc.c:1.99, the rate of panics plummets. Previously, I could
have a box panic within five minutes of getting the crash boxes spinning.
Now I've been going for about 40 minutes without any perceived failures
(i.e
I'm trying to build -current from today (4/28/2002) on a -stable box with a
kernel/world from April 25th.
It blows up in xlint:
==
cc -O -pipe -I. -I/c/ken/perforce/FreeBSD-ken/src/usr.bin/xlint/lint1
-I/c/ken/perforc
54 matches
Mail list logo
