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/loader.conf
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 that is
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 as to
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 of the
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 5GB
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 slots.
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 properly to
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?
[
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 fact
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;
}
[
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 left
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 would
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
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 summary
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 the
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 files on a
÷ 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 done
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 | grep
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
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 filesystem
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 automatically
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
- 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
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
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,
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 be
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?) BIOSen code are
single threaded, and the vm86 code
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.
the
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
39 matches
Mail list logo
