Jonthan,
I just use DOS program as an example, for any program, if it wants to go
into VM86 mode, it is very easy, just calls i386_vm86() to initailize its
VM86 pcb extension, setups some memory area, then call sigreturn() to turn
into VM86 mode.
I think global in_vm86call flags is a bug unde
On Sat, 6 Jul 2002, Jeff Roberson wrote:
> jeff2002/07/06 23:39:37 PDT
>
> Modified files:
> sys/toolsvnode_if.awk
> Log:
>- Use 'options DEBUG_VFS_LOCKS' instead of the DEBUG_ALL_VFS_LOCKS
> environment variable to enable the lock verifiction code.
>
> Revi
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 wha
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:
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 http://www.aten.com.tw
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:
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
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 don'
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
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 precaut
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
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
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 ne
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 ${D
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'
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 t
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 tim
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,
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 afte
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
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 seco
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.
> >
> > Thi
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 abou
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 all
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
> > thr
--
Andrzej Kwiatkowski
tpinternet
unix system administrator
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
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
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
--- 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 pa
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 sh
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
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 d
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
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 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 af
--- Jonathan Lemon <[EMAIL PROTECTED]> wrote:
> In article
>
[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?) BIOSen code are
>
36 matches
Mail list logo
