Re: ACPI project progress report

2000-06-19 Thread Bjoern Fischer
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

Re: -e option to umount?

2000-06-19 Thread Bob Bishop
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

Re: cvs commit: src/usr.sbin/ancontrol ancontrol.c

2000-06-19 Thread Nickolay Dudorov
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]

Re: -e option to umount?

2000-06-19 Thread Daniel O'Connor
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

Re: -e option to umount?

2000-06-19 Thread Kenneth D. Merry
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

Re: VMware detection code in boot loader

2000-06-19 Thread Martin Cracauer
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

Re: -e option to umount?

2000-06-19 Thread Mike Smith
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

Re: -e option to umount?

2000-06-19 Thread Kenneth D. Merry
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

Re: -e option to umount?

2000-06-19 Thread Soren Schmidt
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

RE: ACPI project progress report

2000-06-19 Thread Koster, K.J.
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

Re: compiling kernel with -Os or -O2

2000-06-19 Thread Alexander Leidinger
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

Re: compiling kernel with -Os or -O2

2000-06-19 Thread Jacob A. Hart
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

fsck wrappers

2000-06-19 Thread Adrian Chadd
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:

Re: -e option to umount?

2000-06-19 Thread Jacques A . Vidrine
[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

Re: -e option to umount?

2000-06-19 Thread Steve O'Hara-Smith
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

Re: ACPI project progress report

2000-06-19 Thread Mitsuru IWASAKI
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

Re: ACPI project progress report

2000-06-19 Thread Mitsuru IWASAKI
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.

Re: -e option to umount?

2000-06-19 Thread Parag Patel
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

Re: WaveLan oddness at USENIX

2000-06-19 Thread Alan Clegg
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

make buildworld failed...

2000-06-19 Thread Sergey Osokin
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

Re: fsck wrappers

2000-06-19 Thread David O'Brien
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

Re: fsck wrappers

2000-06-19 Thread Adrian Chadd
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

Re: fsck wrappers

2000-06-19 Thread Adrian Chadd
On Mon, Jun 19, 2000, Adrian Chadd wrote: 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

HEADS UP: Destabilization due to SMP development

2000-06-19 Thread Jason Evans
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

Re: HEADS UP: Destabilization due to SMP development

2000-06-19 Thread Brad Knowles
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

Re: make buildworld failed...

2000-06-19 Thread Eric Jacoboni
"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

Re: HEADS UP: Destabilization due to SMP development

2000-06-19 Thread Michael Lucas
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

Using KLD's with modules that depend other modules in the same file

2000-06-19 Thread Nick Hibma
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

Re: HEADS UP: Destabilization due to SMP development

2000-06-19 Thread Matthew Dillon
: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

SMP locking primities (was Re: HEADS UP: Destabilization due to SMP development)

2000-06-19 Thread Jason Evans
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

Re: SMP locking primities (was Re: HEADS UP: Destabilization due to SMP development)

2000-06-19 Thread Matthew Dillon
: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

Updated kame tarball (oops)

2000-06-19 Thread Kris Kennaway
I accidentally left out a bunch of files from my previous kame patch - the corrected version is at http://www.freebsd.org/~kris/kame.tar.gz - the same caveats apply as before. Extract that tarball in /usr/src/sys and apply the patch, then rebuild. The userland can be obtained from the latest

Re: fsck wrappers

2000-06-19 Thread Anatoly Vorobey
On Mon, Jun 19, 2000 at 01:42:33PM +0200, Adrian Chadd wrote: * the rest of the system treats ffs filesystems as "ufs". Besides the fact that I dislike this, I decided against the NetBSD way of Isn't it time, anyway, to fix this? This legacy dates from long time ago; e.g. the log message

Re: fsck wrappers

2000-06-19 Thread Anatoly Vorobey
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

Re: ACPI project progress report

2000-06-19 Thread Mike Smith
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

Re: ACPI project progress report

2000-06-19 Thread Mike Smith
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

Re: ACPI project progress report

2000-06-19 Thread Warner Losh
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,

Re: ACPI project progress report

2000-06-19 Thread Garrett Wollman
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

Re: ACPI project progress report

2000-06-19 Thread Daniel C. Sobral
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

Re: ACPI project progress report

2000-06-19 Thread Andrew Reilly
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

Re: ACPI project progress report

2000-06-19 Thread Warner Losh
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,

Re: ACPI project progress report

2000-06-19 Thread Andre Oppermann
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

Re: ACPI project progress report

2000-06-19 Thread Daniel C. Sobral
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

Re: ACPI project progress report

2000-06-19 Thread Andrew Reilly
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

Re: ACPI project progress report

2000-06-19 Thread David Scheidt
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

Re: ACPI project progress report

2000-06-19 Thread Warner Losh
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

Re: ACPI project progress report

2000-06-19 Thread Poul-Henning Kamp
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

Re: ACPI project progress report

2000-06-19 Thread Mike Smith
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

Re: ACPI project progress report

2000-06-19 Thread Brooks Davis
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

Process migration (was RE: ACPI project progress report)

2000-06-19 Thread Andrew ReillyAtLake
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

Re: ACPI project progress report

2000-06-19 Thread Andrew Reilly
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

Re: ACPI project progress report

2000-06-19 Thread Andrew Reilly
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

Re: ACPI project progress report

2000-06-19 Thread Brooks Davis
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