On Sat, Jun 17, 2000 at 01:56:11PM +0900, Mitsuru IWASAKI wrote:
I think OS-initiated S4 (hibernation) in FreeBSD has enough advantages
because we can do `Save-to-Disk' anywhere even on non-laptop machines
which BIOS doesn't support hibernation.
FreeBSD supports crash dump facility here, so
At 16:02 -0700 18/6/00, Greg Lehey wrote:
What do people think about adding a -e option to umount(8) to eject a
removable medium where possible?
What's special about mounted devices? I'd prefer to see an eject command
which attempts to unmount the device if it's mounted.
--
Bob Bishop
In [EMAIL PROTECTED] Ollivier Robert [EMAIL PROTECTED]
wrote:
roberto 2000/06/18 16:10:20 PDT
Modified files:
usr.sbin/ancontrol ancontrol.c
Log:
Fix potential buffer overflows (even if ancontrol is not setuid).
Submitted by: Aaron Campbell [EMAIL PROTECTED]
On 19-Jun-00 Brandon D. Valentine wrote:
On Mon, 19 Jun 2000, Bob Bishop wrote:
ejected. I know nothing about what happens when I hit the eject button
on a CDROM drive. Anyone care to speculate on if that's a reasonable
thing to implement?
I think this sort of stuff should be handled by
On Mon, Jun 19, 2000 at 02:53:45 -0400, Brandon D. Valentine wrote:
On Mon, 19 Jun 2000, Bob Bishop wrote:
What's special about mounted devices? I'd prefer to see an eject command
which attempts to unmount the device if it's mounted.
What'd be really spiffy is if when I hit the eject
In [EMAIL PROTECTED], Luoqi Chen wrote:
In [EMAIL PROTECTED], Luoqi Chen wrote:
It is not the loader's job to detect the underlying
hardware configuration.
I disagree. I would like to tell which machine I am booting on to
choose an appropriate kernel.
Eventually (it may take
That's a cool idea, but unfortunately, it won't work with any hardware I
know of.
In order for that to work, the CDROM drive would have to generate an AEN
(Asynchronous Event Notification) and send it to the controller, which
would have to be capable of functioning as a target as well as
On Mon, Jun 19, 2000 at 00:27:35 -0700, Mike Smith wrote:
That's a cool idea, but unfortunately, it won't work with any hardware I
know of.
In order for that to work, the CDROM drive would have to generate an AEN
(Asynchronous Event Notification) and send it to the controller, which
It seems Mike Smith wrote:
That's a cool idea, but unfortunately, it won't work with any hardware I
know of.
In order for that to work, the CDROM drive would have to generate an AEN
(Asynchronous Event Notification) and send it to the controller, which
would have to be capable of
Just a moment. You talk about doing a `Save-to-Disk' (incl.
system halt), turning power off, maybe adding some hardware or
moving the machine to another location, then switching on again,
restoring the system context, and the machine will proceed as if
nothing had happened, do you?
I
On 18 Jun, Donn Miller wrote:
Anyone try to compile the kernel with an optimization higher than -O,
such as -Os or -O2? For example, when I compile my kernel with -Os, I
FreeBSD 5.0-CURRENT #2: Fri Jun 16 17:49:32 CEST 2000
COPTFLAGS= -Os -march=pentiumpro -pipe -Wall -funroll-loops
A word of advice for those who use modules:
If you've recompiled the kernel with -O and the system still won't boot, be
sure to set CFLAGS="-O -pipe" in /etc/make.conf so that your modules are
also compiled with -O. A -O kernel with -O2 modules _doesn't_ work (on my
system anyway).
Now that
I've ported the NetBSD fsck wrapper to compile and run under FreeBSD.
Its probably still very rough, but I'm going to spend the next few
days tidying it up. I have also modified our fsck (and renamed it
fsck_ffs) to fit this new framework.
The source tarball can be found at:
[trimmed cc: list, now including only -current]
On Sun, Jun 18, 2000 at 11:54:51PM -0400, Francisco Reyes wrote:
Also speaking from my own experience I would have expected
something like this to be part of the system and would have
never even looked for a port.
And you'd find it, at least
On 19-Jun-00 Jacques A . Vidrine wrote:
[trimmed cc: list, now including only -current]
On Sun, Jun 18, 2000 at 11:54:51PM -0400, Francisco Reyes wrote:
Also speaking from my own experience I would have expected
something like this to be part of the system and would have
never even looked
Hi,
From: Bjoern Fischer [EMAIL PROTECTED]
Subject: Re: ACPI project progress report
Date: Mon, 19 Jun 2000 07:01:44 +0200
Message-ID: [EMAIL PROTECTED]
Just a moment. You talk about doing a `Save-to-Disk' (incl. system halt),
turning power off, maybe adding some hardware or moving the
imp In message [EMAIL PROTECTED] Mitsuru IWASAKI writes:
imp : Hi, here is the latest report on our ACPI project's progress.
imp
imp As I told you on the Train in Tokyo: Cool! Way Cool! ACPI should
imp enable us to properly put the chipsets in laptops to sleep and then
imp wake them up again.
On Mon, 19 Jun 2000 01:28:27 MDT, "Kenneth D. Merry" wrote:
In any case, if an error were returned, the only way you could get that
to work would be to have the media daemon continually ping the drive with
the mounted media, and then unmount it in response to the (likely) unit
attention
On Mon, Jun 19, 2000 at 12:49:30PM -0400, Alan Clegg wrote:
Well, USENIX is the first time I've needed to run in non-'ad-hoc' mode,
and also the first time I've seen any contention for wireless bandwidth.
I'm seein REALLY odd behavior when I put my wi0 into promiscuous mode..
When it goes
Hello!
After CVSuped my source, i try to buildworld and it failed...
=== libssh
rm -f .depend
mkdep -f .depend -a-DSKEY -I/usr/obj/usr/src/i386/usr/include
/usr/src/secure/lib/libssh/../../../crypto/openssh/authfd.c
/usr/src/secure/lib/libssh/../../../crypto/openssh/authfile.c
On Mon, Jun 19, 2000 at 01:42:33PM +0200, Adrian Chadd wrote:
I've ported the NetBSD fsck wrapper to compile and run under FreeBSD.
Can you summerize what this does, or does better than what we do today?
--
-- David ([EMAIL PROTECTED])
To Unsubscribe: send mail to [EMAIL PROTECTED]
with
On Mon, Jun 19, 2000, David O'Brien wrote:
On Mon, Jun 19, 2000 at 01:42:33PM +0200, Adrian Chadd wrote:
I've ported the NetBSD fsck wrapper to compile and run under FreeBSD.
Can you summerize what this does, or does better than what we do today?
The idea is the same as mount and its
Summary: -current will be destabilized for an extended period (on the order
of months). A tag (not a branch) will be laid down before the initial
checkin, and non-developers should either stick closely to that tag until
the kernel stabilizes, or expect large doses of pain. This tag will be
laid
At 11:53 AM -0700 2000/6/19, Jason Evans wrote:
Last week, approximately 20 BSD developers got together and discussed how
to move FreeBSD's SMP support to the next level. Our effort will be
largely based on the work that has been done in BSD/OS, which should make
things go much more
"Sergey" == Sergey Osokin [EMAIL PROTECTED] writes:
Sergey Hello!
Sergey After CVSuped my source, i try to buildworld and it failed...
Sergey === libssh
(...)
Sergey /usr/obj/usr/src/i386/usr/include/openssl/evp.h:99: openssl/idea.h: No such
file or directory
Sergey mkdep: compile failed
On a totally non-technical, but somewhat related note, can anyone
give me any kind of idea how often relatively "large scale" changes
like this typically occur with FreeBSD?
IIRC, this is the biggest operation of its sort since 2.1.
Can't comment on anything before then, I wasn't
When loading modules with other modules in the same linker file,
depending on each other, currently the kernel linker chokes. Example:
the uhub, uhci, ohci and usb modules are (for unrelated reasons) linked
into one big file. It is however impossible currently to preload that
file because the
:Summary: -current will be destabilized for an extended period (on the order
:of months). A tag (not a branch) will be laid down before the initial
:checkin, and non-developers should either stick closely to that tag until
:the kernel stabilizes, or expect large doses of pain. This tag will be
On Mon, Jun 19, 2000 at 05:34:47PM -0700, Matthew Dillon wrote:
Ok, I have put up a web page that will track my efforts.
http://apollo.backplane.com/FreeBSDSmp/
On this page, you say:
The algorithms described on this page are essentially the BSDI algorithms
plus accomodations
:On this page, you say:
:
: The algorithms described on this page are essentially the BSDI algorithms
: plus accomodations we disussed at the Yahoo SMP meeting. However, I did
: not do a direct port. I did a from-scratch rewrite because, simply put,
: it was easier for me. The variables are
On Mon, Jun 19, 2000 at 09:59:15PM -0400, Brian Hechinger wrote:
but isn't there wisdom in implementing the wrapper as well? we won't be
using ffs forever (log based file system please!! *G*)
Sure there is, I'm all for the wrapper. I just want "ufs is really ffs"
to go away as well, and am
In message [EMAIL PROTECTED] Mitsuru IWASAKI writes:
: Maybe I'm wrong because of lack of my understanding on crush dump and
: loader. Please help us :-)
I think that you might be able to do this. The real tricky part maybe
saving hardware RAM that the drivers expect to be there when you
S4 requires the OS to reinitialise peripherals. Some comments I've seen
from the Linux folks suggest that we'll have to save and restore the PCI
configuration space as well.
Basically, resume from S4 is not something that is going to be very easy
for us to implement. It'll require
In message [EMAIL PROTECTED] Mike Smith writes:
: Hmm, this has me thinking again about suspend/resume. In the current
: context, can we expect a suspend veto from some function to actually
: DTRT? (ie. drivers that have been suspended get a resume call).
If the BIOS allows us to do that,
On Mon, 19 Jun 2000 10:07:26 -0700, Mike Smith [EMAIL PROTECTED] said:
Hmm, this has me thinking again about suspend/resume. In the current
context, can we expect a suspend veto from some function to actually
DTRT? (ie. drivers that have been suspended get a resume call).
That's how I
Bjoern Fischer wrote:
Just a moment. You talk about doing a `Save-to-Disk' (incl. system halt),
turning power off, maybe adding some hardware or moving the machine
to another location, then switching on again, restoring the system context,
and the machine will proceed as if nothing had
On Mon, Jun 19, 2000 at 06:36:14PM +0200, Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], Warner Losh writes:
In message [EMAIL PROTECTED] Mitsuru IWASAKI writes:
: Maybe I'm wrong because of lack of my understanding on crush dump and
: loader. Please help us :-)
I think that you
In message [EMAIL PROTECTED] "Andrew Reilly" writes:
: That sounds way too hard. Why not restrict suspend activity to
: user-level processes and bring the kernel/drivers back up through
: a regular boot process? At least that way the hardware and drivers
: will know what they are all up to,
Andrew Reilly wrote:
On Mon, Jun 19, 2000 at 05:01:46PM -0600, Warner Losh wrote:
In message [EMAIL PROTECTED] "Andrew Reilly" writes:
: That sounds way too hard. Why not restrict suspend activity to
: user-level processes and bring the kernel/drivers back up through
: a regular boot
Warner Losh wrote:
In message [EMAIL PROTECTED] Mitsuru IWASAKI writes:
: Maybe I'm wrong because of lack of my understanding on crush dump and
: loader. Please help us :-)
I think that you might be able to do this. The real tricky part maybe
saving hardware RAM that the drivers expect
On Mon, Jun 19, 2000 at 05:01:46PM -0600, Warner Losh wrote:
In message [EMAIL PROTECTED] "Andrew Reilly" writes:
: That sounds way too hard. Why not restrict suspend activity to
: user-level processes and bring the kernel/drivers back up through
: a regular boot process? At least that way
On Mon, 19 Jun 2000, Brooks Davis wrote:
:On Tue, Jun 20, 2000 at 10:49:24AM +1000, Andrew Reilly wrote:
:
: Processes do still wind up in "sleep" state, completely paged
: out, don't they?
:
:Observationaly, no. Unless I actually manage to run my system low on
:RAM, none of my swap is used
In message [EMAIL PROTECTED] Mitsuru IWASAKI writes:
: Maybe I'm wrong because of lack of my understanding on crush dump and
: loader. Please help us :-)
I think that you might be able to do this. The real tricky part maybe
saving hardware RAM that the drivers expect to be there when you
In message [EMAIL PROTECTED], Warner Losh writes:
In message [EMAIL PROTECTED] Mitsuru IWASAKI writes:
: Maybe I'm wrong because of lack of my understanding on crush dump and
: loader. Please help us :-)
I think that you might be able to do this. The real tricky part maybe
saving hardware RAM
On Mon, Jun 19, 2000 at 05:01:46PM -0600, Warner Losh wrote:
In message [EMAIL PROTECTED] "Andrew Reilly" writes:
: That sounds way too hard. Why not restrict suspend activity to
: user-level processes and bring the kernel/drivers back up through
: a regular boot process? At least that
On Tue, Jun 20, 2000 at 10:16:08AM +1000, Andrew Reilly wrote:
(*) Speaking of which: why are we considering doing process
dumps into a _different_ swap-ish partition, instead of just
ensuring that all processes are sleeping in the normal swap
partition? If that was done, then they would
On Mon, Jun 19, 2000 at 05:40:30PM -0700, Mike Smith wrote:
The real issue here is persistent system state across the S4 suspend;
ie.
leaving applications open, etc. IMO this isn't really something worth a
lot of effort to us, and it has a lot of additional complications for a
On Mon, Jun 19, 2000 at 05:30:55PM -0700, Brooks Davis wrote:
On Tue, Jun 20, 2000 at 10:16:08AM +1000, Andrew Reilly wrote:
(*) Speaking of which: why are we considering doing process
dumps into a _different_ swap-ish partition, instead of just
ensuring that all processes are sleeping in
On Mon, Jun 19, 2000 at 05:40:30PM -0700, Mike Smith wrote:
The real issue here is persistent system state across the S4 suspend; ie.
leaving applications open, etc. IMO this isn't really something worth a
lot of effort to us, and it has a lot of additional complications for a
On Tue, Jun 20, 2000 at 10:49:24AM +1000, Andrew Reilly wrote:
The issue isn't with the size of the disk storage required, but
with the mechanism. Why dedicate 256M to a suspend partition, and
invent a new process saving mechanism, instead of making your
existing swap partition 256M larger
50 matches
Mail list logo
