Re: return to real mode
anybody got some reliable, tested, known-good code for getting back to real mode? I'm to the point where I have a working GDT, and paging is turned off, but the last step -- turning off protection enable -- is not working for me. You want to be more explicit about why you want to get back? There are possibly alternatives, or other collateral damage issues that might be worth commenting on. -- \\ 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: SCSI disk naming problem
See LINT on details of how to wire down scsi devices... Your proposal doesn't take adding a second scsi card into account. Well, I did not mean that has to be da0, da1, etc., but similar thing like dac0t0d0, dac0t1d0, ... dac3t4d0, etc. which is much clear what disk is. A few people does not like this one because the name is long, and it is like some commerical configuration. They said that this is Free software. Manually wiring down disks is OK for a small set of hosts. 100+ hosts with two or three controllers with 100 TB disks will be terribly pain during the setup and maintenance. -Jin On Fri, 1 Oct 1999 [EMAIL PROTECTED] wrote: Current FreeBSD SCSi disk naming mechanism is problem for using more than one disks in the chain during the disk failure. The problem is that the name is not fixed with is SCSI ID. e.g., if one disk is presented in the chain, regardless its SCSI ID, it is always named "da0"; if two disks are installed, the one with lower ID is named da0 and the other will be named as da1. When the lower ID one is crashed, then the other disk will be named as da0 (from da1) after reboot, and it is not mountable due to the name changing. If a system has a UW SCSI controller with 15 disks in the chain, when the first disk (ID = 0) crashed, all rest 14 disks will be useless until either fstab modified or another disk is added with SCSI ID = 0. Why not we use a fixed name corresponding the SCSI ID. That is, disk with ID 0 will be always named as da0, and disk with ID 1 will be always named da1, etc.? Is there problem with fixed disk naming mechanism? , To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FTP directory listing with ftpio(3) and fetch(3)
Jaakko Salomaa [EMAIL PROTECTED] writes: Hey, how am I supposed to fetch directory listing with ftpio(3) or fecth(3)? ftpio doesn't seem to contain necessary functions for it, and fetch's ones aren't implemented. Type 'man 3 fetch', scroll down to the BUGS section, and see the light. Next, scroll back up to the AUTHORS section and find out who to contact :) DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SCSI disk naming problem
See LINT on details of how to wire down scsi devices... Your proposal doesn't take adding a second scsi card into account. On Fri, 1 Oct 1999 [EMAIL PROTECTED] wrote: Current FreeBSD SCSi disk naming mechanism is problem for using more than one disks in the chain during the disk failure. The problem is that the name is not fixed with is SCSI ID. e.g., if one disk is presented in the chain, regardless its SCSI ID, it is always named "da0"; if two disks are installed, the one with lower ID is named da0 and the other will be named as da1. When the lower ID one is crashed, then the other disk will be named as da0 (from da1) after reboot, and it is not mountable due to the name changing. If a system has a UW SCSI controller with 15 disks in the chain, when the first disk (ID = 0) crashed, all rest 14 disks will be useless until either fstab modified or another disk is added with SCSI ID = 0. Why not we use a fixed name corresponding the SCSI ID. That is, disk with ID 0 will be always named as da0, and disk with ID 1 will be always named da1, etc.? Is there problem with fixed disk naming mechanism? -Jin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Huge Binaries..
Hi Julian, On Thu, 30 Sep 1999, Julian Elischer wrote: Has anyone looked at netscape Communicator 4.7 for FreeBSD??? I just installed it. the binary is 13234176 bytes long!! Is this much bigger than before? I usually use Navigator instead as I don't want all the bloat. The 4.61 version of navigator is 7712768 bytes. That's about 1/2 the size and if you're not using the composer, news reader or mailer you might as well toss Communicator in favor of Navigator. Brett * Brett Taylor [EMAIL PROTECTED]* Dept of Chem and Physics* Curie 39A (540) 831-6147 * * To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SCSI disk naming problem
On Fri, 1 Oct 1999 [EMAIL PROTECTED] wrote: Current FreeBSD SCSi disk naming mechanism is problem for using more than one disks in the chain during the disk failure. The problem is that the name is not fixed with is SCSI ID. e.g., if one disk is presented in the chain, regardless its SCSI ID, it is always named "da0"; if two disks are installed, the one with lower ID is named da0 and the other will be named as da1. When the lower ID one is crashed, then the other disk will be named as da0 (from da1) after reboot, and it is not mountable due to the name changing. If a system has a UW SCSI controller with 15 disks in the chain, when the first disk (ID = 0) crashed, all rest 14 disks will be useless until either fstab modified or another disk is added with SCSI ID = 0. Why not we use a fixed name corresponding the SCSI ID. That is, disk with ID 0 will be always named as da0, and disk with ID 1 will be always named da1, etc.? Is there problem with fixed disk naming mechanism? no, read the kernel LINT config file. -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] Wintelcom systems administrator and programmer - http://www.wintelcom.net/ [[EMAIL PROTECTED]] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Netscape Bus Error
Nate Williams wrote: In short, it's a netscape bug maybe not - i recently received buckets of these on a system i was experimenting with overclocking on - an upgraded heatsink fixed it. I've also seen it when I tweak the BIOS settings a bit too aggresively... -- Dave Cornejo - Dogwood Media, Fremont, California General Magician Registered Be Developer To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Tyan Dual PPRO Bios 5.1 problem...
Thanks for the help Soren, The disk is a Seagate Medalist 6.2 GB UDMA But now I have tested all PIO modes(0 - 4 and auto) and disabled udma. It still doesn't work. I get different results when I change PIO. Once I got some message like: Page fault: Couldn't init disk...(something) Any clue? /stefan Soren Schmidt wrote: It seems Stefan Lindgren wrote: I get page faults, kernel panic(trap 12) and the system won't boot. It looks that it could be memory related, but the system works fine with the EIDE disk. Hmm, probably because the system is getting bad data from the drive. Are you using (U)DMA ??, try to switch that off in the driver, or try to "dumb down" the drive in the BIOS (you can set the speed to PIO3 there and still run DMA allthough slower) that helped me and the drive I couldn't get to work otherwise. BTW what make/type of drive is it, it might be a known bad one -Soren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Tyan Dual PPRO Bios 5.1 problem...
It seems Stefan Lindgren wrote: Thanks for the help Soren, The disk is a Seagate Medalist 6.2 GB UDMA But now I have tested all PIO modes(0 - 4 and auto) and disabled udma. It still doesn't work. I get different results when I change PIO. Once I got some message like: Page fault: Couldn't init disk...(something) Any clue? Not really, have you tried with another disk ?? As said I had an older Maxtor that wouldn't work, but I've never had a problem since... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SCSI disk naming problem
[EMAIL PROTECTED] wrote: If memory serves me right, [EMAIL PROTECTED] wrote: See LINT on details of how to wire down scsi devices... Your proposal doesn't take adding a second scsi card into account. Well, I did not mean that has to be da0, da1, etc., but similar thing like dac0t0d0, dac0t1d0, ... dac3t4d0, etc. which is much clear what disk is. A few people does not like this one because the name is long, and it is like some commerical configuration. They said that this is Free software. That's an interesting argument on the part of a few people. The commercial UNIX I first adminned had wired down, short names for disks (rz0, rz1, rz2, ... ). This was very nice. This one does not resolve the controller problem either as [EMAIL PROTECTED] said. So, I guess dac0t0, dac0t1, ... dac3t4, will be good enough if we want to be short, but anything shorter than this will be meaningless. Manually wiring down disks is OK for a small set of hosts. 100+ hosts with two or three controllers with 100 TB disks will be terribly pain during the setup and maintenance. It depends on what you mean by "manually". Presumably, these 100+ hosts have fairly similar kernel configurations, so you only need to build a small number of "wired down" kernels, and then distribute these out to the hosts. I've found that that having wired down SCSI devices is a Good Thing (TM), and it's one of the first things that I fix when I start building kernels for a new version of FreeBSD. I guess I've just gotten used to it. Bruce. I guess you missed the point that I do want to wire down the name. This is the original debate. But, I do not want to wire down the name by hand. The system should be able to take care this simple thing. As you mentioned, digit UNIX does it, Solaris does it, why not FreeBSD? Because it is FreeWare so we cannot do some thing good as commercial UNIXs do? -Jin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
radix.c, Hey is this a bug ?
Hey is this a bug ?
I downloaded the code for radix.c and radix.h and was trying to get a
tree that looks
like the one in TCP/IP Illustrated V.2 page 563 A.K.A "the book". I set
up a test program to put the same data into the tree, page 560 and
noticed a couple of differences. This is a copy of the data I placed in
the tree:
struct myStuff MyStuff [MaxEntries] =
{
"127.0.0.0", 0xff00,
"127.0.0.1", 0x,
"128.32.33.5", 0x,
"140.252.13.32", 0xffe0,
"140.252.13.33", 0x,
"140.252.13.34", 0x,
"140.252.13.35", 0x,
"140.252.13.65", 0x,
"224.0.0.0", 0xff00,
"224.0.0.1", 0x,
"0.0.0.0", 0x,
};
For the first entry 127.0.0.0 with a subnet mask of 0xff 00 the
radix node entry's
mask pointer pointed to the one's entry i.e. radix node in the mask
tree. This caused
a problem with the search i.e. rn_matchaddr of 127.0.0.0, because the
length of the key was taken from this mask entry as 0xff. I have
modified the code to get the tree to look like
the one in "the book" but I have eliminated the benifit of removing
trailing zeros.
A couple of questions; 1. Can someone explain how the removal of
trailing zeros is
suppose to work.? 2. Is this a real bug or pilot error. If pilot error
what did I do wrong?
If it is a real bug the explaintion for question one (1) might help me
implement a solution, ya think?
My next step is to turn this code into a C++ class, has anyone already
done this?
Yea, I look around on the WWW, although maybe not in the right sites.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: SCSI disk naming problem
[EMAIL PROTECTED] wrote... On Fri, 1 Oct 1999 [EMAIL PROTECTED] wrote: Current FreeBSD SCSi disk naming mechanism is problem for using more than one disks in the chain during the disk failure. The problem is that the name is not fixed with is SCSI ID. e.g., if one disk is presented in the chain, regardless its SCSI ID, it is always named "da0"; if two disks are installed, the one with lower ID is named da0 and the other will be named as da1. When the lower ID one is crashed, then the other disk will be named as da0 (from da1) after reboot, and it is not mountable due to the name changing. If a system has a UW SCSI controller with 15 disks in the chain, when the first disk (ID = 0) crashed, all rest 14 disks will be useless until either fstab modified or another disk is added with SCSI ID = 0. Why not we use a fixed name corresponding the SCSI ID. That is, disk with ID 0 will be always named as da0, and disk with ID 1 will be always named da1, etc.? Is there problem with fixed disk naming mechanism? [ ... ] See LINT on details of how to wire down scsi devices... Your proposal doesn't take adding a second scsi card into account. Well, I did not mean that has to be da0, da1, etc., but similar thing like dac0t0d0, dac0t1d0, ... dac3t4d0, etc. which is much clear what disk is. A few people does not like this one because the name is long, and it is like some commerical configuration. They said that this is Free software. You can pretty easily write a script to create device nodes named whatever you want. As long as the major and minor numbers are correct, you can call what would be /dev/da0a /dev/dac0t0d0a or whatever you like. I think it is possible, however, to come up with a somewhat reasonable naming scheme within the current framework. Manually wiring down disks is OK for a small set of hosts. 100+ hosts with two or three controllers with 100 TB disks will be terribly pain during the setup and maintenance. I would suggest that you come up with a standard naming scheme, and then use it across all of your machines. You could do something like: controller ahc0 controller ahc1 controller ahc2 controller scbus0 at ahc0 controller scbus1 at ahc1 controller scbus2 at ahc2 device da0 at scbus0 target 0 unit 0 device da1 at scbus0 target 1 unit 0 device da2 at scbus0 target 2 unit 0 ... device da14 at scbus0 target 14 unit 0 device da20 at scbus1 target 0 unit 0 device da21 at scbus1 target 1 unit 0 ... device da34 at scbus1 target 14 unit 0 device da40 at scbus2 target 0 unit 0 device da41 at scbus2 target 1 unit 0 ... device da54 at scbus2 target 14 unit 0 If you've got reasonably consistent controller hardware across the machines, you could use one wiring setup like the one above for all the machines. If you have different controller drivers on the different machines, you could probably just elminate the controller-bus wiring and go from there. You can design a maximal wire-down configuration for your largest machine, and it should just work on smaller machines. For instance, if your large machine has 7 SCSI busses and 15 disks per chain, you could set them up as da0 through da134 or so. The wiring configuration, though, would work even for a machine with one disk. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
block, I/O, on, locked, vnode
The following is copied from the comments of FFS code: "Block devices associated with filesystems may have new I/O requests posted for them even if the vnode is *locked*, so no amount of trying will get them clean. Thus we give block devices a good effort, then just give up. For all other file types, go around and try again until it is clean." Can anyone explain to me when this situation will occur and, preferrably, point to the place of the related source code? Any help is appreciated. -Zhihui __ Get Your Private, Free Email at http://www.hotmail.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
block I/O on a locked vnode
The following is copied from the comments of FFS code: "Block devices associated with filesystems may have new I/O requests posted for them even if the vnode is *locked*, so no amount of trying will get them clean. Thus we give block devices a good effort, then just give up. For all other file types, go around and try again until it is clean." Can anyone explain to me when this situation will occur and, preferrably, point to the place of the related source code? Any help is appreciated. -- Zhihui Zhang. Please visit http://www.freebsd.org -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SCSI disk naming problem
If memory serves me right, [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: } Well...I personally prefer the short names. On systems with multiple } controllers, the commercial UNIX I used (Ultrix) just continued its } numbering with rz0, rz1, rz2, ..., rz6, rz7, rz8, ... FreeBSD lets you } do exactly the same thing. The thing is what is rz44 representing? If kernel spits: "rz44 hardware error 105: write failure -- replace it" Which disk are you going to shutdown and replace without looking at /etc/fstab or /sys/i386/conf/CRUEENT_RUN ? What happens if when you see the message and the host is hosed and needs to be rebooted -- at this time both above files are not available -- ? You have a good point, but I also believe that part of any good disaster recovery scheme is having critical system information (like /etc/fstab, dmesg output, etc.) in hardcopy form. And believe me, we've had enough disasters around here the past six months to see the value of that. :-( I do not think dac5t4 is that worse than rz44 (just two charaters long). Maybe it is better. You immediately know the disk with ID 4 on the SCSI controller 5 is one having trouble. And there's also two more characters you need to remember to type correctly. } Perhaps I am misunderstanding what you mean when you say "by hand". I'm } envisioning an environment where you have a lot of similarly-configured } machines. So you build a kernel (based on GENERIC) to wire down } devices ONE TIME, and distribute that kernel out to all the different } machines. If kernel can do this automatically, no one has to rebuild the kernel any more, and no one has to remember every thing that may reduce sys-admin costs. OK. I'm almost convinced on this point, but I still think that if you're managing 100+ machines, you probably already have an easy mechanism for distributing out kernels to them (think "security patches"). This is special for new users/sys-admins. I personal built 1MB script to setup FreeBSD over the 10 years. It is easy for me to add a couple of lines for wired down the SCSI disk name. But, what is about for the new suers and new sys-admins. Should we make things more easier for them? Making things more easier for new users seems (IMHO) inconsistent with device names that are much longer than they need to be for the common case. } Because it is FreeWare so we cannot do some thing good } as commercial UNIXs do? } } I don't understand this argument. "Free" (i.e. open source) vs. } commercial doesn't have anything to do with this issue. This was some one screamed a couple of years ago. When I pointed out we can do something good like commercial company doing, and one person jumped on top of me and said that Hey, this is FreeWare,but not commercial software, why we should do things like commercial company does? Please don't apply the thinking of one person to an entire community. We've worked together before, and I know you're smarter than that. :-) I'm going to summarize my position, make one final remark, and then get out of the way. 1. I agree that wiring device names down is a good thing. 2. I think that this probably should be the default behavior, but I haven't put enough thought into it to be completely convinced. 3. I disagree with your proposal for longer, more descriptive, device names. I think that it will make the system harder to use for a majority of installations. Ultimately, changing the status quo is going to involve someone (either yourself or someone else) writing up some patches and submitting them for -core's approval. Cheers, Bruce. PGP signature
Re: FTP directory listing with ftpio(3) and fetch(3)
Dag-Erling Smorgrav wrote: Jaakko Salomaa [EMAIL PROTECTED] writes: Hey, how am I supposed to fetch directory listing with ftpio(3) or fecth(3)? ftpio doesn't seem to contain necessary functions for it, and fetch's ones aren't implemented. Type 'man 3 fetch', scroll down to the BUGS section, and see the light. Next, scroll back up to the AUTHORS section and find out who to contact :) When you contact him, don't applaud, just throw money. Or was that fish? -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Huge Binaries..
According to Brett Taylor: That's about 1/2 the size and if you're not using the composer, news reader or mailer you might as well toss Communicator in favor of Navigator. Yes but with the navigator, you can't even mail a link or a page... -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- [EMAIL PROTECTED] FreeBSD keltia.freenix.fr 4.0-CURRENT #74: Thu Sep 9 00:20:51 CEST 1999 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SCSI disk naming problem
[EMAIL PROTECTED] wrote: } That's an interesting argument on the part of a few people. The } commercial UNIX I first adminned had wired down, short names for disks } (rz0, rz1, rz2, ... ). This was very nice. } } This one does not resolve the controller problem either as } [EMAIL PROTECTED] said. } } So, I guess dac0t0, dac0t1, ... dac3t4, will be good enough if we want } to be short, but anything shorter than this will be meaningless. } } Well...I personally prefer the short names. On systems with multiple } controllers, the commercial UNIX I used (Ultrix) just continued its } numbering with rz0, rz1, rz2, ..., rz6, rz7, rz8, ... FreeBSD lets you } do exactly the same thing. The thing is what is rz44 representing? If kernel spits: "rz44 hardware error 105: write failure -- replace it" Which disk are you going to shutdown and replace without looking at /etc/fstab or /sys/i386/conf/CRUEENT_RUN ? What happens if when you see the message and the host is hosed and needs to be rebooted -- at this time both above files are not available -- ? I do not think dac5t4 is that worse than rz44 (just two charaters long). Maybe it is better. You immediately know the disk with ID 4 on the SCSI controller 5 is one having trouble. If you have just one disk, I think two charaters will not be a big deal anyway. However, it will be great help to identify the disk by this two charaters. } Having long device names is confusing to users who only have one disk } controller (and I'd bet this is the vast majority). It took me a long Yes or No. I know at least 7-10 sites running 50 - 100 nodes of FreeBSD. I believe there are much more than I know. How many FreeBSD servers are running in this world? A single node FreeBSD server on this planet can be a lot. A single disk FreeBSD users could be the majority at this monment, do we want more and more FreeBSD servers runnning around the world? So, we should think about the future. } time to grok the syntax of Solaris device names and I still get confused } about this. Commercial or free doesn't have anything to do with this } issue...this scheme would force users to remember and type extra } is good. (I did } miss a message or two in the middle of your discussion, apparently, and } that may have contributed to my apparently confusion.) } } But I think your proposed long names are confusing, and I claim that } that rebuilding a kernel to get wired-down device names is easy. } } Perhaps I am misunderstanding what you mean when you say "by hand". I'm } envisioning an environment where you have a lot of similarly-configured } machines. So you build a kernel (based on GENERIC) to wire down } devices ONE TIME, and distribute that kernel out to all the different } machines. If kernel can do this automatically, no one has to rebuild the kernel any more, and no one has to remember every thing that may reduce sys-admin costs. This is special for new users/sys-admins. I personal built 1MB script to setup FreeBSD over the 10 years. It is easy for me to add a couple of lines for wired down the SCSI disk name. But, what is about for the new suers and new sys-admins. Should we make things more easier for them? } Because it is FreeWare so we cannot do some thing good } as commercial UNIXs do? } } I don't understand this argument. "Free" (i.e. open source) vs. } commercial doesn't have anything to do with this issue. This was some one screamed a couple of years ago. When I pointed out we can do something good like commercial company doing, and one person jumped on top of me and said that Hey, this is FreeWare,but not commercial software, why we should do things like commercial company does? I was scared I had bad approching for FreeWare. Now I think there is nothing wrong if we can use some good idea from any one including commercial sector. So, that is why I would like to tune the name on SCSI disks. -Jin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
I was accepted to LokiHack '99 at Atlanta Linux Showcase
This wouldn't seem -hackers worthy, except I offfered to try to port it to freebsd-current. I thought that this would be interesting to people and that I might be able to get some advice from around here. Following is the email thread that happened between Scott Draeker (president of Loki) and Sam Lantinga (Lead Programmer at Loki). After that is the official offer letter with the library specifications (such as what sound library is used and graphics packages). If anybody has any suggestions it would help me greatly. I have already started looking at the sound library, since that it my weekest area. save:71 Date:Thu, 30 Sep 1999 13:40:44 PDT To: [EMAIL PROTECTED] cc: Scott Draeker [EMAIL PROTECTED], Sam Lantinga [EMAIL PROTECTED] From:Sam Lantinga [EMAIL PROTECTED] Subject: Re: Loki Hack 1999 Registration Return-Path: [EMAIL PROTECTED] Delivery-Date: Thu Sep 30 13:48:11 1999 Return-Path: [EMAIL PROTECTED] Delivered-To: [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] Organization: Loki Entertainment Software X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.12 i686) X-Accept-Language: en MIME-Version: 1.0 References: [EMAIL PROTECTED] X-UIDL: 1309d17516e3077a05fb7010bee48ba9 Nobody wrote: Name: Jason Nordwick E-mail: [EMAIL PROTECTED] Address: 2530 hilleghass #310 berkeley, ca 94704 Telephone: (510) 5486818 Owns CivCTP? No Why I Should Participate: I will port C:CtP to FreeBSD-current. We will not have FreeBSD machines on-site, but thanks for applying! :) -- -Sam Lantinga, Lead Programmer, Loki Entertainment Software save:72 Date:Thu, 30 Sep 1999 14:53:34 PDT To: "Sam Lantinga" [EMAIL PROTECTED], [EMAIL PROTECTED] cc: "Sigyn" [EMAIL PROTECTED] From:Scott Draeker [EMAIL PROTECTED] Subject: Re: Loki Hack 1999 Registration Return-Path: [EMAIL PROTECTED] Delivery-Date: Thu Sep 30 15:10:10 1999 Return-Path: [EMAIL PROTECTED] Delivered-To: [EMAIL PROTECTED] x-sender: [EMAIL PROTECTED] x-mailer: Claris Emailer 2.0v3, January 22, 1998 Mime-Version: 1.0 X-UIDL: b14a543c8550012478ca16d822a5d267 Why I Should Participate: I will port C:CtP to FreeBSD-current. We will not have FreeBSD machines on-site, but thanks for applying! :) Sam. I think this is a legitimate endeavor. We can't set up FreeBSD for this gentleman, but if he's willing to do all the work I say have at it! Scott Draeker President Loki Entertainment Software save:74 Date:Thu, 30 Sep 1999 15:49:46 PDT To: [EMAIL PROTECTED] cc: Scott Draeker [EMAIL PROTECTED], Sam Lantinga [EMAIL PROTECTED] From:Sam Lantinga [EMAIL PROTECTED] Subject: LokiHack '99 Return-Path: [EMAIL PROTECTED] Delivery-Date: Thu Sep 30 15:57:06 1999 Return-Path: [EMAIL PROTECTED] Delivered-To: [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] Organization: Loki Entertainment Software X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.12 i686) X-Accept-Language: en MIME-Version: 1.0 X-UIDL: 4f8c80131644d3c6ab5571a906c054d1 Scott says you're in! You'll need to bring your own FreeBSD and tools, since we will not have network access on the contest LAN. CivCTP uses threads extensively, and displays to X11. The contest development systems will have XPERT 98 video cards. We will have source to all the libraries used in CivCTP available on-site. Good luck! :) -- -Sam Lantinga, Lead Programmer, Loki Entertainment Software (Message save:73) Date:Fri, 01 Oct 1999 13:47:10 PDT From:Kayt Sorhaindo [EMAIL PROTECTED] Subject: Welcome to Loki Hack '99 Return-Path: [EMAIL PROTECTED] Delivery-Date: Fri Oct 1 13:57:05 1999 Return-Path: [EMAIL PROTECTED] Delivered-To: [EMAIL PROTECTED] x-mailer: Claris Emailer 2.0v3, January 22, 1998 Bcc: Mime-Version: 1.0 X-UIDL: 00fe1bd6f5a287838b42aed9cca71142 X-MIME-Autoconverted: from quoted-printable to 8bit by erdos.hq.askjeeves.com i ***d NAA14548 part text/plain6267 [7mPress return to show content...[m Congratulations! We have reviewed your entry form, and would now like to extend an official invitation to you to participate in the first annual Loki Hack to be held October 11-13 in Atlanta, GA. Please: * Let us know by the morning of Tuesday, October 5, if you accept or decline this invitation. You may email me at [EMAIL PROTECTED] * Register by Monday, October 4, at https://www.cmsusa.com/linux/ for the free Exhibits Only pass to the Atlanta Linux Showscase. We will coordinate the upgrade to a complimentary Three Day Technical pass for you to enjoy upon completion of the Hack. * Review the Hack FAQ below, and let us know if you have any additional questions or concerns. We look forward to seeing you in Atlanta! Sincerely, Kayt Sorhaindo Loki Entertainment Software -- WHY IS LOKI SPONSORING THIS EVENT? With Loki Hack, we want to give our customers a chance to see the source code for a commercial game -- modify it,
Re: Huge Binaries..
Julian Elischer wrote: Has anyone looked at netscape Communicator 4.7 for FreeBSD??? I just installed it. the binary is 13234176 bytes long!! yes folks, that's 13 MB! stripped! With shared libraries! It runs but it's quite easy to make your xserver run out of memory (or something (Sig 11)) One has to wonder what on earth they have in there? (My machine has 32 MB so it can run, but it's a bit of a squeez!) I guess you may need a bigger swap space. A while ago yet with Netscape 3.x and 16MB machine I have found that the smallest acceptable swap size was 50MB or it runs out of memory real quick. Now I my machine has 64MB of memory and 150MB of swap but still Netscape 4.07 occasionally runs out of space. I think it has a big memory leak in the forms code (sometimes it consumes tens of kilobytes per each letter typed) and also big problems with Java support. 4.61 seemed to support Java OK (I was able to run a few games in Java!) but crashed every time I tried to send an e-mail, so I returned back to 4.07. -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SCSI disk naming problem
Narvi wrote: See LINT on details of how to wire down scsi devices... Your proposal doesn't take adding a second scsi card into account. UnixWare has a kind od solution for this: when they create the VTOC table (an analog of the BSD disk label) on the disk they have a field in it that contains some piece of random-generated junk that works as a disk ID. The association of the disk number and this ID is also written into resmanager. Resmanager is a thing like sysctl but much more braindamaged and difficult to use, and its contents is saved to disk when the system is stopped. So when the system boots next time it reads in the resmanager database and tries to associate the disks with known ID to the same number which was assigned to them last time. The problem of this method is getting rid of the stale disk ID left in the resmanager, so some way should be provided to do that (and better it be better than in UnixWare). I guess this thing would be rather easy to implement in FreeBSD: instead of the on-disk resmanager database we can use the already existing mechanism of the 3rd stage loader configuration files. And the changes to the SCSI disk driver should be not too complex too. Such a mechanism has also the second (and I suppose the main) use in UnixWare: it is absolutely neccessary for the MultiPath I/O. That is, a disk may be connected to more than one SCSI card and if one of the access paths crashes another one can still be used. There are two problems: first, how do we know that this is the same disk accessible by two paths ? second, if one of the path crashes what are we going to do on the next reboot not to let the disk get re-assigned to another name ? Both of them are resolved by these disk IDs in the VTOCs. -SB On Fri, 1 Oct 1999 [EMAIL PROTECTED] wrote: Current FreeBSD SCSi disk naming mechanism is problem for using more than one disks in the chain during the disk failure. The problem is that the name is not fixed with is SCSI ID. e.g., if one disk is presented in the chain, regardless its SCSI ID, it is always named "da0"; if two disks are installed, the one with lower ID is named da0 and the other will be named as da1. When the lower ID one is crashed, then the other disk will be named as da0 (from da1) after reboot, and it is not mountable due to the name changing. If a system has a UW SCSI controller with 15 disks in the chain, when the first disk (ID = 0) crashed, all rest 14 disks will be useless until either fstab modified or another disk is added with SCSI ID = 0. Why not we use a fixed name corresponding the SCSI ID. That is, disk with ID 0 will be always named as da0, and disk with ID 1 will be always named da1, etc.? Is there problem with fixed disk naming mechanism? -Jin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: return to real mode
Mike Smith wrote: anybody got some reliable, tested, known-good code for getting back to real mode? I'm to the point where I have a working GDT, and paging is turned off, but the last step -- turning off protection enable -- is not working for me. You want to be more explicit about why you want to get back? There are possibly alternatives, or other collateral damage issues that might be worth commenting on. I have an almost-working code written yet in the 2.0.5 days. Then there was a guy Wee Teck [EMAIL PROTECTED] who asked a similar question and I sent my code to him. He has found the final bug and got it working. Maybe he is still on the list and can provide some information. I'm going to send my code and his fix off the list. -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
