David Xu wrote:
testl $PSL_VM,TF_EFLAGS(%esp) /* are we in vm86 mode? */
jz doreti_notvm86
cmpl$1,in_vm86call /* are we in a vm86 call? */
sorry for a bit OT, does anyone see this in_vm86call crazy global variable?
it prevents two CPUs to trap
--- Jonathan Lemon [EMAIL PROTECTED] wrote:
In article
local.mail.freebsd-current/[EMAIL PROTECTED]
you write:
sorry for a bit OT, does anyone see this in_vm86call crazy global variable?
it prevents two CPUs to trap into VM86 model :(
Um, unfortunately, this is by design. Most (all?)
On Fri, 5 Jul 2002, Jake Burkholder wrote:
Apparently, On Fri, Jul 05, 2002 at 05:43:26PM -0700,
Julian Elischer said words to the effect of;
Looking at i386/exception.s
one sees:
[...]
Now:
would it not make a lot of sense to put doreti immediatly after
calltrap: in
Thus spake David Xu [EMAIL PROTECTED]:
I don't know if FreeBSD can run DOS program, if it can, then one CPU running
DOS program can confuse another CPU which is running BIOS code because of this
global flags.
my current patch does not remove vm86_lock, it is still there, my orginal
On Sat, 6 Jul 2002, Andrew Gallatin wrote:
OK, current is really confusing me. When we are panic'ing and syncing
disks, how are we supposed to come back to the current thread which
caused the dump after we do an mi_switch() to allow an interrupt
thread to run?
The alpha seems to get stuck
Here are two files that make stateful configuration of world
building somewhat easier.
I expect that the way this will be used is to allow Paul, et. al.
the option of setting a default, and having the system ask users
if they want to live with Paul's default, or if they want to
select their own
On Sat, 2002-07-06 at 03:46, Garance A Drosihn wrote:
At 3:05 AM +0100 7/6/02, Paul Richards wrote:
Let's start with a premise: No-one running current is using
it for anything other than developing FreeBSD.
This is assumption is too limiting.
It shouldn't be. You're trying to defend a
Paul Richards wrote:
On Sat, 2002-07-06 at 03:46, Garance A Drosihn wrote:
At 3:05 AM +0100 7/6/02, Paul Richards wrote:
Let's start with a premise: No-one running current is using
it for anything other than developing FreeBSD.
This is assumption is too limiting.
It shouldn't be.
--- David Schultz [EMAIL PROTECTED] wrote:
Thus spake David Xu [EMAIL PROTECTED]:
I don't know if FreeBSD can run DOS program, if it can, then one CPU
running
DOS program can confuse another CPU which is running BIOS code because of
this
global flags.
my current patch does not
On Fri, Jul 05, 2002 at 10:45:41AM +0100, Paul Richards wrote:
I think we should add a target to make world that checks for the
existence of an old base install of Perl and removes it if it exists.
As a general principle, if we do things like remove code during -current
development then
On Sat, 2002-07-06 at 13:29, Ruslan Ermilov wrote:
On Fri, Jul 05, 2002 at 10:45:41AM +0100, Paul Richards wrote:
I think we should add a target to make world that checks for the
existence of an old base install of Perl and removes it if it exists.
As a general principle, if we do
--
Andrzej Kwiatkowski
tpinternet
unix system administrator
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Bruce Evans writes:
On Sat, 6 Jul 2002, Andrew Gallatin wrote:
OK, current is really confusing me. When we are panic'ing and syncing
disks, how are we supposed to come back to the current thread which
caused the dump after we do an mi_switch() to allow an interrupt
thread to
Julian Elischer writes:
On Sat, 6 Jul 2002, Andrew Gallatin wrote:
OK, current is really confusing me. When we are panic'ing and syncing
disks, how are we supposed to come back to the current thread which
caused the dump after we do an mi_switch() to allow an
On (2002/07/05 17:24), Sheldon Hearn wrote:
You and Paul are both pretty out there if you think -current users
will graciously accept a new world order in which ports linked
dymanically against system libraries won't work between a system upgrade
and the next port reinstall.
Sorry about the
On Sat, Jul 06, 2002 at 12:42:53PM +0100, Paul Richards wrote:
On Sat, 2002-07-06 at 03:46, Garance A Drosihn wrote:
At 3:05 AM +0100 7/6/02, Paul Richards wrote:
Let's start with a premise: No-one running current is using
it for anything other than developing FreeBSD.
This is
Thatis, after issuing
sudo boot0cfg -s 1 ad0 sudo halt -p
I see (on the serial console):
Additional TCP options:.
Starting background filesystem checks
Sat Jul 6 08:07:46 PDT 2002
FreeBSD/i386 (freebeast.catwhisker.org) (cuaa0)
login: Juboot() called on cpu#0
Waiting (max 60
On Sat, Jul 06, 2002 at 05:15:26AM -0700, David Xu wrote:
I don't know how DOS emulating program works, but if it let DOS
program run in VM86 mode, the in_vm86call global flag can prevent
one CPU to run VM86 BIOS call and another CPU run DOS VM86 code,
because it can not distinct which CPU
On Sat, 6 Jul 2002, Andrew Gallatin wrote:
Julian Elischer writes:
On Sat, 6 Jul 2002, Andrew Gallatin wrote:
OK, current is really confusing me. When we are panic'ing and syncing
disks, how are we supposed to come back to the current thread which
caused the dump after we do an
Hi all,
If anyone's still looking at the /tmp on md stuff, I've thrown together a
workaround/solution based on the mount_md idea. Okay, I know that using
a shell-script for a mount program may be seen as a Bad Thing and I'm not
sure I want to broadcast my duff shell-programming for all to see,
David Wolfskill writes:
syncing disks...
done
And at that point, nothing further. I'm able to ping the machine, but I
didn't see the (usual) mention of an attempt to shut power off via ACPI.
(Sometimes that would work; sometimes it would time out, but this is the
first time I
Bruce Evans writes:
On Sat, 6 Jul 2002, Andrew Gallatin wrote:
Julian Elischer writes:
On Sat, 6 Jul 2002, Andrew Gallatin wrote:
OK, current is really confusing me. When we are panic'ing and syncing
disks, how are we supposed to come back to the current thread which
On Sat, Jul 06, 2002 at 09:08:39PM +0100, Chris Hedley wrote:
Hi all,
If anyone's still looking at the /tmp on md stuff, I've thrown together a
workaround/solution based on the mount_md idea. Okay, I know that using
a shell-script for a mount program may be seen as a Bad Thing and I'm not
On Sat, 6 Jul 2002, Bernd Walter wrote:
I abused diskless_mount for md filesystems:
Either solution's preferable to my first inelegant attempt at an rc.tmp
involving making a complete pigs' ear of rc! :)
[351]cicely5 cat /etc/rc.md
DEV=`mdconfig -a -t swap -s 1400M`
disklabel -r -w ${DEV}
Sheldon Hearn wrote:
On (2002/07/05 17:24), Sheldon Hearn wrote:
You and Paul are both pretty out there if you think -current users
will graciously accept a new world order in which ports linked
dymanically against system libraries won't work between a system upgrade
and the next port
looks to me like the idle thread is running..
what does 'ps' show from ddb
and
show locks
On Sat, 6 Jul 2002, Andrew Gallatin wrote:
David Wolfskill writes:
syncing disks...
done
And at that point, nothing further. I'm able to ping the machine, but I
didn't see the
Hi,
I have a ASUS A7V333 motherboard. Thats a UP motherboard vith a VIA KT333
chipset and a AMD XP Processor.
There is a setting in BIOS where you can select Interrupt Mode between
APIC an PIC, default APIC.
What happends if i set options APIC_IO in the kernel config on a UP
system with APIC
In message: [EMAIL PROTECTED]
Paul Richards [EMAIL PROTECTED] writes:
: A 'sysclean' target would be the same in my mind. If you're within
: spec of what -current supports then running that target shouldn't hose
: you. If you're outside spec then you need to take your own precautions.
Try again with new vfs_subr.c, vfs_bio.c
Latest updates seem to have fixed it for me.
(Thanks Jeff)
Cheers,
Jerry Hicks
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Well with various hints from here and there I have fixed
the ^Z/fg problem (at least it seems fixed to me and others that
have tested) This basically leaves only one outstanding
problem that I know of which is a problem that Warner has with a
particular progam. (This may also be fixed but I
At 12:42 PM +0100 7/6/02, Paul Richards wrote:
On Sat, 2002-07-06 at 03:46, Garance A Drosihn wrote:
At 3:05 AM +0100 7/6/02, Paul Richards wrote:
Let's start with a premise: No-one running current is using
it for anything other than developing FreeBSD.
This is assumption is too
On 5 Jul, Georg-W. Koltermann wrote:
Am Mi, 2002-07-03 um 17.31 schrieb David O'Brien:
On a 27-June-2002 23:02:00 UTC system (just before ipfw2 went in,
pre-KSE3), dump will not complete dumping more than 5GB. At that point
it stops responding properly to ^T, which should give DUMP: 47.52%
Hi,
The uplcom(4) driver which supports USB-to-serial converters lists
support for the following devices which use the Prolific PL-2303
chipset.
Man page for uplcom driver:
http://www.freebsd.org/cgi/cvsweb.cgi/src/share/man/man4/uplcom.4
Supported cables:
ATEN UC-232A
On 5 Jul, Georg-W. Koltermann wrote:
Am Mi, 2002-07-03 um 17.31 schrieb David O'Brien:
On a 27-June-2002 23:02:00 UTC system (just before ipfw2 went in,
pre-KSE3), dump will not complete dumping more than 5GB. At that point
it stops responding properly to ^T, which should give DUMP: 47.52%
To those of you who provided me with UMA statistics; Thank you! The
information was enlightening. The current bucket sizes aren't as bad as I
had originally anticipated. I think I need to rework the mechanism by
which the statistics are collected to get more interesting results, but
for now
35 matches
Mail list logo