Re: -e option to umount?
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 an event daemon.. It could handle stuff like a user hitting the eject button, someone pressing a magic key on the keyboard, and apm events etc.. then do something about it. --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -e option to umount?
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 button on my CDROM > drive that whatever scsi signal that event generates, was intercepted by > the kernel and, provided the filesystem met the normal criteria for > being umount'd(i.e. nothing accessing it), it would be umount'd and then > 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? 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 an initiator. Then the controller would have to pass that back up to some process that would then unmount the drive, which would also give the cd(4) driver its final close and allow removal of the media. Then the eject could proceed. The problem is that I haven't yet seen a SCSI device (well, short of a FreeBSD box) that is capable of doing AENs, since most SCSI devices can't be both target and initiator. They're generally just targets. Likewise, most controllers only function as initiators. The Adaptec and Qlogic controllers are exceptions in FreeBSD. The Symbios/LSI controllers could probably do target mode as well, given the right firmware and driver support. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: VMware detection code in boot loader
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 a while) we should be able to boot any i386/AT > based machine with a single kernel which dynamically loads drivers for > available hardware (and different locking modules for UP and SMP for that > matter). I have such a kernel for all my machines except SMP. However, I still boot different UP kernels on each machines for testing purposes: - different 'cpu I..._CPU' settings - different floating emulators - much or few RAM I don't want to detect all hardware, what I need is one way to tell each machine from each other, like a hostid. The ethernet address of the first card could be. Martin -- % Martin Cracauer <[EMAIL PROTECTED]> http://www.cons.org/cracauer/ BSD User Group Hamburg, Germany http://www.bsdhh.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -e option to umount?
> 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 an > initiator. Hmm. If SCSI drives are anything like ATAPI drives (and here I confess I haven't checked), the first I/O after the eject button is pressed will come back with a marker (eg. check condition) with sense information that indicates that a user eject was requested. > Then the controller would have to pass that back up to some process that > would then unmount the drive, which would also give the cd(4) driver its > final close and allow removal of the media. That's pretty much a given part of the media daemon implementation, and really not all that hard. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -e option to umount?
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 > > would have to be capable of functioning as a target as well as an > > initiator. > > Hmm. If SCSI drives are anything like ATAPI drives (and here I confess I > haven't checked), the first I/O after the eject button is pressed will > come back with a marker (eg. check condition) with sense information that > indicates that a user eject was requested. Some may, but the Panasonic DVD drive I just tried here didn't pass back any sort of error in response to the TUR I sent it after pressing the eject button. 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 condition. > > Then the controller would have to pass that back up to some process that > > would then unmount the drive, which would also give the cd(4) driver its > > final close and allow removal of the media. > > That's pretty much a given part of the media daemon implementation, and > really not all that hard. True enough. It's getting a drive that supports AEN that is hard. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -e option to umount?
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 functioning as a target as well as an > > initiator. > > Hmm. If SCSI drives are anything like ATAPI drives (and here I confess I > haven't checked), the first I/O after the eject button is pressed will > come back with a marker (eg. check condition) with sense information that > indicates that a user eject was requested. This is not true for the wast majority of ATAPI devices, they plain ignore the eject button if the media is locked. The only drive I've seen this working on is the Onstream ADR tape, which has a whole palette of other problems :) -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: ACPI project progress report
> > 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 think FreeBSD supports something similar already. It's a little outdated by modern computing standards, but it used to be called a "halt" or a "reboot". Advantage of those outdated concepts used to be that you could replace your /kernel, adding for example a new driver for the new hardware, or after a cvsup. Just curious, but are you planning to add such functionality to S4? :) Kees Jan == Everyone is responsible for his own actions, and (people tend to forget this) the effect they have on others. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: compiling kernel with -Os or -O2
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 -fschedule-insns2 Works fine here. Bye, Alexander. -- Reboot America. http://www.Leidinger.net Alexander+Home @ Leidinger.net GPG fingerprint = 7423 F3E6 3A7E B334 A9CC B10A 1F5F 130A A638 6E7E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: compiling kernel with -Os or -O2
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 modules are built with the kernel, perhaps COPTFLAGS should be the optimisation variable responsible for both kernel _and_ modules? -jake On Sun, Jun 18, 2000 at 07:17:26PM -0400, 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 > get a "fatal trap 12: page fault in supervisor mode" right after I > see this on my screen while the kernel is booting: > > Copyright (c) 1992-2000 The FreeBSD Project. > Copyright (c) 1982, 1986, 1989, 1991, 1993 > The Regents of the University of California. All rights > reserved. > FreeBSD 5.0-CURRENT #0: Sun Jun 18 19:06:34 EDT 2000 > [EMAIL PROTECTED]:/usr/src/sys/compile/CUSTOM > Timecounter "i8254" frequency 1193182 Hz > CPU: Pentium/P55C (166.45-MHz 586-class CPU) > Origin = "GenuineIntel" Id = 0x543 Stepping = 3 > Features=0x8001bf > real memory = 62914560 (61440K bytes) > > > This is all the further the boot gets before the page fault. Of > course, as David O'Brien pointed out, optimization levels beyond -O > aren't supported. But, I'm curious as to what the cause of this is, > as it may reveal a deeper problem someplace. For example, is the > problem with binutils, the kernel source code, or both? Hopefully, > we'll find out after the binutils upgrade is complete. > > I should point out that using -O to compile the kernel gives no > problems booting; it's just -Os that causes the problems for me. > > - Donn > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message -- Jacob A. Hart <[EMAIL PROTECTED]> Powered by: FreeBSD 5.0-CURRENT #25: Sat Jun 17 14:16:03 EST 2000 I believe the technical term is "Oops!" PGP signature
fsck wrappers
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: http://www.freebsd.org/~adrian/fsck.tar.gz A couple of notes: * the rest of the system treats ffs filesystems as "ufs". Besides the fact that I dislike this, I decided against the NetBSD way of if (strcmp(vfstype, "ufs")) fstype = "ffs"; and have left people to symlink or hardlink fsck_ufs to fsck_ffs. * I've left the CVS directories intact so people can generate their own cvs diff's against the original sources. Appropriate CVSROOT frobbing will be needed. Constructive comments are welcome. Adrian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -e option to umount?
[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 for SCSI devices, in camcontrol(8). e.g. % camcontrol eject cd0 This works for SCSI tapes as well. -- Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -e option to umount?
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 for a port. > > And you'd find it, at least for SCSI devices, in camcontrol(8). > e.g. > > % camcontrol eject cd0 > > This works for SCSI tapes as well. /usr/sbin/cdcontrol -f /dev/acd0c eject works for ATAPI CDs. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI project progress report
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 machine > to another location, then switching on again, restoring the system context, > and the machine will proceed as if nothing had happened, do you? Yes, exactly. My rough idea is like this; - do preparation for sleeping state transition for each devices and _PTS (prepare to sleep) control method. - stop all of processes, other sub-system (eg filesystem, memory...) and write contents of memory to dedicated swap partition for "Save-to-Disk" and save system context. - turning power off by manipulating ACPI registers (or just halt the system and user will turning power off). - upon turning power on, BIOS built ACPI tables again if hardware configuration changed during sleeping. Any important device (eg disk controller) configuration changes will cause the restoring system context to fail. - after POST, BIOS passes control to the boot loader in normal case. - load will check whether S4 transition occurred, then restore system context and memory from swap partition. - do _WAK (wakeup) control method, wakeup processes for each devices and re-enable them. Maybe I'm wrong because of lack of my understanding on crush dump and loader. Please help us :-) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI project progress report
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. Right now pccard insert/removal can be missed imp> when you put a laptop to sleep... Yes, many of today's laptop BIOS are expecting that OS shouldn handle this kind of things by executing the AML. Good news, recently I wrote accessing ioport stuff (roughly :-) and experimental code for executing _PTS & _WAK method in kernel space. On P2B based system, it seems working fine :-) Next step is implement accessing other bus spaces, physical memory will be the target (and PCI config, SMBus...). Can anybody help us on this? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -e option to umount?
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 condition. This is how the MacOS does it, at least prior to MacOS X. If the CD-ROM is external and powered-down after the MacOS boots, the Mac then hangs periodically trying to ping it. Really screws up performance. :) -- Parag Patel To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: WaveLan oddness at USENIX
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 promiscuous, 'wicontrol' shows that the Current netname (SSID) > gets reset, the BSSID goes to all 4's (ie: 44:44:44:44:44:44) and my net > connection goes into the toilet. > > Any ideas on what is happening? BTW, this is with 5.0-CURRENT cvs'd Saturday 6/17. AlanC To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
make buildworld failed...
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 /usr/src/secure/lib/libssh/../../../crypto/openssh/aux.c /usr/src/secure/lib/libssh/../../../crypto/openssh/bufaux.c /usr/src/secure/lib/libssh/../../../crypto/openssh/buffer.c /usr/src/secure/lib/libssh/../../../crypto/openssh/canohost.c /usr/src/secure/lib/libssh/../../../crypto/openssh/channels.c /usr/src/secure/lib/libssh/../../../crypto/openssh/cipher.c /usr/src/secure/lib/libssh/../../../crypto/openssh/compat.c /usr/src/secure/lib/libssh/../../../crypto/openssh/compress.c /usr/src/secure/lib/libssh/../../../crypto/openssh/crc32.c /usr/src/secure/lib/libssh/../../../crypto/openssh/deattack.c /usr/src/secure/lib/libssh/../../../crypto/openssh/fingerprint.c /usr/src/secure/lib/libssh/../../../crypto/openssh/hostfile.c /usr/src/secure/lib/libssh/../../../crypto/openssh/log.c /usr/src/secure/lib/libssh/../../../crypto/openssh/match.c /usr/src/secure/lib/libssh/../../../crypto/openssh/mpaux.c /usr/src/secure/lib/libssh/../../../crypto/openssh/nchan.c /usr/src/secure/lib/libssh/../../../crypto/openssh/packet.c /usr/src/secure/lib/libssh/../../../crypto/openssh/readpass.c /usr/src/secure/lib/libssh/../../../crypto/openssh/rsa.c /usr/src/secure/lib/libssh/../../../crypto/openssh/tildexpand.c /usr/src/secure/lib/libssh/../../../crypto/openssh/ttymodes.c /usr/src/secure/lib/libssh/../../../crypto/openssh/uidswap.c /usr/src/secure/lib/libssh/../../../crypto/openssh/xmalloc.c /usr/src/secure/lib/libssh/../../../crypto/openssh/atomicio.c /usr/src/secure/lib/libssh/../../../crypto/openssh/key.c /usr/src/secure/lib/libssh/../../../crypto/openssh/dispatch.c /usr/src/secure/lib/libssh/../../../crypto/openssh/dsa.c /usr/src/secure/lib/libssh/../../../crypto/openssh/kex.c /usr/src/secure/lib/libssh/../../../crypto/openssh/hmac.c /usr/src/secure/lib/libssh/../../../crypto/openssh/uuencode.c /usr/src/secure/lib/libssh/../../../crypto/openssh/auth-skey.c In file included from /usr/obj/usr/src/i386/usr/include/openssl/pem.h:66, from /usr/src/secure/lib/libssh/../../../crypto/openssh/authfile.c:24: /usr/obj/usr/src/i386/usr/include/openssl/evp.h:99: openssl/idea.h: No such file or directory In file included from /usr/obj/usr/src/i386/usr/include/openssl/hmac.h:69, from /usr/src/secure/lib/libssh/../../../crypto/openssh/packet.c:40: /usr/obj/usr/src/i386/usr/include/openssl/evp.h:99: openssl/idea.h: No such file or directory In file included from /usr/src/secure/lib/libssh/../../../crypto/openssh/key.c:40: /usr/obj/usr/src/i386/usr/include/openssl/evp.h:99: openssl/idea.h: No such file or directory In file included from /usr/src/secure/lib/libssh/../../../crypto/openssh/dsa.c:43: /usr/obj/usr/src/i386/usr/include/openssl/evp.h:99: openssl/idea.h: No such file or directory In file included from /usr/obj/usr/src/i386/usr/include/openssl/pem.h:66, from /usr/src/secure/lib/libssh/../../../crypto/openssh/kex.c:49: /usr/obj/usr/src/i386/usr/include/openssl/evp.h:99: openssl/idea.h: No such file or directory In file included from /usr/obj/usr/src/i386/usr/include/openssl/hmac.h:69, from /usr/src/secure/lib/libssh/../../../crypto/openssh/hmac.c:37: /usr/obj/usr/src/i386/usr/include/openssl/evp.h:99: openssl/idea.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /usr/src/secure/lib/libssh. *** Error code 1 Stop in /usr/src/secure/lib. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Any idea? Rgdz, Sergey A. Osokin aka oZZ, [EMAIL PROTECTED] http://www.FreeBSD.ORG.ru/~osa/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: fsck wrappers
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 "unsubscribe freebsd-current" in the body of the message
Re: fsck wrappers
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 helpers - adding new fsck types doesn't require modifying the startup scripts or fsck. Think of a system where you have an FFS fs, an LFS fs, and perhaps an IFS fs. Each one requires a seperate fsck, but it would be stupid to have fsck_* -p in the rc scripts. Eventually FreeBSD systems will have more than just FFS based filesystems running the system, and users will want to fsck them just like a FFS filesystem. adrian -- Adrian ChaddBuild a man a fire, and he's warm for the <[EMAIL PROTECTED]>rest of the evening. Set a man on fire and he's warm for the rest of his life. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: fsck wrappers
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 today? > > The idea is the same as mount and its helpers - adding new fsck types > doesn't require modifying the startup scripts or fsck. Think of a system > where you have an FFS fs, an LFS fs, and perhaps an IFS fs. Each one > requires a seperate fsck, but it would be stupid to have fsck_* -p in > the rc scripts. > > Eventually FreeBSD systems will have more than just FFS based filesystems > running the system, and users will want to fsck them just like a FFS > filesystem. Watching my machine boot, the parallel nature of this fsck is now confusing the output, eg: Automatic reboot in progress... ** /dev/ad0s1a ** Last Mounted on / ** Root file system ** Phase 1 - Check Blocks and Sizes de0: enabling 10baseT port ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups 1506 files, 57594 used, 10837 free (285 frags, 1319 blocks, 0.4% fragmentation) ** /dev/amrd0a ** /dev/ad0s1f ** Last Mounted on /cache ** Phase 1 - Check Blocks and Sizes ** Last Mounted on /usr ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups ** Phase 2 - Check Pathnames 98429 files, 1812888 used, 2499978 free (181498 frags, 289810 blocks, 4.2% fragmentation) .. Would people object to fsck printing out either the mountpoint or the devname (where appropriate) prepending each line of fsck_ffs ? Adrian -- Adrian ChaddBuild a man a fire, and he's warm for the <[EMAIL PROTECTED]>rest of the evening. Set a man on fire and he's warm for the rest of his life. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
HEADS UP: Destabilization due to SMP development
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 down as soon as June 26, 00:00 PST, with a minimum 24 hour warning beforehand. --- 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 smoothly than they otherwise might, but we still expect -current to be destabilized for an extended period of time. Matthew Dillon is currently working on the locking primitives, as well as some changes to the way our top-level kernel locking works. His initial code will not remove spl()s. This code will probably be committed as the first step, as soon as June 26, 00:00 PST, and Peter Wemm will lay a tag down just beforehand. We will give at least 24 hours notice before the tag is laid down. Be forewarned: if you are doing anything with -current besides FreeBSD development, you will probably want to stop tracking -current at that point for a while. Greg Lehey will be working on the initial cutover to interrupt threads (as well as the lazy interrupt thread context switching code later on). spl()s will go away as soon as interrupt threads start working. Once interrupt threads are working, most of the remaining work of threading the kernel will be able to go on in parallel. Device driver maintainers will be able to convert device drivers over a period of several months. We expect to have a compatibility shim in place initially, but there will be a hard cutoff date sometime before the release of FreeBSD 5.0 where the compatibility shim is removed. Before getting too excited about this part of the conversion to a threaded kernel, please keep in mind that 1) there will be plenty of time to do this conversion, 2) the conversion is pretty trivial for most drivers, and 3) as we get to the stage where the conversion becomes possible, there will be much more detail about how to do the conversion, as well as the working examples of the first drivers to be converted. The addition of kernel support for scheduler activations is generally a separate project, but there are some interdependencies between the SMP and scheduler activations changes, especially in the scheduler and the proc structure. There are many other SMP-related changes that will be made to the kernel that are not specifically mentioned in this email, since they are not of significant interest from a grand overview perspective. However, there are many details, and if you want to follow the technical discussions, you will want to be subscribed to at least the -current and -smp mailing lists. Finally, here are some notes about the organization of this effort. I was cajoled into acting as the manager of this effort. That doesn't mean I'm going to do all (or even a major part) of the work; it merely means I'm the focal point of communications and decisions made with regard to the project. Right now, there are at least a dozen highly capable FreeBSD developers that have taken an interest in working on this project. We, as a group, have made a number of decisions about how to attack this project. If you want to contribute to technical aspects of the project, please jump in. However, consider that the general direction we're taking with the SMP effort is the result of a number of very knowledgeable people hashing this out over a period of two days; don't expect that direction to change in the short-term. So, if you have grievances about the way this project is being run, complain to me, but please let the other developers work on this in relative peace. Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: Destabilization due to SMP development
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 smoothly than they otherwise might, but we still expect > -current to be destabilized for an extended period of time. Wow. Cool. Way cool. My mind is already beginning to boggle, just thinking of what very little I know of what must go into a process like this 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? By the time I came along, I think -CURRENT was already well into 4.x, so I don't have that kind of history to fall back on. I'm just intensely curious to know how often "revolutions" of this kind of scale typically happen within this project. I can't wait to see the discussions go on with relation to all this stuff! However, if you don't mind I think I'll continue to track RELENG_4 and listen over here to get some idea of what may be ultimately coming down the pike over there for -STABLE. -- These are my opinions -- not to be taken as official Skynet policy == Brad Knowles, <[EMAIL PROTECTED]>|| Belgacom Skynet SA/NV Systems Architect, Mail/News/FTP/Proxy Admin || Rue Colonel Bourg, 124 Phone/Fax: +32-2-706.13.11/12.49 || B-1140 Brussels http://www.skynet.be || Belgium To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make buildworld failed...
> "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 Sergey> *** Error code 1 Sergey> Stop in /usr/src/secure/lib/libssh. Sergey> *** Error code 1 Sergey> Stop in /usr/src/secure/lib. Sergey> *** Error code 1 Sergey> Stop in /usr/src. Sergey> *** Error code 1 Sergey> Stop in /usr/src. Sergey> *** Error code 1 Same for me (fresh cvsup)... From the FAQ : "You can try to config OpenSSL so as not to use IDEA by using './config no-idea'". But i've no idea (what's a joke...) on how to do that with 'make buildworld'. No times to test any further now : it's late and i have to go to bed ;-) -- - Éric Jacoboni « No sport, cigars! » (W. Churchill) - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: Destabilization due to SMP development
> 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 around. ==ml To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Using KLD's with modules that depend other modules in the same file
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 dependencies are not found if MODULE_DEPEND and
MODULE_VERSION are added in appropriate places.
Currently we do the following:
for all linker files
(A) check dependencies for all modules in linker file
against found_modules
if resolves
(B) add the modules to found_modules
The attached patch changes this to
for all linker files
(B) create a list of modules in the file (file_modules)
(A) check dependencies for all modules in linker file
against found_modules and file_modules
if resolves
(C) concatenate file_modules to found_modules
Step A and B are reversed and a copy loop (C) has been added.
As a side effect it is now also possible for modules to depend on
themselves (usb_depend_on_usb):
% nm /modules/usb.ko | grep depend_on
00019bc0 d _uhub_depend_on_usb
00019e88 d _usb_depend_on_usb
Comments?
Nick
P.S.: I am aware of the people involved being at Usenix, so I'll
postpone committing this until they have had time to comment on it.
--
[EMAIL PROTECTED]
[EMAIL PROTECTED] USB project
http://www.etla.net/~n_hibma/
Index: kern_linker.c
===
RCS file: /home/ncvs/src/sys/kern/kern_linker.c,v
retrieving revision 1.46
diff -w -u -r1.46 kern_linker.c
--- kern_linker.c 2000/05/26 02:04:34 1.46
+++ kern_linker.c 2000/06/19 23:36:24
@@ -923,11 +923,11 @@
*/
static modlist_t
-modlist_lookup(const char *name)
+modlist_lookup(modlisthead_t *modules, const char *name)
{
modlist_t mod;
-for (mod = TAILQ_FIRST(&found_modules); mod; mod = TAILQ_NEXT(mod, link)) {
+for (mod = TAILQ_FIRST(modules); mod; mod = TAILQ_NEXT(mod, link)) {
if (!strcmp(mod->name, name))
return mod;
}
@@ -960,10 +960,12 @@
inti;
intresolves;
modlist_t mod;
+modlisthead_t file_modules;
TAILQ_INIT(&loaded_files);
TAILQ_INIT(&depended_files);
TAILQ_INIT(&found_modules);
+TAILQ_INIT(&file_modules);
error = 0;
modptr = NULL;
@@ -1002,7 +1004,7 @@
if (mp->md_type != MDT_VERSION)
continue;
modname = mp->md_cval;
- if (modlist_lookup(modname) != NULL) {
+ if (modlist_lookup(&found_modules, modname) != NULL) {
printf("module %s already present!\n", modname);
/* XXX what can we do? this is a build error. :-( */
continue;
@@ -1025,34 +1027,20 @@
for (lf = TAILQ_FIRST(&loaded_files); lf; lf = TAILQ_NEXT(lf, loaded)) {
deps = (struct linker_set*)
linker_file_lookup_symbol(lf, MDT_SETNAME, 0);
- /*
-* First, look to see if we would successfully link with this stuff.
-*/
+
resolves = 1; /* unless we know otherwise */
+
if (deps) {
- for (i = 0; i < deps->ls_length; i++) {
- mp = linker_reloc_ptr(lf, deps->ls_items[i]);
- if (mp->md_type != MDT_DEPEND)
- continue;
- modname = linker_reloc_ptr(lf, mp->md_cval);
- if (modlist_lookup(modname) == NULL) {
- /* ok, the module isn't here yet, we are not finished */
- resolves = 0;
- }
- }
- }
/*
-* OK, if we found our modules, we can link. So, "provide" the
-* modules inside and add it to the end of the link order list.
+* First, find all the modules that are contained in the file.
*/
- if (resolves) {
- if (deps) {
for (i = 0; i < deps->ls_length; i++) {
mp = linker_reloc_ptr(lf, deps->ls_items[i]);
if (mp->md_type != MDT_VERSION)
continue;
modname = linker_reloc_ptr(lf, mp->md_cval);
- if (modlist_lookup(modname) != NULL) {
+ if (modlist_lookup(&found_modules, modname) != NULL
+ || modlist_lookup(&file_modules, modname) != NULL) {
printf("module %s already present!\n", modname);
linker_file_unload(lf);
TAILQ_REMOVE(&loaded_files, lf, loaded);
@@ -1064,9 +1052,38 @@
bzero(mod, sizeof(*mod));
mod->container = lf;
mod->name = modname;
- TAILQ_INSERT_TAIL(&found_modules, mod, link);
+
Re: HEADS UP: Destabilization due to SMP development
: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 down as soon as June 26, 00:00 PST, with a minimum 24 hour warning :beforehand. : :--- : :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 smoothly than they otherwise might, but we still expect :-current to be destabilized for an extended period of time. : :Matthew Dillon is currently working on the locking primitives, as well as :some changes to the way our top-level kernel locking works. His initial :code will not remove spl()s. This code will probably be committed as the :... Thank you Jason! Ok, I have put up a web page that will track my efforts. http://apollo.backplane.com/FreeBSDSmp/ I got a slow start on the weekend, but I expect to have my piece commitable this week sometime. When I say committable I mean: won't crash the system outright but will still probably panic due to legacy spl*() issues, which we will fix as we see them. I am making good progress. In many respects it is actually easier to get the stuff working on a single-cpu system first since all the MP mechanisms must now work on a single-cpu system due to the preemptive kernel scheduling, but I expect I will have both single and multi-cpu systems working more or less (non-inclusive of interrupt threads, which is going to be Greg's baby, but hopefully with all the support Greg needs to implement them) in the next few days. When I get a little further along I will start making patch sets available on the same page. Probably in the next day or two. :Device driver maintainers will be able to convert device drivers over a :period of several months. We expect to have a compatibility shim in place :initially, but there will be a hard cutoff date sometime before the release :of FreeBSD 5.0 where the compatibility shim is removed. Before getting too :excited about this part of the conversion to a threaded kernel, please keep :in mind that 1) there will be plenty of time to do this conversion, 2) the :conversion is pretty trivial for most drivers, and 3) as we get to the :stage where the conversion becomes possible, there will be much more detail :about how to do the conversion, as well as the working examples of the :first drivers to be converted. I believe I found a way to isolate the legacy spl*() stuff without too much interference with the overall design plan (see my document), but I will be the second to say that the legacy stuff is ALL going to be ripped out for the 5.0 release. I would ask that people not commit major changes to the -current sys tree until after we lay down the tags and get the new MP core in place. -Matt Matthew Dillon <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
SMP locking primities (was Re: HEADS UP: Destabilization due to SMP development)
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 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 named differently but I attempt to follow the same API. All the work is subject to change... the point is to make it work first, then clean it up later. Does this include the locking primitives? In the case of the locking primitives, there is functionality that we definitely need, such as the witness code, and it probably would save effort to use the BSD/OS code. I'm guessing that you are actually using the BSD/OS code in this case; I'm just looking for clarification. Thanks, Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SMP locking primities (was Re: HEADS UP: Destabilization due to SMP development)
: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 named differently but I attempt : to follow the same API. All the work is subject to change... the point is : to make it work first, then clean it up later. : :Does this include the locking primitives? In the case of the locking :primitives, there is functionality that we definitely need, such as the :witness code, and it probably would save effort to use the BSD/OS code. :I'm guessing that you are actually using the BSD/OS code in this case; I'm :just looking for clarification. : :Thanks, :Jason The API is very similar, and when I clean it up it should be possible to make it exactly the same, but SPL/CPL/INTERRUPT considerations make using the BSDI code verbatim impossible. Basically I rewrote the core mutex code but I used *everything* that was discussed at the meeting in the implementation, so all the features that we need are there. Spin locks, blocking locks, Giant lock save/restore integrated into the scheduler, quick-attempt in an inline then a call to a real procedure if it fails, using the low 2 bits of the mutex lock field to implement a 'held' bit and a 'contested' bit (which works really wonderfully, I might add! I would never have thought of doing things that way myself!). I am trying to keep it close enough that we can add the witness code in, but before I do that I want to get the system semi-stable. In some respects it's actually easier for us with FreeBSD because we are keeping the spl*() system intact for a while. The witness code is going to be critical for the unwinding work (moving things out of the Giant mutex and into their own mutexes). It isn't critical for this first stage which basically just puts everything under the Giant lock and doesn't *have* any other mutexes beyond SchedMutex and GiantMutex. -Matt Matthew Dillon <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Updated kame tarball (oops)
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 freebsd4 KAME snapshot at ftp.kame.net (the code in the FreeBSD tree won't work). Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: fsck wrappers
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 in the kernel code which declares the ffs module (it reads: `` Call ffs ``ufs'' for the benefit of poor, confused user-land programs. '') dates to September '94. Are there any arguments against changing the filesystem type name to 'ffs' in the kernel and in the userland? If not, I'll volunteer to find all kernel/userland uses I can and provide a diff. -- Anatoly Vorobey, [EMAIL PROTECTED] http://pobox.com/~mellon/ "Angels can fly because they take themselves lightly" - G.K.Chesterton To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: fsck wrappers
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 using the opportunity that the issue surfaced up. I think the wrapper is a great idea, and reporting the mountpoint etc., asked about in a separate message, is great as well. -- Anatoly Vorobey, [EMAIL PROTECTED] http://pobox.com/~mellon/ "Angels can fly because they take themselves lightly" - G.K.Chesterton To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI project progress report
> 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 > wakeup. I thinking of video ram and the X server's font cache, to > name one example. 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 every S4-OK driver to re-initialise in the resume method. (Note that we will also need to add suspend-to and resume-from arguments to the relevant driver methods.) We also have a problem in that we'll need a separate suspend file for system memory, since we can't just up and use swap (which may already be busy). I would be inclined to start with some of the easier states first. 8) -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI project progress report
> 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 every S4-OK driver to re-initialise > in the resume method. (Note that we will also need to add suspend-to and > resume-from arguments to the relevant driver methods.) 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). Or should we make two passes over the suspend method? One with " intention to suspend at this level", the second to actually perform the suspension once the first has been accepted? This will allow non-ACPI-represented drivers to participate in determining which suspend level(s) can actually be supported by the hardware... -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI project progress report
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, yes. I'm fairly sure that doug did the right thing here. The only issue that I ever ran into was that the APM bios shut the machine down anyway, even when we tried to tell it not to. Funny thing about batteries, or something like that:-) : Or should we make two passes over the suspend method? One with " : intention to suspend at this level", the second to actually perform the : suspension once the first has been accepted? No comment. : This will allow non-ACPI-represented drivers to participate in : determining which suspend level(s) can actually be supported by the : hardware... That's true. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI project progress report
< 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 originally implemented it, but I'm not sure whether that has been maintained or not. > Or should we make two passes over the suspend method? One with " > intention to suspend at this level", the second to actually perform the > suspension once the first has been accepted? I think this is a good idea, and better than my implementation. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI project progress report
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 happened, do you? That's what hybernation does under Windows. -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] "He is my minion, so he doesn't need a name." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI project progress report
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 might be able to do this. The real tricky part maybe > >saving hardware RAM that the drivers expect to be there when you > >wakeup. I thinking of video ram and the X server's font cache, to > >name one example. > > Drivers will need a "your hardware may have been zonked" entrypoint, > think about the i8254 counter or all the weird versions of write > only or "write here - read there" I/O registers in existence. 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, even if some of it has changed in the mean time. > Obviously the video driver will need to send a signal or clue to the > Xserver saying "you own the device, you'd better do something" Yeah. The X server has far too much "driver" level code in it already, so probably needs to be tweaked to re-initialise itself properly. -- Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI project progress report
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, even if some of it has changed : in the mean time. Takes too long... That's shutdown, not S4. : > Obviously the video driver will need to send a signal or clue to the : > Xserver saying "you own the device, you'd better do something" : : Yeah. The X server has far too much "driver" level code in it : already, so probably needs to be tweaked to re-initialise itself : properly. Yes. Likely. But if we're going to support sleep modes, we'll need to do this. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI project progress report
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 process? At least that way the hardware and drivers > > : will know what they are all up to, even if some of it has changed > > : in the mean time. > > > > Takes too long... That's shutdown, not S4. > > Yes. But what is the difference, really? As far as the > hardware is concerned, it's being booted. If that process can > be sped up by using the "S4" mechanisms, why can't they be > applied to a regular boot process too? [I'm thinking about a > kernel equivelant of the "clean shutdown" flag on file systems.] If you resume a W2k system from hibernation it will basically boot but with restoring from swap what was running before. > Fundamentally, is there no way to get the kernel and drivers to > go through a full boot phase in a small fraction of the time > that it takes to repopulate 64M of RAM from disk? (*) > > I'm concerned about trying to take short-cuts with booting, > because I've seen both the Toshiba laptop that I'm using now, > and my mother's HP desktop system hang horribly hard when they > should have been coming out of suspend. (Both W'98.) > > I like the idea that my laptop will save power by shutting down > after a while, but I don't want to get into trouble if I forget > whether I was docked or not, or whether the floppy was plugged > in or not, when next I turn it on. > > (*) 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 just page > themselves back in as needed, on wake-up. Yes, W2k pages everything out on hibernate and swaps it in back again when you start using an application that was running before. It's pretty evident once you've used W2k on a Laptop, you can really feel it. > Sorry for blathering. This is just really interesting stuff. It is! :) -- Andre To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI project progress report
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 to be there when you > wakeup. I thinking of video ram and the X server's font cache, to > name one example. It would be the driver's responsibility to save what it can on SLEEP, and rebuild what it couldn't on WAKE. If the driver is simply incapable for some reason, either always or at specific times, it should fail on SLEEP, effectively disabling hybernation on any setup with it (shoganai). -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] "He is my minion, so he doesn't need a name." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI project progress report
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 the hardware and drivers > : will know what they are all up to, even if some of it has changed > : in the mean time. > > Takes too long... That's shutdown, not S4. Yes. But what is the difference, really? As far as the hardware is concerned, it's being booted. If that process can be sped up by using the "S4" mechanisms, why can't they be applied to a regular boot process too? [I'm thinking about a kernel equivelant of the "clean shutdown" flag on file systems.] Fundamentally, is there no way to get the kernel and drivers to go through a full boot phase in a small fraction of the time that it takes to repopulate 64M of RAM from disk? (*) I'm concerned about trying to take short-cuts with booting, because I've seen both the Toshiba laptop that I'm using now, and my mother's HP desktop system hang horribly hard when they should have been coming out of suspend. (Both W'98.) I like the idea that my laptop will save power by shutting down after a while, but I don't want to get into trouble if I forget whether I was docked or not, or whether the floppy was plugged in or not, when next I turn it on. (*) 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 just page themselves back in as needed, on wake-up. Sorry for blathering. This is just really interesting stuff. -- Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI project progress report
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 even with ~5MB Eterm processes sitting :unused for days. I suppose if I let memory get tight, they might get :ditched in favor of disk cache, but I haven't seen that happen. Someone :with a better grasp of the VM could give a more preciese answer. I find lots my xterms getting swapped out on my office desktop. It's only (!) got 128MB of RAM, and I routinely have two or three dozen xterms running locally, plus a like number from remote machines, plus an instance of the X server and Netscape. It only takes a couple seconds to swap in one of the xterms when I start to use it again, and I often don't notice, because I have to move my hand from the mouse back to hte keyboard. I'm probably not a typical user, of course. David scheidt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI project progress report
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 wakeup. I thinking of video ram and the X server's font cache, to name one example. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI project progress report
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 that the drivers expect to be there when you >wakeup. I thinking of video ram and the X server's font cache, to >name one example. Drivers will need a "your hardware may have been zonked" entrypoint, think about the i8254 counter or all the weird versions of write only or "write here - read there" I/O registers in existence. Obviously the video driver will need to send a signal or clue to the Xserver saying "you own the device, you'd better do something" -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI project progress report
> 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 the hardware and drivers > > : will know what they are all up to, even if some of it has changed > > : in the mean time. > > > > Takes too long... That's shutdown, not S4. > > Yes. But what is the difference, really? As far as the > hardware is concerned, it's being booted. If that process can > be sped up by using the "S4" mechanisms, why can't they be > applied to a regular boot process too? [I'm thinking about a > kernel equivelant of the "clean shutdown" flag on file systems.] > > Fundamentally, is there no way to get the kernel and drivers to > go through a full boot phase in a small fraction of the time > that it takes to repopulate 64M of RAM from disk? (*) 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 "server-class" operating system in that you have to worry about network connections from other systems, not just _to_ other systems. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI project progress report
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 just page > themselves back in as needed, on wake-up. Because swap doesn't work that way anymore. They days where every page of memory had to be backed by disk are long gone. This means that there may not be anywere to put processes which are in memory unless you allocate somewhere to save all (or practicaly all) of memory. In any case, I haven't seen many laptops capable of using more then 256MB of RAM which isn't exactly much of a modern disk. My laptop has 256MB of RAM and ships with up to a 10GB disk. I've retrofitted it with a non-standard 18GB disk because 10GB looked too small for my needs. Even with the 6.4GB disk it shipped with, the suspend to disk partition is only 4% of my disk. -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Process migration (was RE: ACPI project progress report)
> 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 > > "server-class" operating system in that you have to worry about network > > connections from other systems, not just _to_ other systems. I was thinking about this a little more this afternoon, and it occurred to me that the system state management services that one would like for smooth "suspend" operation on laptops are very nearly the same as the process checkpointing services that one requires for process migration in a cluster environment. That sounds like a "server-class" application for this stuff. I know of at least one research project involving process migration in a cluster (at U Sydney, I think) using FreeBSD. Hey: wouldn't it be cool if, when you manually suspended your laptop, the processes waiting for user input would be suspended to disk, but the CPU-bound one running a simulation would migrate to your main compute server. It might even be finished the next time you logged in... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI project progress report
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 the normal swap > > partition? If that was done, then they would just page > > themselves back in as needed, on wake-up. > > Because swap doesn't work that way anymore. They days where every page of > memory had to be backed by disk are long gone. This means that there may > not be anywere to put processes which are in memory unless you allocate > somewhere to save all (or practicaly all) of memory. But to do the proposed state save to disk, there _must_ be enough disk space to back all of the process pages. > In any case, I > haven't seen many laptops capable of using more then 256MB of RAM which > isn't exactly much of a modern disk. My laptop has 256MB of RAM and > ships with up to a 10GB disk. I've retrofitted it with a non-standard > 18GB disk because 10GB looked too small for my needs. Even with the 6.4GB > disk it shipped with, the suspend to disk partition is only 4% of my disk. 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 and using the existing swap pager? Processes do still wind up in "sleep" state, completely paged out, don't they? -- Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI project progress report
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 > "server-class" operating system in that you have to worry about network > connections from other systems, not just _to_ other systems. Don't the normal TCP timeouts take care of existing connections? I doubt that a "server class" system will be going into suspend mode for any reason, but I would imagine that suspend/resume should look much like network outage for the clients of suspended servers. For the only place that I can see it mattering (laptops), I suspect that suspend/resume should be an X session manager and application level job, and the kernel should just shutdown and boot as normal. I know that there aren't too many X applications that do all of the session management things, but maybe that would change if suspend actions interacted with the popular desktops in the appropriate way. -- Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI project progress report
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 and using the existing swap > pager? Because our swapper doesn't work that way. Generally speaking, swappers don't work that way anymore. Systems that suspend to disk are a corner case for FreeBSD. > 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 even with ~5MB Eterm processes sitting unused for days. I suppose if I let memory get tight, they might get ditched in favor of disk cache, but I haven't seen that happen. Someone with a better grasp of the VM could give a more preciese answer. -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
