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-hackers" in the body of the message
Re: freebsd bios.
I never said it would be easy, I simply was stating that the reference designs tend to stick to documented specifications, typically. Of course, writing a BIOS is hard enough. John Baldwin had the audacity to say: > On 19-Jun-00 Coleman Kane wrote: > > If you start out with a board based on a reference design, say the Intel > > SE440BX, you already have access to all this info. Most chipset vendors have > > info on this sort of thing up on their webpage, I know intel is really good > > about this sort of thing (though I am not so sure about the 810/815/820/840 > > chipsets). > > Not the chipset, all the hardware like the PIC's, the RTC, the CPU fan, > the keyboard controller, etc. etc. ad nauseum. Go back earlier in the > thread and read some of the AML Mike posted that has to be done just to > turn the CPU fan on. > > > Mike Smith had the audacity to say: > >> > >> > On Sat, 17 Jun 2000 07:35:51 +0900, "Daniel C. Sobral" wrote: > >> > > > >> > >Loader(8) runs using BIOS services, and loads the kernel from any drive > >> > >that BIOS recognizes. It has also been enhanced with PXE knowledge, so > >> > >he can load from that to. > >> > > >> > My mistake, as Ron pointed out, since loader uses the BIOS services, it > >> > can't run when there is no BIOS. Now if someone writes a loader that > >> > doesn't use a BIOS... > >> > >> You could easily do this, just as soon as you find a motherboard vendor > >> that will tell you how to initialise all their hardware. > > -- > > John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ > PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc > "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ > -- Coleman Kane President, UC Free O.S. Users Group - http://pohl.ececs.uc.edu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ACPI project progress report
In message <[EMAIL PROTECTED]> Mike Smith writes: : Can we guarantee that we can find this area? On eg. the Dell i7500 that : I've been playing most with, it's a file on a FAT filesystem, and the : BIOS will only "find" it if the filesystem is in the 'active' partition : at boot time. Generally we cannot guarnatee that. IIRC, there's lots of variation. Usually it is just a partition, but sometimes it is the last N cylenders of the disk, and sometimes it is a file like you say. It would at the very least need to be configured... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ACPI project progress report
> [[ cc trimmed ]] > > S4 state is the lowest power, longest wakeup latency state supported > by acpi. In this state all devices are powered down. The OS context > is preserved. That's how it is different from the G3 state > (shutdown/power off). It is not safe to take the computer apart when > in S4 state, but it is in G3 state. In addition, the machine may > automatically be awoken from the S4 state, but not the G3 state. > > Personally, I don't see why we can't just save to the > partition/reserved area on the disk that is used for the current BIOS > save to disk functionality. Can we guarantee that we can find this area? On eg. the Dell i7500 that I've been playing most with, it's a file on a FAT filesystem, and the BIOS will only "find" it if the filesystem is in the 'active' partition at boot time. -- \\ 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-hackers" in the body of the message
RE: install / boot last 3 gig of 25 gig drive
On 19-Jun-00 Jeff Kreska wrote: > > > I think there is something wrong with the install prog. Well, our geometry stuff isn't perfect, but part of that is do to the poor design of PC hardware. > 2 things to note: > The partition table is corrupt after a install. (even if I don't install > anything and just go into the intaller's fdisk like screen and type "w".) How do you know it is corrupt other than that it doesn't boot? > If I set the BSD partition active the system beeps at start up and says no > Operating System. You aren't using boot0, you are using /boot/mbr, which probably doesn't grok EDD, and thus can't deal with 1024 cylinders. > Are there specs for how to create a partition past the 1024 cyl? > I would like to verify that the installer is writing the correct entries to > the disk. If you formatted this disk with Windows before installing BSD (or if it came pre-formatted for example) then sysinstall got it right. -- John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: freebsd bios.
On 19-Jun-00 Coleman Kane wrote: > If you start out with a board based on a reference design, say the Intel > SE440BX, you already have access to all this info. Most chipset vendors have > info on this sort of thing up on their webpage, I know intel is really good > about this sort of thing (though I am not so sure about the 810/815/820/840 > chipsets). Not the chipset, all the hardware like the PIC's, the RTC, the CPU fan, the keyboard controller, etc. etc. ad nauseum. Go back earlier in the thread and read some of the AML Mike posted that has to be done just to turn the CPU fan on. > Mike Smith had the audacity to say: >> >> > On Sat, 17 Jun 2000 07:35:51 +0900, "Daniel C. Sobral" wrote: >> > > >> > >Loader(8) runs using BIOS services, and loads the kernel from any drive >> > >that BIOS recognizes. It has also been enhanced with PXE knowledge, so >> > >he can load from that to. >> > >> > My mistake, as Ron pointed out, since loader uses the BIOS services, it >> > can't run when there is no BIOS. Now if someone writes a loader that >> > doesn't use a BIOS... >> >> You could easily do this, just as soon as you find a motherboard vendor >> that will tell you how to initialise all their hardware. -- John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: freebsd bios.
On 18-Jun-00 Parag Patel wrote: > On Sat, 17 Jun 2000 07:35:51 +0900, "Daniel C. Sobral" wrote: >> >>Loader(8) runs using BIOS services, and loads the kernel from any drive >>that BIOS recognizes. It has also been enhanced with PXE knowledge, so >>he can load from that to. > > My mistake, as Ron pointed out, since loader uses the BIOS services, it > can't run when there is no BIOS. Now if someone writes a loader that > doesn't use a BIOS... Basically, you'd have to replace libi386 in src/sys/boot/i386/libi386. > -- Parag Patel -- John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: FBSDBOOT.EXE, Vi and DosCMD.
On 18-Jun-00 Gustavo Pamplona wrote: > Hi, BSDusers. > > I know I ought to post these 2 questions to questions mailing list. > > How can I use FBSDBOOT.EXE? When I try to use it, it give me a error of > "Invalid Format!", I think is the kernel was compiled for Elf format, so, > is there a way to compile the kernel in the Static Format, Stripped or not > Stripped. FBSDBOOT.EXE hasn't worked for years. It should be taken off the CD. > Vi, the editor, one dumb question, is there a way to select more text than > one line? The command 'yy' only select one line. Well, when I use, for > example, the Vi of my Linux Slackware, I can press 'v' at my keyboard, and > I can use both arrow keys or 'h,j,k,l' to select the text, been after I > press 'y' to select 'yank the lines' Type a number in for the number of lines you want to yank and then type yy. For example, 10yy yanks 10 lines. You can also use the 'm' command to set a mark and then yank from that mark to the current line. For example, go to the first line of the region and type 'ma'. Now move down to the line below the last line in the region you want to yank and type 'y`a'. See the vi man page for more info on marks, etc. -- John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ACPI project progress report
[[ cc trimmed ]] S4 state is the lowest power, longest wakeup latency state supported by acpi. In this state all devices are powered down. The OS context is preserved. That's how it is different from the G3 state (shutdown/power off). It is not safe to take the computer apart when in S4 state, but it is in G3 state. In addition, the machine may automatically be awoken from the S4 state, but not the G3 state. Personally, I don't see why we can't just save to the partition/reserved area on the disk that is used for the current BIOS save to disk functionality. The S5 state is like the G3 state, but it can be left via software, while the G3 state cannot. At least that's what my copy of the acpi spec tells me. That's why they are different. It is a subtle distinction, but one that is worth making, imho, if we are going to suppport ACPI to its fullest. I think that we'll need to support this eventually. Iwasaki-san's demo on the tokyo train was certainly interesting. I liked it very much. He was also talking about the problems of some BIOS' S2 and S3 sleep states needing a protected mode driver, or something of the sort to deal with properly... That's going to be interesting. I read that the S3 state is exited via the reset vector maybe in real-mode... The spec was a little unclear on this point, or maybe I've not read enough of it :-) Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" 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-hackers" in the body of the message
Re: PCI Plug 'n' Pray and old BIOSes
> > > Perhaps all I need to do is toggle the PnP BIOS setting, but before I > > > pull out the screwdrivers and tear the two machines apart again, I'm > > > hoping to draw on someone else's experience here. > > BTW will setting the PnP BIOS to `enabled' have any effect? It shouldn't in your case, as you're performing your own resource allocation. It's possible that IRQ 12 is a poor choice with your board. -- \\ 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-hackers" 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-hackers" 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-hackers" 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-hackers" 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-hackers" 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-hackers" 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-hackers" 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-hackers" in the body of the message
Re: 3dfx driver for freebsd
"Jordan K. Hubbard" wrote: > > > Seeing as how it has been a link on Daemon News' front page for several > > months, I find that hard to believe. :-P > > Not all of us read daemon news, either. As far as I'm concerned, if > it's not part of www.freebsd.org, it doesn't exist. :-) /me removes all references to Jordan from www.freebsd.org. -- 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-hackers" 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-hackers" in the body of the message
Re: freebsd bios.
Parag Patel wrote: > > Well, it's more of a matter of putting the kernel itself into the boot > ROM with some small assembly/C code to turn on DRAM and an ungzipper to > load and run it. It's fairly simple, other than dealing with the > various motherboard/chipset vagaries. Ah, yes, I forgot about that part. Still evil, but better. :-) > Personally, I'd set it up to hold two kernel images - one for testing > and one for emergency recovery. If a bad kernel gets into the flash, > recovering will be ... painful. But there may not be enough room. Heh. :-) Yeah, that would be... desirable... :-) -- 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-hackers" 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-hackers" in the body of the message
Re: freebsd bios.
On Mon, 19 Jun 2000, Parag Patel wrote: > It's fairly simple, other than dealing with the > various motherboard/chipset vagaries. So far those vagaries are not much code, something like 200 lines tops. > It's possible to make a complete BIOS based on Linux that in turn loads > and boots another kernel, but that I don't think that this is what the > LinuxBIOS folks are attempting. Actually, we aren't attempting it, we've got it working. see the LOBOS paper on the www.linuxbios.org web page. One option is that we start linux from NVRAM, talk to a DHCP server, and as a result we suck a kernel down over the network and boot it. Linux (or FreeBSD) make far more capable network boot programs than such things as PXE. And LinuxBIOS is SMALLER than the Intel BIOS it replaces. You can get complicated. LinuxBIOS loads, talks to DHCP, is sent some KLDs, the KLDs drive the boot device, and so on. So the thing in NVRAM can be little more than a netboot. A number: sun's net bootstrap is 200K. > Instead they have (or will have) access to the flash from within Linux > to load a kernel directly into flash (along with its startup code) > rather than placing it into /. (Please correct me if I'm wrong.) You have both options. We're going to use them. > Personally, I'd set it up to hold two kernel images - one for testing > and one for emergency recovery. If a bad kernel gets into the flash, > recovering will be ... painful. But there may not be enough room. There will be enough in future, next generation mainboards have 2 MB or more flash. My cheap DFI mainboard at home has 2 MB flash. For now, there is enough room in current mainboards, and more to come (I am told that the current driver for flash is MP3 players, which only demand more and more and more and ...) ron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" 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-hackers" in the body of the message
Re: PCI Plug 'n' Pray and old BIOSes
At 11:05 19.06.00 +0200, Graham Wheeler wrote: >Hi all > >I have a Genius Hub Card (basically an Ethernet NIC that also acts as a >four port hub). I would ideally like to use this card in an old 486DX4 >machine which acts as a ppp router. The card is detected (under both >Windoze and FreeBSD) as a RealTek card (the model number escapes me >right now). > >I installed 4.0-R on this machine, which detects the card, but gives me >"ed0: device timeout" messages. Usually this is because the interrupt is >misconfigured, but I don't think that is the case here. > >As I was under time pressure, I pulled the card out and put it in a >different machine, this one a P166 which works fine (with the same IRQ). > >Anyway, when I get a chance I would like to try it again in the 486. The >486 has three PCI slots, and the BIOS has some additional settings which >may be the reason it wasn't working. I'm unfamiliar with what some of >these do, and am hoping that someone on the list may have experience >with early days of PCI and Plug 'n Play, and be able to help. > >These are the settings: > >Slot n IRQ Line (this is the only one I set on my first attempt, to 12) >Slot n Latency Timer (ranges from 0..255 PCICLK) (was on 255) >On Board PCI/SCSI BIOS Enabled/Disabled (was disabled) >CC State Machine: > Data Write 0 WS Enabled/Disabled (was disabled) > Data Read 0 WS Enabled/Disabled (was disabled) Hi! The card normally should act and behave at least as a normal NE2000 clone (ed0) But as stated before, you might have to jumper it into the mobo. Also the PCI latency is IMHO too high. Try setting it at around 40. If you want to check out possible IRQ conflicts (at least on PCI bus with vid cards), there are some programs (ok, DOS based) that give out very reliable figures. Otherwise try the config utility of the card and put it into jumperless mode, no pnp. Regards Olaf Hoyer Olaf Hoyer www.nightfire.demailto:[EMAIL PROTECTED] FreeBSD- Turning PC's into workstations ICQ:22838075 Liebe und Hass sind nicht blind, aber geblendet vom Feuer, dass sie selber mit sich tragen. (Nietzsche) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: freebsd bios.
On Tue, 20 Jun 2000 07:06:36 +0900, "Daniel C. Sobral" wrote: > >And, in the process, they are teaching the firmware about Ext2FS, >Ext3FS, RheiserFS, (in our case) ffs, vinum, etc, so it can find the >kernel in whatever place it is, or resorting to some sort of bootfs >(though any software RAID would still have to be taught), with it's >inherent disadvantages? Well, it's more of a matter of putting the kernel itself into the boot ROM with some small assembly/C code to turn on DRAM and an ungzipper to load and run it. It's fairly simple, other than dealing with the various motherboard/chipset vagaries. It's possible to make a complete BIOS based on Linux that in turn loads and boots another kernel, but that I don't think that this is what the LinuxBIOS folks are attempting. Instead they have (or will have) access to the flash from within Linux to load a kernel directly into flash (along with its startup code) rather than placing it into /. (Please correct me if I'm wrong.) Personally, I'd set it up to hold two kernel images - one for testing and one for emergency recovery. If a bad kernel gets into the flash, recovering will be ... painful. But there may not be enough room. -- Parag Patel To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: freebsd bios.
Parag Patel wrote:
>
> It can't, without shitloads of drivers. :)
>
> ("I asked you not to tell me that, Ninety-Nine!")
>
> A new loader would need to be written that would have a way to talk to
> whatever firmware is in the box, Open Firmware, LinuxBIOS, etc.
> (Assuming that the firmware has a proper call-back API, like IEEE-1275.)
>
> Otherwise the loader will be about as complicated as the kernel itself.
> So it may as well *be* the kernel and use the same drivers. But then it
> stills needs a way to bootstrap it from ROM.
>
> Which is why the LinuxBIOS folks are trying to use Linux as the BIOS. :)
And, in the process, they are teaching the firmware about Ext2FS,
Ext3FS, RheiserFS, (in our case) ffs, vinum, etc, so it can find the
kernel in whatever place it is, or resorting to some sort of bootfs
(though any software RAID would still have to be taught), with it's
inherent disadvantages?
If what you describe is accurate... imho, that's the diametrical
oppositve of the right way.
--
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-hackers" 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-hackers" in the body of the message
Unknown exception/trap confusion
Ok, I've got a system that seems to spuriously "panic: unknown/reserved
trap". In trying to figure out which exception got triggered, I did a
backtrace...
(kgdb) bt
#0 boot (howto=256) at ../../kern/kern_shutdown.c:303
#1 0xc016a355 in panic (fmt=0xc02c58d9 "unknown/reserved trap") at
../../kern/kern_shutdown.c:553
#2 0xc02821ea in trap_fatal (frame=0xd907ebfc, eva=0) at ../../i386/i386/trap.c:929
#3 0xc0281b37 in trap (frame={tf_fs = 24, tf_es = 65552, tf_ds = -653852656, tf_edi =
4, tf_esi = -866895904,
tf_ebp = -653792120, tf_isp = -653792216, tf_ebx = -1066888788, tf_edx =
-1070536316, tf_ecx = 16777218,
tf_eax = 1862615194, tf_trapno = 29, tf_err = 0, tf_eip = -1071493032, tf_cs =
8, tf_eflags = 518, tf_esp = -1071172139,
tf_ss = -1042059264}) at ../../i386/i386/trap.c:589
#4 0xc0225058 in ti_intr (xsc=0xc) at ../../pci/if_ti.c:1938
#5 0xc027c11f in smp_invltlb () at machine/mpapic.h:104
#6 0xc027dd42 in pmap_qremove (va=3443085312, count=4) at ../../i386/i386/pmap.c:818
#7 0xc01918fc in vfs_vmio_release (bp=0xcc5437e0) at ../../kern/vfs_bio.c:1270
#8 0xc0191dfe in getnewbuf (slpflag=0, slptimeo=0, size=16384, maxsize=16384) at
../../kern/vfs_bio.c:1551
#9 0xc0192a01 in getblk (vp=0xd9928000, blkno=2, size=16384, slpflag=0, slptimeo=0)
at ../../kern/vfs_bio.c:2195
#10 0xc019506e in cluster_rbuild (vp=0xd9928000, filesize=136472, lbn=1,
blkno=189541632, size=16384, run=2, fbp=0x0)
at ../../kern/vfs_cluster.c:391
#11 0xc0194c72 in cluster_read (vp=0xd9928000, filesize=136472, lblkno=1, size=16384,
cred=0x0, totread=2820, seqcount=2,
bpp=0xd907ee68) at ../../kern/vfs_cluster.c:229
#12 0xc0238666 in ffs_read (ap=0xd907ee8c) at ../../ufs/ufs/ufs_readwrite.c:252
#13 0xc01a00fc in vn_read (fp=0xc2dacb80, uio=0xd907eed8, cred=0xc32e1d00, flags=0,
p=0xd6952440) at vnode_if.h:334
#14 0xc017a889 in dofileread (p=0xd6952440, fp=0xc2dacb80, fd=18, buf=0x816f035,
nbyte=2820, offset=-1, flags=0)
at ../../sys/file.h:141
#15 0xc017a78f in read (p=0xd6952440, uap=0xd907ef80) at ../../kern/sys_generic.c:111
#16 0xc0282511 in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds = 135594031, tf_edi =
0, tf_esi = 0, tf_ebp = 0,
tf_isp = -653791276, tf_ebx = 140614144, tf_edx = 140614144, tf_ecx = 140614144,
tf_eax = 3, tf_trapno = 7, tf_err = 2,
tf_eip = 673047244, tf_cs = 31, tf_eflags = 663, tf_esp = -1077937696, tf_ss =
47}) at ../../i386/i386/trap.c:1126
In frame 3, trap is getting called with tf_trapno equal to 29... Which
according to machine/trap.h is:
#define T_RESERVED 29 /* reserved (unknown) */
It's getting set that way from the idt vector in exception.s:
IDTVEC(rsvd)
pushl $0; TRAP(T_RESERVED)
because all exceptions that aren't specifically mapped to a idt vector are
pointed to IDTVEC(rsvd) in machdep.c:
for (x = 0; x < NIDT; x++)
setidt(x, &IDTVEC(rsvd), SDT_SYS386TGT, SEL_KPL, GSEL(GCODE_SEL,
SEL_KPL));
My question is... How am I going to tell which exception is actually getting
called? Is it completely unreasonable to have the rsvd idt vector call trap
with the trap value + MAX_TRAP_MSG or some other constant, so that trap()
can tell what the real exception was?
Without knowing which exception really got called, troubleshooting this is
more difficult, but... I can't quite figure out what's going on in ti_intr
that could cause an exeception... It appears that ti_intr is just getting
things off the stack when it crashes:
#4 0xc0225058 in ti_intr (xsc=0xc) at ../../pci/if_ti.c:1938
1938}
(kgdb) list
1933
1934if (cur_tx != NULL)
1935ifp->if_flags &= ~IFF_OACTIVE;
1936
1937return;
1938}
1939
1940static void ti_intr(xsc)
1941void*xsc;
1942{
(kgdb) disassemble
Dump of assembler code for function ti_intr:
0xc0225058 : push %ebp
0xc0225059 : mov%esp,%ebp
0xc022505b : push %esi
0xc022505c : push %ebx
0xc022505d : mov0x8(%ebp),%esi
0xc0225060 : mov%esi,%ebx
(kgdb) info frame
Stack level 4, frame at 0xd907ec88:
eip = 0xc0225058 in ti_intr (../../pci/if_ti.c:1938); saved eip 0xc027c11f
called by frame at 0xd907ec9c, caller of frame at 0xd907ebf4
source language c.
Arglist at 0xd907ec88, args:
Locals at 0xd907ec88, Previous frame's sp is 0x0
Saved registers:
ebx at 0xd907ec80, ebp at 0xd907ec88, esi at 0xd907ec84, eip at 0xd907ec8c
(kgdb) info registers
eax0x0 0
ecx0x0 0
edx0x0 0
ebx0x6f05409a 1862615194
esp0xd907eb58 0xd907eb58
ebp0xd907ec88 0xd907ec88
esi0xcc5437e0 -866895904
edi0x4 4
eip0xc02701ab 0xc02701ab
eflags 0x0 0
cs 0x0 0
ss 0x0 0
ds 0x0 0
es 0x0 0
fs cannot read u area ptr for proc at 0
I'm a bit over my head
Re: Little "Complain"
Hi! > >So if one of the "high" people agree with this idea, I could set up such a > >system (well I have to look for a constant internet connection, but I > >suppose my ISP will give me one for free when his name is listed on the > >contribution list :-)). > > We don't need any "high" people to agree with this: Just do it, if it > works, people will use it and it will become a success, if it doesn't > work...well you can say that you tried :-) Sounds good! OK. I'll check for a non-interrupted internet connection tomorrow and then I'll give further details. Kind regards, Freddy To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: freebsd design model
Hi! > You can make an announcement that you're working on it, and what > you hope to acoomplish. > [..] > > > > What about this idea? > > The FreeBSD project has well over 150 people working on it, you > can't mark off large parts of the system as your own. The idea is > to work together concurrantly, occasionally there's some overlap, > but usually it's a good thing because in that case the two works > can be merged together as something better. > > Don't worry too much about overlap, just do what you want to and > submit it, the chances of collision are so small that the system > you're suggesting would be too heavyweight for most of my needs. OK. So I don't do it! :-) I just found it very cool as we did it last time! Regards, Freddy To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Anybody working on FreeBSD BIOS?
On Mon, 19 Jun 2000, Ronald G Minnich wrote: > On Mon, 19 Jun 2000, Neil Blakey-Milner wrote: > > On Thu 2000-06-15 (15:25), Ronald G Minnich wrote: > > 'linuxbios' will only support booting off Linux partitions? > > linuxbios is getting to be a misnomer, but ... > > linuxbios is a simple chunk of FLASH-based code that gunzips a kernel > image to RAM. That's it. It doesn't do much of anything but get DRAM > turned on (not hard) and some other bits that OSes don't yet do well. > Our long term goal is not to control this thing. Best case scenario is > the vendors buy in and support it directly. We have one case in hand > where this is happening. Mainboards from this one vendor will ship with > LinuxBIOS in flash. Hmm. It seems like it would just make more sense for the motherboard manufacturers to (a) fix their BIOS's to allow serial-port access, and (b) provider more flash where you can stuff a "disk" image to boot from, with appropriate support for accessing it as an IDE or floppy drive. That way it works with all versions of all operating systems (well, only those that can do the serial console stuff, of course). Doing LinuxBIOS seems like the long way around, here. I can't imagine that serial-port BIOS access hasn't happened because it's too hard - it's just because BIOS makers don't care. Nonetheless, it is a cool notion, scott To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
freebsd design model
* Frederik Meerwaldt <[EMAIL PROTECTED]> [000619 11:34] wrote: > Hi all, > > this message is especially for the developers or other people who > contribute FreeBSD. > I just thought today, that I could write a little bit documentation for > the PCMCIA stuff... (That's what on the TODO List). But if I start now, > how can I verify that there's nobody else who writes this? You can make an announcement that you're working on it, and what you hope to acoomplish. > So I had an Idea: > > What about setting a computer in the internet on which everyone can have > an own account and with a self-written program on it which does the > following: > > The Program has the Items of the ToDo list in it. > Every user can say, that he'll do this or that item, and that will be > registered in the system, so that nobody else does this work, too, else > only the code of 1 programmer will be used (you can hardly mix different > code). That is for Coding as well as for documentation. > The background is the following: > > I was developer on a "huge" project (we were 40 people, so nothing against > the FreeBSD team), and there we had such a system and everybody was > happy. If I wanted to write a part I saw... oh, user xxx has checked it > out. > > So if one of the "high" people agree with this idea, I could set up such a > system (well I have to look for a constant internet connection, but I > suppose my ISP will give me one for free when his name is listed on the > contribution list :-)). > > What about this idea? The FreeBSD project has well over 150 people working on it, you can't mark off large parts of the system as your own. The idea is to work together concurrantly, occasionally there's some overlap, but usually it's a good thing because in that case the two works can be merged together as something better. Don't worry too much about overlap, just do what you want to and submit it, the chances of collision are so small that the system you're suggesting would be too heavyweight for most of my needs. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Little "Complain"
>So if one of the "high" people agree with this idea, I could set up such a >system (well I have to look for a constant internet connection, but I >suppose my ISP will give me one for free when his name is listed on the >contribution list :-)). We don't need any "high" people to agree with this: Just do it, if it works, people will use it and it will become a success, if it doesn't work...well you can say that you tried :-) -- 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-hackers" in the body of the message
Little "Complain"
Hi all, this message is especially for the developers or other people who contribute FreeBSD. I just thought today, that I could write a little bit documentation for the PCMCIA stuff... (That's what on the TODO List). But if I start now, how can I verify that there's nobody else who writes this? So I had an Idea: What about setting a computer in the internet on which everyone can have an own account and with a self-written program on it which does the following: The Program has the Items of the ToDo list in it. Every user can say, that he'll do this or that item, and that will be registered in the system, so that nobody else does this work, too, else only the code of 1 programmer will be used (you can hardly mix different code). That is for Coding as well as for documentation. The background is the following: I was developer on a "huge" project (we were 40 people, so nothing against the FreeBSD team), and there we had such a system and everybody was happy. If I wanted to write a part I saw... oh, user xxx has checked it out. So if one of the "high" people agree with this idea, I could set up such a system (well I have to look for a constant internet connection, but I suppose my ISP will give me one for free when his name is listed on the contribution list :-)). What about this idea? Awaiting responses, Freddy To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PCI Plug 'n' Pray and old BIOSes
On 2000-06-19 15:32 +0200, Graham Wheeler <[EMAIL PROTECTED]> wrote: > Stefan Esser wrote: > > Is the PS/2 mouse interface enabled ? It will try to grab IRQ 12, > > and may do so in a way that the IRQ can't be delivered from ISA > > or PCI slots ... > > The may be a psm driver in the kernel, but there is no PS/2 mouse device > on the motherboard or on any of the cards. The BIOS may configure the chip-set to directly connect the PS/2 mouse to IRQ 12 in a hardware specific way. Use of IRQ 12 for PCI interrupts may be impossible, but the PCI or Ethernet drivers can't tell, because it is all a function of chip-set internals. It doesn't matter whether there are any PS/2 drivers or even a PS/2 plug. > > > Perhaps all I need to do is toggle the PnP BIOS setting, but before I > > > pull out the screwdrivers and tear the two machines apart again, I'm > > > hoping to draw on someone else's experience here. > > BTW will setting the PnP BIOS to `enabled' have any effect? Not sure. You didn't tell anything about the system. I assume it is one of the Saturn I or Saturn II based boards, which were the first reliably working PCI based PC mainboards. Verbose boot messages may help, too, since they provide a lot of details about the hardware and the configuration performed by the BIOS. PnP BIOS usually applies to ISA PnP cards and should have no impact on PCI. But if your system predates ISA PnP, the term may well be used to toggle a PCI chip-set or bus initialisation feature. > I'll have to check that; I do still have the mboard manual somewhere. Ok. If you can't get it to work, then please send at least the following information: * name of mainboard (brand and model) * verbose boot message log Regards, STefan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" 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-hackers" 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-hackers" 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-hackers" 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-hackers" 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-hackers" 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-hackers" in the body of the message
procmail broken?
Does anyone know of any commits to 4-stable in the past three weeks that would have broken procmail (probably related the locking)? I just synched Sunday, and it broke procmail. I've recompiled from the ports directory, and that didn't help. Interestingly (and strangely), it works when I turn on verbose debugging :-( --mark To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" 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-hackers" 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-hackers" in the body of the message
LDAP, PAM, NSS
What is the current status of using an LDAP server together with PAM for authentication in FreeBSD? Has anybody got around to implement a working solution for configuring the name service information routines in libc (e.g. nsswitch.conf or something similar)? Search in the mailing list archives showed that there was some discussion about this topic about a year ago, and some people seemingly working on solutions, but I have found nothing since August 1999. I'd appreciate it if those who were concerned would mail me about their results (or unsurmountable problems or reasons for abandoning the project). I'm also interested in any pointers to information about the topic. Thanks in advance Olaf -- /\ || Olaf Wagner | [EMAIL PROTECTED] (private) | || Cranachstrasse 7 | [EMAIL PROTECTED] (business)| || D-12157 Berlin| phone: +49 30 85 58 01 81| || Germany / Deutschland | fax: +49 30 85 58 01 88| \/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Anybody working on FreeBSD BIOS?
On Mon, 19 Jun 2000, Neil Blakey-Milner wrote: > On Thu 2000-06-15 (15:25), Ronald G Minnich wrote: > 'linuxbios' will only support booting off Linux partitions? linuxbios is getting to be a misnomer, but ... linuxbios is a simple chunk of FLASH-based code that gunzips a kernel image to RAM. That's it. It doesn't do much of anything but get DRAM turned on (not hard) and some other bits that OSes don't yet do well. Although, I am finding that increasingly the open source OSes are taking on more and more hardware tasks because so many BIOSes screw up hardware config. The APIC support in the more recent kernels is pretty amazing. LinuxBIOS DOES NOT: 1) read disks 2) talk to network cards 3) etc. It knows how to get ram up, it is mostly written in C (except for that 'get ram up' part, obviously), and it counts on the OS to do the heavy lifting. It works on two very different motherboards. We're working on an Alpha port now. Our long term goal is not to control this thing. Best case scenario is the vendors buy in and support it directly. We have one case in hand where this is happening. Mainboards from this one vendor will ship with LinuxBIOS in flash. We have a couple of industrial partners at this point, including a new one that just wrote me this morning who you would recognize (you'll see their name on the web page in a week or so). I would love to see FreeBSD support work. I can't do it much anymore, since unfortunately the HPC cluster community seems less and less concerned with FreeBSD nowadays, which I think is a tragedy. But I'll do what I can. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PCI Plug 'n' Pray and old BIOSes
Stefan Esser wrote: > > On 2000-06-19 11:05 +0200, Graham Wheeler <[EMAIL PROTECTED]> wrote: > > As I was under time pressure, I pulled the card out and put it in a > > different machine, this one a P166 which works fine (with the same IRQ). > > These are the settings: > > > > Slot n IRQ Line (this is the only one I set on my first attempt, to 12) > > Is the PS/2 mouse interface enabled ? It will try to grab IRQ 12, > and may do so in a way that the IRQ can't be delivered from ISA > or PCI slots ... The may be a psm driver in the kernel, but there is no PS/2 mouse device on the motherboard or on any of the cards. > > Perhaps all I need to do is toggle the PnP BIOS setting, but before I > > pull out the screwdrivers and tear the two machines apart again, I'm > > hoping to draw on someone else's experience here. BTW will setting the PnP BIOS to `enabled' have any effect? > Depending on the time when the mainboard was built, this may be a > board that needs jumpers configured accordingly (i.e. you have to > enter the jumper settings in the BIOS, which will put the number > in the appropriate config space register, but interrupt routing is > implemented via jumper fields ...) I'll have to check that; I do still have the mboard manual somewhere. regards gram -- Dr Graham WheelerE-mail: [EMAIL PROTECTED] Director, Research and Development WWW:http://www.cequrux.com CEQURUX Technologies Phone: +27(21)423-6065 Firewalls/VPN SpecialistsFax:+27(21)424-3656 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PCI Plug 'n' Pray and old BIOSes
On 2000-06-19 11:05 +0200, Graham Wheeler <[EMAIL PROTECTED]> wrote: > As I was under time pressure, I pulled the card out and put it in a > different machine, this one a P166 which works fine (with the same IRQ). > > Anyway, when I get a chance I would like to try it again in the 486. The > 486 has three PCI slots, and the BIOS has some additional settings which > may be the reason it wasn't working. I'm unfamiliar with what some of > these do, and am hoping that someone on the list may have experience > with early days of PCI and Plug 'n Play, and be able to help. > > These are the settings: > > Slot n IRQ Line (this is the only one I set on my first attempt, to 12) Is the PS/2 mouse interface enabled ? It will try to grab IRQ 12, and may do so in a way that the IRQ can't be delivered from ISA or PCI slots ... > Perhaps all I need to do is toggle the PnP BIOS setting, but before I > pull out the screwdrivers and tear the two machines apart again, I'm > hoping to draw on someone else's experience here. Depending on the time when the mainboard was built, this may be a board that needs jumpers configured accordingly (i.e. you have to enter the jumper settings in the BIOS, which will put the number in the appropriate config space register, but interrupt routing is implemented via jumper fields ...) The first ASUS 486 board, for example, (the 486-SP3, based on the Saturn 1, chip revision 2) used jumpers, while the SP3G used the Saturn II (chip rev. 4) and there was an IRQ routing matrix in the chipset, which allowed for BIOS-only IRQ assignment. Regards, STefan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FBSDBOOT.EXE, Vi and DosCMD.
On Sun, 18 Jun 2000, Gustavo Pamplona wrote: > How can I use FBSDBOOT.EXE? When I try to use it, it give me a error of It doesn't work with ELF kernels. Check the archives. > Vi, the editor, one dumb question, is there a way to select more text than > one line? The command 'yy' only select one line. Well, when I use, for man vi. In short nyy where n is a number will select n lines. > example, the Vi of my Linux Slackware, I can press 'v' at my keyboard, and > I can use both arrow keys or 'h,j,k,l' to select the text, been after I > press 'y' to select 'yank the lines' That is probably vim which is in the ports collection. Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Anybody working on FreeBSD BIOS?
On Mon 2000-06-19 (11:45), Neil Blakey-Milner wrote: > 'linuxbios' will only support booting off Linux partitions? > > I doubt they're replacing a multi-purpose, occasionally > not-all-that-clever thing, with a single-purpose very-often > not-all-that-clever thing? Ah wait, having read a bit more, they are. Good luck to them. I would have thought that redo-ing the entire BIOS would be a bit extreme. A 'simpler' serial console video/keyboard interaction firmware chip would have been nice. If you really want to be funky, add in network support for TCP/IP-based BIOS interaction. Otherwise, for the five-nines, replacing the whole BIOS is extreme. (says he, wondering why malfunctioning hardware tends to make his brain malfunction) Neil -- Neil Blakey-Milner Sunesi Clinical Systems [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" 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-hackers" in the body of the message
Re: Anybody working on FreeBSD BIOS?
On Thu 2000-06-15 (15:25), Ronald G Minnich wrote: > well linuxbios is what I started here, and I pinged some folks on this > list about supporting freebsd as well as linux, and got a 'no interest' > back from some folks. > > I'm still up for it. I think it's easy. 'linuxbios' will only support booting off Linux partitions? I doubt they're replacing a multi-purpose, occasionally not-all-that-clever thing, with a single-purpose very-often not-all-that-clever thing? What 'support' will FreeBSD require in 'linuxbios'? Neil -- Neil Blakey-Milner Sunesi Clinical Systems [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
PCI Plug 'n' Pray and old BIOSes
Hi all I have a Genius Hub Card (basically an Ethernet NIC that also acts as a four port hub). I would ideally like to use this card in an old 486DX4 machine which acts as a ppp router. The card is detected (under both Windoze and FreeBSD) as a RealTek card (the model number escapes me right now). I installed 4.0-R on this machine, which detects the card, but gives me "ed0: device timeout" messages. Usually this is because the interrupt is misconfigured, but I don't think that is the case here. As I was under time pressure, I pulled the card out and put it in a different machine, this one a P166 which works fine (with the same IRQ). Anyway, when I get a chance I would like to try it again in the 486. The 486 has three PCI slots, and the BIOS has some additional settings which may be the reason it wasn't working. I'm unfamiliar with what some of these do, and am hoping that someone on the list may have experience with early days of PCI and Plug 'n Play, and be able to help. These are the settings: Slot n IRQ Line (this is the only one I set on my first attempt, to 12) Slot n Latency Timer (ranges from 0..255 PCICLK) (was on 255) On Board PCI/SCSI BIOS Enabled/Disabled (was disabled) CC State Machine: Data Write 0 WS Enabled/Disabled (was disabled) Data Read 0 WS Enabled/Disabled (was disabled) Perhaps all I need to do is toggle the PnP BIOS setting, but before I pull out the screwdrivers and tear the two machines apart again, I'm hoping to draw on someone else's experience here. Any ideas? TIA gram -- Dr Graham WheelerE-mail: [EMAIL PROTECTED] Director, Research and Development WWW:http://www.cequrux.com CEQURUX Technologies Phone: +27(21)423-6065 Firewalls/VPN SpecialistsFax:+27(21)424-3656 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
