> 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.
I agree that we may need a tool to do this, but I don't agree that it
gets done automatically by "make world".
> As a general principle, if we do things like
In message <[EMAIL PROTECTED]>, Alex Zepeda wrote:
>On Fri, Jul 05, 2002 at 04:01:08PM +0900, Takanori Watanabe wrote:
>
>> We already have a way to use your own bytecode without recompiling.
>> Simply put your AML file to /boot/acpi_dsdt.aml and add 'acpi_dsdt_load="YES
>"
>> to your /boot/loade
On Fri, Jul 05, 2002 at 05:08:24AM -0700, Terry Lambert wrote:
> Takanori Watanabe wrote:
> > +.Sh OVERRIDING YOUR BIOS BYTECODE
> > +ACPI interprets bytecode named AML, ACPI Machine Language, provided by BIOS
> > +vendor as memory image at boot time. Sometimes, the AML code contains
> > +problem
On (2002/07/05 05:22), Terry Lambert wrote:
> > This would not fit in with the rest of the world target, which doesn't
> > clean out stale headers, stale libraries or stale binaries.
> > Special-casing certain things will surprise people.
>
> Headers and libraries arguably should be removed, so
On Fri, 2002-07-05 at 16:24, Sheldon Hearn wrote:
> On (2002/07/05 05:22), Terry Lambert wrote:
>
> > > This would not fit in with the rest of the world target, which doesn't
> > > clean out stale headers, stale libraries or stale binaries.
> > > Special-casing certain things will surprise people
At 11:16 AM +0100 7/5/02, Paul Richards wrote:
>On Fri, 2002-07-05 at 10:52, Sheldon Hearn wrote:
> > On (2002/07/05 10:45), Paul Richards wrote:
> > > I'd like to resurrect it's original meaning and add code
> > > to clean out old versions of Perl.
> >
> > This would not fit in with the rest
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% done,
> finished in 1:19". At the 5
On Thu, Jul 04, 2002 at 01:34:42PM -0400, Chuck Robey wrote:
> >> The K7 had a broken on-board usb (the AMD
> >> chipset had a PCI contention bug for the usb port, so the tin back panel
> >> of the board blocked out the usb, and the K7 came with a PCI usb card,
> >> which ate up one of your PCI sl
On Fri, Jul 05, 2002 at 06:48:56PM +0200, 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 properl
On Thu, Jul 04, 2002 at 10:09:52PM +0900, Mitsuru IWASAKI wrote:
> My analysis was finished. Please try this patch.
>
> --- exfield.c-Thu Jul 4 21:54:24 2002
> +++ exfield.c Thu Jul 4 21:55:02 2002
> @@ -200,7 +200,7 @@
> /* Handle both ACPI 1.0 and ACPI 2.0 Integer widths */
>
[ erdgeist@bauklotz:~/Coding ]
20:59:14 $> less test.c
int main( ) {
char a;
a = getchar();
return a;
}
[ erdgeist@bauklotz:~/Coding ]
20:59:19 $> ./test
^Z
[1]+ Stopped ./test
[ erdgeist@bauklotz:~/Coding ]
20:59:26 $> bg
bash: bg: bg background job?
[ erdgeist@ba
Julian Elischer wrote:
> At this time I have no information on any apps that fail to work (that did
> work before KSE).
>
> The signal flakiness is still present but at least people can get work
> done. I will work on this next (though signal experts are welcome to
> try their hand as well.. (in
this is a bug in the KSE signal handling..
peter and I are looking at it at the moemnt. it is a known problem.
On Fri, 5 Jul 2002, Dirk Engling wrote:
>
> [ erdgeist@bauklotz:~/Coding ]
> 20:59:14 $> less test.c
> int main( ) {
>char a;
>
>a = getchar();
>
>return a;
> }
> [ er
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.
>
> If you want to clean out crap
Garance A Drosihn wrote:
> While I agree there should be some automatic way to get rid
> of old cruft (or at least to list it), I do not think that it
> should be part of installworld or installkernel. All that
> any such step can do is find things which "it does not expect"
> to be there, but it
On Fri, Jul 05, 2002 at 03:33:08PM -0700, Terry Lambert wrote:
> Others: I think the flaw in your idea is that you aren't
> really running -current, so why the heck aren't you just
> running -stable, instead of pretending to run -current?
Of course by this argument, we wouldn't be running -stable
At 3:33 PM -0700 7/5/02, Terry Lambert wrote:
>
>So, to summarize:
>
Let me summarize my own position.
There are a number of files which installworld does install. After
an installworld is done, there may be a number of files on a person's
hard disk which were not put there by the most recent i
Garance A Drosihn wrote:
> At 3:33 PM -0700 7/5/02, Terry Lambert wrote:
> >So, to summarize:
> >
>
> Let me summarize my own position.
I was summarizing both. It's not really necessary to summarize a
position you've already taken... that's "reiterating". 8-) 8-).
You want a one sentence summ
Looking at i386/exception.s
one sees:
###
.globl alltraps
.type alltraps,@function
alltraps:
pushal
pushl %ds
pushl %es
pushl %fs
alltraps_with_regs_pushed:
mov $KDSEL,%ax
mov %ax,%ds
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 the same file
> so that one could follow t
On Sat, 2002-07-06 at 01:07, Garance A Drosihn wrote:
> At 3:33 PM -0700 7/5/02, Terry Lambert wrote:
> >
> >So, to summarize:
> >
>
> Let me summarize my own position.
>
> There are a number of files which installworld does install. After
> an installworld is done, there may be a number of fil
÷ Fri, 05.07.2002, × 06:39, Terry Lambert ÎÁÐÉÓÁÌ:
> > Loader?
> > ie on shutdown write a list of permissions etc into a file which the
> > loader can slurp up next boot and shove into the kernel and be parsed.
>
> This really doesn't work very well. You end up with two sets of
> data. Having
On Fri, Jul 05, 2002 at 03:29:13PM +0200, Dag-Erling Smorgrav wrote:
> Bernd Walter <[EMAIL PROTECTED]> writes:
> > cicely10 is an alpha running -current from 3. Jul.
> > The kernel is a day younger.
>
> What does 'ident /usr/sbin/sshd | grep monitor' say?
[51]cicely10> ident /usr/sbin/sshd | gr
Bernd Walter <[EMAIL PROTECTED]> writes:
> cicely10 is an alpha running -current from 3. Jul.
> The kernel is a day younger.
What does 'ident /usr/sbin/sshd | grep monitor' say?
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe free
On 5 Jul 2002, Vladimir B. Grebenschikov wrote:
> May be same mechanism as hints, like:
> hint.sio.0.mode=0622
As long as we are throwing out ideas: Aside from the fact that
it's broken and at the moment wouldn't exactly DTRT, I always
figured a type of mount_unionfs() with the older filesyste
On Fri, Jul 05, 2002 at 11:29:30AM +0100, Mark Murray 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.
>
> I agree that we may need a tool to do this, but I don't agree that it
> gets done automat
the following patch can fix the bug, but for KSE programs, it may not be a
best solution, KSE programs signal handling is on going...
--- kern_synch.cWed Jul 3 17:15:20 2002
+++ kern_synch.c.newSat Jul 6 10:36:22 2002
@@ -537,8 +537,7 @@
PROC_LOCK(p);
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.
People running -current are doing it to test the latest builds.
What they *do* to test it is their busine
- Original Message -
From: "Julian Elischer" <[EMAIL PROTECTED]>
To: "Peter Wemm" <[EMAIL PROTECTED]>
Cc: "FreeBSD current users" <[EMAIL PROTECTED]>
Sent: Saturday, July 06, 2002 8:43 AM
Subject: i386 trap code
>
> Looking at i386/exception.s
> one sees:
> ###
- Original Message -
From: "Julian Elischer" <[EMAIL PROTECTED]>
To: "Peter Wemm" <[EMAIL PROTECTED]>
Cc: "FreeBSD current users" <[EMAIL PROTECTED]>
Sent: Saturday, July 06, 2002 8:43 AM
Subject: i386 trap code
>
> Looking at i386/exception.s
> one sees:
> ###
NetBSD has a mtree.obsolete. Seems like that might not be a bad way
to solve this generically.
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Hi Julian,
When I panic an alpha these days, I end up with the random_kthread
spinning on the cpu stuck in msleep, and I never get the disks sync'ed
(or, if I disable sync'ing, I never get through a dump):
panic: vm_page_wakeup: page not busy!!!
panic
Stopped at Debugger+0x34: zapnot v0,
On Fri, Jul 05, 2002 at 06:46:05PM +0900, Takanori Watanabe wrote:
> Would you review this description?
How about:
--- acpi.4.orig Thu Jun 13 02:50:06 2002
+++ acpi.4 Fri Jul 5 21:16:59 2002
@@ -258,10 +258,35 @@
bus/children scan of the namespace.
The ACPI CA code will still
know abou
Steve Kargl writes:
> On Fri, Jul 05, 2002 at 11:43:59PM -0400, Andrew Gallatin wrote:
> >
> > Any ideas? Are people able to get crashdumps on UP SCSI x86s?
> >
>
> Yes. I can get dumps on an ahc (adaptec 2940) on a UP x86 box.
>
> Kernel was built with July 4th current sources.
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 running various sorts of kernel
processes, but
On 6 Jul, Paul Richards wrote:
> Let's start with a premise: No-one running current is using it for
> anything other than developing FreeBSD.
>
> Given that premise, then there shouldn't be anything in /usr outside of
> /usr/local, that wasn't put there by make world. Likewise the same
> should
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
single threaded, and the vm86 code shares the entire ISA hole
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?
>
It depends.
th
put a breakpoint at msleep+0x290
then continue..
sprinkle a few breakpoints at locations you think other processes ahould
be hitting if they were to be running..
On Fri, 5 Jul 2002, Andrew Gallatin wrote:
>
> Hi Julian,
>
> When I panic an alpha these days, I end up with the random_kthread
>
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
40 matches
Mail list logo
