Re: diskless problems
while the subject is being revived, there are some changes/additions I made to libstand/bootp.c, it exports all the dhcp tags so that they are available to rc.diskless? or rc.d/initdiskless via kenv check out ftp://ftp.cs.huji.ac.il/users/danny/freebsd/diskless-boot/ these are a bit date, but the uptodated stuff is actively being used here, so if there is some interest i could update it. danny ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discussion on the future of floppies in 5.x and 6.x
Wes Peters wrote: Faster than loading a single ISO image with only the boot information and sysinstall and booting from that, rather than 3 (or 4 or 5) floppies? A CD-R is cheaper, faster, more reliable, and you don't have to keep feeding them into the machine. I think you're missing the point, which I'll come onto, but first, the points you raise. It's not cheaper than a floppy - I have stacks of old floppies here that are re-usable, unlike CD-Rs where I have to shell out for a new one every time. It isn't faster than a floppy, because I'm still doing an FTP install (because I've taken your advice and only downloaded a 3Mb file to save time). If you assume that burning the CD takes no longer than doing a dd (finding the machine would take me longer), it takes the same amount of time. Oh, you mean the extra 30 seconds to read the disk? Yeah, my life would be *much* improved if I could save that. (I'm trying to be ironic... :-) ). It isn't more reliable, as I do a diff on /dev/fd0 and the img file to make sure everything is OK after the dd, and therefore it's just as reliable. In fact, with cheap CD-Rs, I get a coaster-to-usable ratio of about 1:2 which is nowhere near as good as 3.5 floppy. As for Keep feeding them into the machine? It's two disks. Let me write that again. 2. Two. One + one. This constant feeding is hardly likely to give me serious RSI. :-) Perhaps I'm missing something, and I can see why abondoning the current method in 5-6 years would be reasonable, but I don't see the immediate advantage of making the change right now. I also don't think it's the issue that needs to be dealt with - distribution is much, much, MUCH bigger an issue than shall we get rid of floppies? I sent this to the list before, but it got ignored, so I'll send it again, where Jordan points out we have bigger issues to deal with when discussing the floppy disk problem whilst discussing libh:- (http://rtp1.slowblink.com/~libh/sysinstall2/improvements.html): As I mentioned in Section 2.3, one of the more annoying problems with FreeBSD's current distribution format is the dividing line between distributions and packages. There should really only be one type of distribution format and, of course, it should be the package (There Can Be Only One). Achieving this means we're first going to have to grapple with several problems, however: First, eliminating the distribution format means either teaching the package tools how to deal with a split archive format (they currently do not) or divorcing ourselves forever from floppies as a distribution medium. This is an issue which would seem an easy one to decide but invariably becomes Highly Religious(tm) every time it's brought up. In some dark corner of the world, there always seems to be somebody still installing FreeBSD via floppies and even some of the fortune 500 folks can cite FreeBSD success stories where they resurrected some old 386 box (with only a floppy drive and no networking/CD/...) and turned it into the star of the office/saved the company/etc etc. That's not to say we can't still bite that particular bullet, just that it's not a decision which will go down easily with everyone and should be well thought-out. And I have to say, I agree. If abondoning floppies is part of some well-thought-out and well-planned package management strategy, I'm all for it. Otherwise, let sleeping dogs lie? -- Paul Robinson ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discussion on the future of floppies in 5.x and 6.x
On Sunday 11 January 2004 12:27 am, Paul Robinson wrote: Perhaps I'm missing something, and I can see why abondoning the current method in 5-6 years would be reasonable, but I don't see the immediate advantage of making the change right now. So you'll be signing up to do the floppy release engineering, and to modify the kernel so it can load the boot-device modules dynamically. That's great news! And I have to say, I agree. If abondoning floppies is part of some well-thought-out and well-planned package management strategy, I'm all for it. Otherwise, let sleeping dogs lie? The dog isn't sleeping, it's dead. Like everything else in FreeBSD, it takes time. If someone wants to donate that time, it'll continue getting done, otherwise it'll fall by the wayside. -- Where am I, and what am I doing in this handbasket? Wes Peters [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Future of RAIDFrame
Scott Long [EMAIL PROTECTED] writes: Dag-Erling Smørgrav wrote: I'm having trouble seeing what RF does that Vinum (or at least a properly GEOMified Vinum) can't do... Please read the RAIDframe documents at http://www.pdl.cmu.edu/RAIDframe before you ask again. I have, long ago, and frankly it sounds like GEOM with a bunch of RAID classes. We already have GEOM, and the RAID classes are practically trivial to implement once you have GEOM. Considering that RF is unusable in -CURRENT (any attempt to use it causes a panic) and nobody is working on it or has been in a long time, the least you could do is disconnect it from the build. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Large Filesystem Woes
Peter Jeremy [EMAIL PROTECTED] writes: - A statement these options are no longer necessary and will be be removed in a future release in the newfs(8)-equivalent man page should read more like these options are essential (this relates to dimensioning metadata allocation based on the expected total number of files). The default values hit undocumented metadata extent count limits at about 500,000 files. The table showing suggested dimensioning guidelines only goes to 800,000 files. Ugh. That's practically useless. And they actually charge money for this product? DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discussion on the future of floppies in 5.x and 6.x
Wes Peters wrote: So you'll be signing up to do the floppy release engineering, and to modify the kernel so it can load the boot-device modules dynamically. That's great news! If the kernel changes don't support the established distribution format, the kernel changes are broken, not the distribution format. If the kernel changes must happen at some point and the distribution format must therefore become the package, then that's fine, but that change (including being able to split packages over several physical distribution units) has to happen first, surely? I'm happy to get involved in any team looking at that as it falls under something I've been looking at for the last year or so in my spare time - package management and installers. The dog isn't sleeping, it's dead. Like everything else in FreeBSD, it takes time. If someone wants to donate that time, it'll continue getting done, otherwise it'll fall by the wayside. Understood. I just think saying let's get rid of floppies is shooting a dog that happens to be near to hand because you don't like that dog, to stretch the analogy. Personally, I think getting the package management issues sorted so that distribution becomes independent of physical medium (so floppies, CDs, etc. can be used or abondoned at will, along with future formats) is an admirable goal, but one that should be on the 6- roadmap. In other words, getting rid of floppies is not the discussion we should be having, if that makes sense? -- Paul Robinson ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discussion on the future of floppies in 5.x and 6.x
Paul Robinson [EMAIL PROTECTED] writes: Understood. I just think saying let's get rid of floppies is shooting a dog that happens to be near to hand because you don't like that dog, to stretch the analogy. I don't think you have any idea how difficult it is (and has been for a couple of years now) just to keep the install floppies alive. The kernel keeps growing, and the amount of must-have features (such as acpi) keeps growing, and every time the boot floppies overflow we have to toss out yet another driver that about a dozen people vehemently tell us they can't live without. To rephrase this in terms of your analogy, the dog was hit by a bus two years ago and has been on artificial life support ever since, and it's starting to dawn on us that we can no longer afford the hospital bill. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discussion on the future of floppies in 5.x and 6.x
* Dag-Erling Smørgrav [EMAIL PROTECTED] [2004-01-11 10:19 +0100]: Paul Robinson [EMAIL PROTECTED] writes: Understood. I just think saying let's get rid of floppies is shooting a dog that happens to be near to hand because you don't like that dog, to stretch the analogy. I don't think you have any idea how difficult it is (and has been for a couple of years now) just to keep the install floppies alive. The kernel keeps growing, and the amount of must-have features (such as acpi) keeps growing, and every time the boot floppies overflow we have to toss out yet another driver that about a dozen people vehemently tell us they can't live without. Why not split the kernel onto 2 disks? The code to do this is already there and seems to work. And the people who think they absolutly need disks would have to deal with 4 disks, but that would be better than no disks. Look at the commit history of /usr/src/lib/libstand/splitfs.c. Is there a reason not to use it? Nicolas ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SCM options (was Re: Where is FreeBSD going?)
On Sun, 2004-01-11 at 00:05, Peter Jeremy wrote: On Sat, Jan 10, 2004 at 05:01:13PM -0500, Garance A Drosihn wrote: At 9:35 PM + 1/10/04, Andrew Boothman wrote: Peter Schuller wrote: Most of the noteworthy features of subversion are listed on the project front page: http://subversion.tigris.org/ A significant one of which is the fact that it's available under a BSD-style license. Meaning that the project wouldn't have to rely on more GPLed code. I wonder if our SCM would be brought into the base system or whether it would just be left in ports? We haven't even started to *test* subversion yet, so I think it's a bit early to worry about this question! I disagree. Andrew raised two issues (type of license and port vs base location). The type of license is an input to the decision as to which SCM to choose - BSD would be preferable but GPL is probably acceptable (given two potential SCMs with similar features, the BSD licensed one would be selected in preference to the GPL one). Subversion has a friendly BSD-ish license but it depends heavily on Sleepycat DB which doesn't. I imagine that if we do end up using it one day, it would be best managed as a port rather than part of the base system. I just don't see many people agreeing on importing subversion+db-4.2+apache2 into src/contrib... ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
FreeBSD 5.1 Installation probelms
hey guys, Just got my copy of FreeBSD 5.1. Spent about an hour going through the BSD Handbook and preparing a Installation checklist. ok here's my problem. I have a WD 40 GB HDD the primary partition is 10 GB, with the extended partition 28 GB.(the rest 2 GB is in WD's bank). OK , the extended partition has 3 logical drives. To create a slice for BSD, I resized one of the logical drives to free up some space. About 1.2 GB,cause that's all I can spare. When I run the installation through CDROM, and the point where I'm to creat the Freebsd slice,the new partition is not displayed in the FDISK utility. All I get is the primary (10GB) and the whole Extended (28 GB). The freespace I guess is locked into the Extended Partiton. Not sure though. Any workaround for this, or should I start with a new HDD. cheers, TH = Love is control,I'll die if I let go I will only let you breathe My air that you receive Then we'll see if I let you love me. -James Hetfield All Within My Hands,St.Anger Metallica __ Do you Yahoo!? Yahoo! Hotjobs: Enter the Signing Bonus Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Future of RAIDFrame and Vinum (was: Future of RAIDFrame)
In message [EMAIL PROTECTED], Alexander Leidinge r writes: I'm a little bit confused. I've read Pouls mail as an suggestion to remove vinum from -current and let people modify it in the perforce repository. If I got this wrong, please tell me and everything is fine, but if I got it right, do you (Greg) agree to remove it from -current? My proposal is to do just that with both vinum and raidframe until one or possibly both are up to full strength again. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Future of RAIDFrame and Vinum (was: Future of RAIDFrame)
On Sunday, 11 January 2004 at 12:08:24 +0100, Alexander Leidinger wrote: On Sun, 11 Jan 2004 15:46:49 +1030 Greg 'groggy' Lehey [EMAIL PROTECTED] wrote: [missing attribution to phk] I'd say lets kick them both into perforce and let whoever wants their hands have a go at them. For some definition of perforce, I'm all for it. Note that there's also an OS-independent mailing list (see http://www.auug.org.au/mailman/listinfo/vinum-devel for joining instructions). I'm a little bit confused. I've read Pouls mail as an suggestion to remove vinum from -current and let people modify it in the perforce repository. If I got this wrong, please tell me and everything is fine, but if I got it right, do you (Greg) agree to remove it from -current? No. As others have said, if phk and I agree, the world will come to an end. I'm saying: 1. Yes, let people hack at it and improve on it outside the source tree. 2. If it works, don't fix it. At the moment, Vinum works, for some definition of works. These two aren't incompatible. Removing existing functionality for the sake of purity, on the other hand, is unnecessary. Sadly, much as I love the discussion, I have this conference next week, starting in less than 12 hours, and I need to sleep first. Unless the shit hits the fan, don't expect to hear from me for a week. Greg -- See complete headers for address and phone numbers. pgp0.pgp Description: PGP signature
Re: Future of RAIDFrame
Scott Long wrote: I started RAIDframe three years ago with the hope of bringing a proven and extensible RAID stack to FreeBSD. Unfortunately, while it was made to work pretty well on 4.x, it has never been viable on 5.x; it never survived the introduction of GEOM and removal of the old disk layer. I'm coming to the conclusion that I really don't have the time to work on it in my spare time. Also, I've seen next to zero interest in it from others, except for the occasional reminder that it doesn't work. William Carrel used to maintain a set of patches for RAIDframe on 4.x, were they ever committed? No? Why not? WRT lack of interest in RF. First, the 5.0 patches were horrible. That code was a mess to work with. Second, inertia. Most people with simple needs like mirroring and/or simple stripes were happy with good old ccd(4). Those who needed a full volume manager (which neither ccd nor RF claim to be) used vinum. People with VxVM experience feel at home with it. Unfortunately, vinum has its own set of issues as well. It's probably easier to write a set of GEOM classes from scratch than trying to shoehorn RF into GEOM. Cheers, Miguel Mendez http://www.energyhq.es.eu.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Remote GDB online and kernel functions
Hi there. I sent the following question to the list a while ago, and got no answer yet. The problem looks weird to me, but I have the feeling that I'm missing something very simple (I did RTFM, though) - so if anyone can provide any guidance - cannot be that complicated of a question... I didn't look much into the sources of the kernel GDB (db_interface.c, etc. etc.), but from what I saw I wasn't sure what's going on. I'm asking again because it would really ease one of the things I have on my to do queue (which I haven't touched recently because of that problem): I'm fooling around a bit with kernel hacking recently, and got a bit to work with online kernel debugging with GDB (over a serial port). I built the kernel (FreeBSD-4.9) with DDB and -g compile option, and set the flag on sio0, as described in section 10.6 of the FreeBSD Developer's Handbook at: http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-online-gdb.html Using gdb -k I can open the kernel image, and doing 'target remote /dev/cuaa0' I can attach to the debugged host (having switched to gdb mode from DDB on it, and entered 's' to generate a trap). Trying to figure out some stuff I can do with it, I noticed that for some reason I cannot call any kernel functions from kgdb... When entering, e.g. the command: (kgdb) call print_uptime() gdb points it caught of a SIGSEGV, which actually is a panic on the host - I see a fatal trap 12 (page fault while in kernel mode), with fault code 'supervisor read, page not present'... Am I in some special context when inside the kernel debugger, from which other kernel functions cannot be called? (no access to their page?) What needs to be done to setup the paging and memory protection to be able to do so? The even more weird thing yet is that from the information in the panic, during the panic the instruction pointer, frame pointer (but not the stack pointer), and panic virtual address are zero: fault virtual address = 0x0 instruction pointer = 0x8:0x0 frame pointer = 0x10:0x0 I thought maybe there is some zero at the time of return from the function when ret is executed (so the CPU tries to jump to address 0), but having put some breakpoints inside the function, I see that the panic is even before the first instruction of it executes... I found very little documentation on kernel debugging, except on how to get into DDB and use it a bit, how to debug offline with gdb with crash dumps, and how to start a remote online GDB session through the serial port on a running kernel... In the Developer's Handbook there are examples on usage of DDB online, and GDB offline on a crash dump, but no examples of online remote GDB usage. I am not sure how exactly the contexts of the kernel should affect debugging which (as far as I understand) is done completely within the kernel, and how the kernel debugger/GDB interferes... I'll try to learn more and perhaps understand it... But can someone provide some ideas as to what is the cause of the problem, what is exactly happening and why, and how to overcome it? Thanks, any help appreciated, -- Tom -- Tom Alsberg - hacker (being the best description fitting this space) Web page: http://www.cs.huji.ac.il/~alsbergt/ DISCLAIMER: The above message does not even necessarily represent what my fingers have typed on the keyboard, save anything further. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 5.1 Installation probelms
On Sunday 11 January 2004 11:29, 70uf33q Hu5541n wrote: hey guys, Just got my copy of FreeBSD 5.1. Spent about an hour going through the BSD Handbook and preparing a Installation checklist. ok here's my problem. I have a WD 40 GB HDD the primary partition is 10 GB, with the extended partition 28 GB.(the rest 2 GB is in WD's bank). OK , the extended partition has 3 logical drives. To create a slice for BSD, I resized one of the logical drives to free up some space. About 1.2 GB,cause that's all I can spare. When I run the installation through CDROM, and the point where I'm to creat the Freebsd slice,the new partition is not displayed in the FDISK utility. All I get is the primary (10GB) and the whole Extended (28 GB). The freespace I guess is locked into the Extended Partiton. Not sure though. Indeed you first have to resize the extended partition before you can use the space to create slices. The fdisk program that comes with Windows has no way to do this (except deleting all logicle drives in the extended partition and re-creating them). Have a look at the program Partition Magic. It can resize partitions and it has a nice user interface. grtz, Daan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SCM options (was Re: Where is FreeBSD going?)
--- Garance A Drosihn [EMAIL PROTECTED] wrote: At 7:27 PM -0800 1/9/04, Pedro F. Giffuni wrote: Hi; There is a comparison here: http://better-scm.berlios.de/comparison/comparison.html I think there are compelling reasons to try subversion, but we have to wait for a 1.0 Release, and this would be something that should be done gradually.. for example moving the ports tree first. That's a pretty major test! Could we perhaps pick off something smaller? The projects repository, for instance? (or is that still tied to the base-system?) (I am very interested in subversion, but it is still something I need to learn more about...) I think we must wait until a 1.0 version is available. SVN is meant to be a replacement to CVS. The projects repository is using perforce which happens to be a good tool, so moving it to svn is probably not a step forward IMHO ;-). cheers, Pedro. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Hotjobs: Enter the Signing Bonus Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Future of RAIDFrame
In message [EMAIL PROTECTED], Scott Long writes: All, I started RAIDframe three years ago with the hope of bringing a proven and extensible RAID stack to FreeBSD. Unfortunately, while it was made to work pretty well on 4.x, it has never been viable on 5.x; it never survived the introduction of GEOM and removal of the old disk layer. [...] I have a Work-In-Progress for converting and integrating it into GEOM on my home Perforce server. It hasn't been touched in several months and I really don't see myself being able to finish alone it in the near future. Since it's been hanging over my head for so long, I'm very, very close to just removing it and moving on. I can't help thinking about how small the central group of developers in FreeBSD is, and considering that you also carry the armoured release-engineer hat, I am fully able to understand why you have not been able to pull RF along in addition to all the other stuff. As much as I would hate to see RF and Vinum disappar from our source tree, maybe what we need to do is to kick them both into training-camp in p4 while you and Greg look the other way. In the p4 tree, we can easier add new talent to our developer force and I am pretty sure that some sort of merry band of developers would form around both RF and vinum there. I am not convinced that they may be able to pull off the task, but the fact that somebody at least tries should give us better chances than having RF stuck in your TODO queue, and vinum stuck in Gregs, while everybody else waits more or less paitiently. If they manage to make it work in p4, pulling it back into CVS is a small matter of repo work (AFAIK). Because we might as well be honest and face it: Neither you nor Greg has much chance of finding the significant amount of time that you need. I know this can be seen as you and Greg throwing in the towel, but I urge you to try to see it like saw my Junior Kernel Hacker list: Throwing a good meaty bone to pick which I myself couldn't eat anyway. I'd say lets kick them both into perforce and let whoever wants their hands have a go at them. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Future of RAIDFrame
At 12:28 AM +0100 2004/01/11, Dag-Erling Smørgrav wrote: I'm having trouble seeing what RF does that Vinum (or at least a properly GEOMified Vinum) can't do... I think Scott is right, in that we should probably have separate RAID vs. LVM systems. It seems to me that vinum naturally fills the LVM role, while RAIDframe handles the RAID side well. -- Brad Knowles, [EMAIL PROTECTED] They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++): a C++(+++)$ UMBSHI$ P+++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++ h--- r---(+++)* z(+++) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Future of RAIDFrame
On Sun, 11 Jan 2004 00:12:57 +0100 Poul-Henning Kamp [EMAIL PROTECTED] wrote: As much as I would hate to see RF and Vinum disappar from our source tree, maybe what we need to do is to kick them both into training-camp in p4 while you and Greg look the other way. [...] I'd say lets kick them both into perforce and let whoever wants their hands have a go at them. RF isn't working today on -current, vinum is (please don't tell me something else, I don't want the system under my desk stop running on a vinum volume just because you say it has to :-)). Do you really want to throw your axe at vinum while it's still alive? Bye, Alexander. -- I will be available to get hired in April 2004. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Future of RAIDFrame
At 3:30 PM -0700 2004/01/10, Scott Long wrote: It will probably never be an LVM stack, but I've also always believed that LVM and RAID are related but separate layers. Having looked at the RAIDframe documentation you referenced, it strikes me that it cannot really move towards LVM and still be RAIDframe. It is a framework for doing rapid prototyping of RAID systems (and presumably their operation), and is available on a wide variety of platforms. To do anything else would be to change the fundamental nature of the beast. It can certainly build upon whatever LVM layer appears in GEOM. My experience has been that a good RAID/LVM system also needs a lot of support from the filesystem, and skimming through the RAIDframe documentation, it seems that I am not alone in this opinion. What work has been done (or identified) to make the filesystem more suitable for use with RAID/LVM systems? At the most basic, do we have things like growfs and shrinkfs? -- Brad Knowles, [EMAIL PROTECTED] They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++): a C++(+++)$ UMBSHI$ P+++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++ h--- r---(+++)* z(+++) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Future of RAIDFrame and Vinum (was: Future of RAIDFrame)
In message [EMAIL PROTECTED], Greg 'groggy' Lehey writes: As much as I would hate to see RF and Vinum disappar from our source tree, maybe what we need to do is to kick them both into training-camp in p4 while you and Greg look the other way. Hmm. I can't see why they have to disappear from the source tree, and I don't see why Scott or I should have to look the other way. The reason I say this is that neither of you have the time needed, and whoever picks up may have ideas, even necesarry ideas, which would grind your spine seriously. By letting go, I think you would give vinum a better chance. In the p4 tree, we can easier add new talent to our developer force and I am pretty sure that some sort of merry band of developers would form around both RF and vinum there. OK, I'm not a fan of p4, but I suspect that's not the issue. This sounds like a way of suggesting Let's do VinumNG and RFNG and get a whole lot of people involved. I couldn't agree more. Well, I soft of think the entire NG thing is so dotcomish, so I particularly tried to avoid it :-) But otherwise: yes, exactly. I just want you and Scott to realize that if you don't have the time to run with whatever crowd forms, your participation might be a hindrance more than a help. For it to work, you need to truly let go of control. I've been trying to encourage people to look at Vinum for some time. It's a relatively complicated piece of code, and something about it seems to scare people away. The proximity of a [EMAIL PROTECTED] person can be quite a damper on enthusiasm by way of intimidation: Gee, I'm nowhere near as good as him, I'd better not even try, and getting a lukewarm Yeah, well, maybe from such a person is a very cold shower for a young rising star. We are an intimidating bunch of old farts, and that's all well and fine, but we need to remember to pull in young farts and let them grow older, at least if we want the project to stay long term. Every so often I have to remind myself that when I was at their age, I was allowed to mess around with some complicated and important stuff so I shouldn't be in the way of them getting the same experience. but I urge you to try to see it like saw my Junior Kernel Hacker list: Throwing a good meaty bone to pick which I myself couldn't eat anyway. Yes, that's the way I've seen it for some time. Any ideas how to excite people? Do you want to say something? Something like If phk and grog agree, it must be right? :-) A lot of people out there will start looking out for black helicopters if they see the two of us agree, so I would like to state for the record that while you words _seem_ to say the same as my words, you have got it all _TOTALLY_ wrong! :-) Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Future of RAIDFrame and Vinum (was: Future of RAIDFrame)
On Sun, 11 Jan 2004 15:46:49 +1030 Greg 'groggy' Lehey [EMAIL PROTECTED] wrote: Hmm. I can't see why they have to disappear from the source tree, and I don't see why Scott or I should have to look the other way. I don't know about RAIDFrame, but Vinum still works for the most part: [...] In the p4 tree, we can easier add new talent to our developer force and I am pretty sure that some sort of merry band of developers would form around both RF and vinum there. OK, I'm not a fan of p4, but I suspect that's not the issue. This sounds like a way of suggesting Let's do VinumNG and RFNG and get a whole lot of people involved. I couldn't agree more. [...] I'd say lets kick them both into perforce and let whoever wants their hands have a go at them. For some definition of perforce, I'm all for it. Note that there's also an OS-independent mailing list (see http://www.auug.org.au/mailman/listinfo/vinum-devel for joining instructions). I'm a little bit confused. I've read Pouls mail as an suggestion to remove vinum from -current and let people modify it in the perforce repository. If I got this wrong, please tell me and everything is fine, but if I got it right, do you (Greg) agree to remove it from -current? Bye, Alexander. -- I will be available to get hired in April 2004. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Assembler coding help needed.
I'm trying to find out why I can't boot 5.2 from USB CDROM on Supermicro motherboards. (I have an old Gateway P3 that can!). I've found out that that only 0x20 of 0x4c sectors of the loader are read in and it therfor traps when executed. (read is only called once). My last attempt at programming x86 assembler was ~15years ago so I'm a bit rusty :-) The below loop from cdboot.s is what I'm having problem understanding, how can this fail on one box but not on another? # # Load the binary into the buffer. Due to real mode addressing limitations # we have to read it in in 64k chunks. # mov DIR_SIZE(%bx),%eax # Read file length add $SECTOR_SIZE-1,%eax # Convert length to sectors shr $11,%eax %eax is 0x4c here on both machines! cmp $BUFFER_LEN,%eax jbe load_sizeok mov $msg_load2big,%si # Error message call error load_sizeok:movzbw %al,%cx # Num sectors to read mov DIR_EXTENT(%bx),%eax# Load extent xor %edx,%edx mov DIR_EA_LEN(%bx),%dl add %edx,%eax # Skip extended mov $MEM_READ_BUFFER,%ebx # Read into the buffer load_loop: mov %cl,%dh cmp $MAX_READ_SEC,%cl # Truncate to max read size jbe load_notrunc mov $MAX_READ_SEC,%dh load_notrunc: sub %dh,%cl # Update count push %eax # Save call read # Read it in pop %eax# Restore add $MAX_READ_SEC,%eax # Update LBA add $MAX_READ,%ebx # Update dest addr jcxz load_done # Done? jmp load_loop # Keep going load_done: ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: freebsd-hackers Digest, Vol 42, Issue 6
On Fri, Jan 09, 2004 at 03:57:07PM +, YACINE GHANJAOUI wrote: when trying to intercept UDP packet after changing the protocol number from 17 to a user one (99) in the ip_input.c file. when trying to regenrate the packet after inserting some bit errors an error message appears in the reciever telling that The udp checksum is incorrect even if i just change the ip Header. What do you think the problem is? You didn't read how UDP checksums were calculated, did you? Here is one free clue: Look at the definition of in_pseudo() and where it is used. Use the source. look! BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
MD(4) cleanups and unload lesson.
Hello hackers...
With attached patch unloading md(4) module is possible.
It also cleans up big part of code according to style(9).
Patch is also avaliable at:
http://garage.freebsd.pl/patches/md.c.patch
--
Pawel Jakub Dawidek [EMAIL PROTECTED]
UNIX Systems Programmer/Administrator http://garage.freebsd.pl
Am I Evil? Yes, I Am! http://cerber.sourceforge.net
With this patch it is possible to unload md.ko module and it contains
a lot of cleanups (style(9)) and simplifies.
--- md.c.orig Sun Dec 28 11:12:22 2003
+++ md.cSun Jan 11 16:41:23 2004
@@ -98,7 +98,7 @@
static MALLOC_DEFINE(M_MD, MD disk, Memory Disk);
static MALLOC_DEFINE(M_MDSECT, MD sectors, Memory Disk Sectors);
-static int md_debug;
+static int md_debug = 0;
SYSCTL_INT(_debug, OID_AUTO, mddebug, CTLFLAG_RW, md_debug, 0, );
#if defined(MD_ROOT) defined(MD_ROOT_SIZE)
@@ -107,13 +107,16 @@
static u_char end_mfs_root[] __unused = MFS Filesystem had better STOP here;
#endif
-static g_init_t md_drvinit;
static int mdrootready;
static int mdunits;
static dev_t status_dev = 0;
+
static d_ioctl_t mdctlioctl;
+static g_init_t md_drvinit;
+static g_fini_t md_drvfini;
+static g_ctl_destroy_geom_t md_destroy_geom;
static struct cdevsw mdctl_cdevsw = {
.d_ioctl = mdctlioctl,
@@ -121,6 +124,14 @@
};
+struct g_class g_md_class = {
+ .name = MD,
+ .init = md_drvinit,
+ .fini = md_drvfini,
+ .destroy_geom = md_destroy_geom,
+};
+
+
static LIST_HEAD(, md_s) md_softc_list = LIST_HEAD_INITIALIZER(md_softc_list);
#define NINDIR (PAGE_SIZE / sizeof(uintptr_t))
@@ -168,7 +179,14 @@
vm_object_t object;
};
-static int mddestroy(struct md_s *sc, struct thread *td);
+struct md_tmp {
+ int unit;
+ int error;
+};
+
+
+static void mddestroy(struct md_s *sc);
+
static struct indir *
new_indir(u_int shift)
@@ -178,8 +196,8 @@
ip = malloc(sizeof *ip, M_MD, M_NOWAIT | M_ZERO);
if (ip == NULL)
return (NULL);
- ip-array = malloc(sizeof(uintptr_t) * NINDIR,
- M_MDSECT, M_NOWAIT | M_ZERO);
+ ip-array = malloc(sizeof(uintptr_t) * NINDIR, M_MDSECT,
+ M_NOWAIT | M_ZERO);
if (ip-array == NULL) {
free(ip, M_MD);
return (NULL);
@@ -240,8 +258,8 @@
* too much space for ip-array in here.
*/
ip = malloc(sizeof *ip, M_MD, M_WAITOK | M_ZERO);
- ip-array = malloc(sizeof(uintptr_t) * NINDIR,
- M_MDSECT, M_WAITOK | M_ZERO);
+ ip-array = malloc(sizeof(uintptr_t) * NINDIR, M_MDSECT,
+ M_WAITOK | M_ZERO);
ip-total = NINDIR;
ip-shift = layer * nshift;
return (ip);
@@ -292,7 +310,7 @@
cip = ip;
for (;;) {
lip[li++] = cip;
- if (cip-shift) {
+ if (cip-shift 0) {
idx = (offset cip-shift) NMASK;
up = cip-array[idx];
if (up != 0) {
@@ -335,12 +353,6 @@
return (0);
}
-
-struct g_class g_md_class = {
- .name = MD,
- .init = md_drvinit,
-};
-
static int
g_md_access(struct g_provider *pp, int r, int w, int e)
{
@@ -352,11 +364,10 @@
r += pp-acr;
w += pp-acw;
e += pp-ace;
- if ((pp-acr + pp-acw + pp-ace) == 0 (r + w + e) 0) {
+ if ((pp-acr + pp-acw + pp-ace) == 0 (r + w + e) 0)
sc-opencount = 1;
- } else if ((pp-acr + pp-acw + pp-ace) 0 (r + w + e) == 0) {
+ else if ((pp-acr + pp-acw + pp-ace) 0 (r + w + e) == 0)
sc-opencount = 0;
- }
return (0);
}
@@ -376,9 +387,6 @@
wakeup(sc);
}
-DECLARE_GEOM_CLASS(g_md_class, g_md);
-
-
static int
mdstart_malloc(struct md_s *sc, struct bio *bp)
{
@@ -391,7 +399,7 @@
secno = bp-bio_pblkno;
dst = bp-bio_data;
error = 0;
- while (nsec--) {
+ while (nsec-- 0) {
osp = s_read(sc-indir, secno);
if (bp-bio_cmd == BIO_DELETE) {
if (osp != 0)
@@ -406,7 +414,7 @@
bcopy((void *)osp, dst, sc-secsize);
osp = 0;
} else if (bp-bio_cmd == BIO_WRITE) {
- if (sc-flags MD_COMPRESS) {
+ if ((sc-flags MD_COMPRESS) != 0) {
uc = dst[0];
for (i = 1; i sc-secsize; i++)
if (dst[i] != uc)
@@ -420,8 +428,8 @@
error = s_write(sc-indir, secno, uc);
} else {
if (osp = 255) {
- sp = (uintptr_t) uma_zalloc(
- sc-uma, M_NOWAIT);
+ sp =
Re: Discussion on the future of floppies in 5.x and 6.x
I also don't think it's the issue that needs to be dealt with - distribution is much, much, MUCH bigger an issue than shall we get rid of floppies? I sent this to the list before, but it got ignored, so I'll send it again, where Jordan points out we have bigger issues to deal with when discussing the floppy disk problem whilst discussing libh:- (http://rtp1.slowblink.com/~libh/sysinstall2/improvements.html): As I mentioned in Section 2.3, one of the more annoying problems with FreeBSD's current distribution format is the dividing line between distributions and packages. There should really only be one type of distribution format and, of course, it should be the package (There Can Be Only One). Achieving this means we're first going to have to grapple with several problems, however: First, eliminating the distribution format means either teaching the package tools how to deal with a split archive format (they currently do not) or divorcing ourselves forever from floppies as a distribution medium. This is an issue which would seem an easy one to decide but invariably becomes Highly Religious(tm) every time it's brought up. In some dark corner of the world, there always seems to be somebody still installing FreeBSD via floppies and even some of the fortune 500 folks can cite FreeBSD success stories where they resurrected some old 386 box (with only a floppy drive and no networking/CD/...) and turned it into the star of the office/saved the company/etc etc. That's not to say we can't still bite that particular bullet, just that it's not a decision which will go down easily with everyone and should be well thought-out. And I have to say, I agree. If abondoning floppies is part of some well-thought-out and well-planned package management strategy, I'm all for it. Otherwise, let sleeping dogs lie? It isn't as far as I can understand from that link. JKH is talking about doing floppy only install (some old 386 box (with only a floppy drive and no networking/CD/...) and turned it into the star of the office/saved the company/etc etc...) not loading an installation kernel and /stand from floppy and then transfer to network/cd later. This because when then base/packages need to fit on floppy. This isn't necessary for the current two-flop, then CD install which is discussed now. P.s. for the record, I prefer Slackware's approach to floppy booting. Multiple cut down bootsets (SCSI, NET etc) with the ability to simply extract extra kernel modules from CD to a floppy (on a separate machine) and load them from floppy while still in the initial system ramdisk (before mounting CD). The loading/mounting etc must be done by hand, no extra new functionality required. Maybe the basic idea should be to forget the equivalence of floppy and cd boot, and deliver a set of kernel modules on CD, and a few basic boot/root floppies, and for the rest let users create their own custom driver discs, and do some extra work to keep their floppy boot running. That ends the one boot/root for all idea, but is maybe more flexible, ( didn't have to make something with custom kernel to install my Proliant 1500, but only select the right kernel disc and copy some extra kernel moduless to an empty flop) and at the same time decrease release engineering on the floppies. I think this is a good compromise: Keep floppy option open, but shift some burden to the users. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: diskless problems
On Sun, 11 Jan 2004, Danny Braniss wrote: while the subject is being revived, there are some changes/additions I made to libstand/bootp.c, it exports all the dhcp tags so that they are available to rc.diskless? or rc.d/initdiskless via kenv check out ftp://ftp.cs.huji.ac.il/users/danny/freebsd/diskless-boot/ these are a bit date, but the uptodated stuff is actively being used here, so if there is some interest i could update it. Sounds very interesting indeed. Could you: (1) Update it to bootp.c:1.5; this just removed 'register', and it looks like you've already done that. (2) Restore the original file style -- right now, it's a very hard to read diff because you use different tabbing, function prototypes, etc, so it's hard to isolate and read the changes. There's probably some room for style convergence (new function prototypes), but we have a long-standing tradition of committing style and functional chaanges separately so cvs diff is maximally useful between revisions. It looks like the main difference is that you use four space tabs, and the original file uses real tab characters. Then if you could file a PR and drop me the PR number by e-mail, that would be great. I can do the style stuff if necessary, but I figured since you're much more familiar with the changes, it might not be a bad idea if you did it :-). Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Senior Research Scientist, McAfee Research ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discussion on the future of floppies in 5.x and 6.x
On 8 Jan 2004, at 14:39, Leo Bicknell wrote: Then, to replace the current floppy process, a new floppy installer is created. It may or may not be based on FreeBSD, but what it needs to be able to do is boot, load a network driver, configure the network, and ftp the above mentioned iso into ram, and then jump into the kernel from the iso as if it had been loaded from a CD. Or mount the ISO image from a FAT, NTFS, UFS, or EXT2FS filesystem on a disk that's already in the machine... N PGP.sig Description: This is a digitally signed message part
binary files in src tree
While browsing the FreeBSD src tree, I came across a number of binary files (listed below); the regression tests are perhaps understandable, but shouldn't the rest of these files be uuencoded? contrib/groff/doc/gnu.png contrib/ipfilter/samples/ipfilter-pb.gif contrib/sendmail/libmilter/docs/figure1.jpg contrib/sendmail/libmilter/docs/figure2.jpg crypto/openssh/regress/copy.1 crypto/openssh/regress/copy.2 crypto/openssh/scard/Ssh.bin crypto/openssl/crypto/pkcs7/p7/a1 crypto/openssl/crypto/pkcs7/p7/a2 crypto/openssl/crypto/pkcs7/p7/cert.p7c crypto/openssl/crypto/pkcs7/p7/smime.p7m crypto/openssl/crypto/pkcs7/p7/smime.p7s crypto/openssl/doc/openssl_button.gif release/picobsd/tinyware/view/fbsd.png tools/regression/usr.bin/file2c/regress.in tools/regression/usr.bin/uudecode/regress.out tools/regression/usr.bin/uuencode/regress.in tools/tools/tinderbox/www/daemon.png tools/tools/tinderbox/www/valid-css.png tools/tools/tinderbox/www/valid-xhtml10.png Colin Percival ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: MD(4) cleanups and unload lesson.
On Sun, 11 Jan 2004, Pawel Jakub Dawidek wrote: With attached patch unloading md(4) module is possible. It also cleans up big part of code according to style(9). Could you separate this into a functional diff and a style diff? There's a general preference to not combine them, as it means cvs diff between revisions isn't useful for identifying functional changes (i.e., reviewing for bugs when back-tracking, etc). Thanks, Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Senior Research Scientist, McAfee Research ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Future of RAIDFrame
Scott == Scott Long [EMAIL PROTECTED] writes: Scott Dag-Erling Smørgrav wrote: Scott Long [EMAIL PROTECTED] writes: I started RAIDframe three years ago with the hope of bringing a proven and extensible RAID stack to FreeBSD. I'm having trouble seeing what RF does that Vinum (or at least a properly GEOMified Vinum) can't do... DES Scott Please read the RAIDframe documents at Scott http://www.pdl.cmu.edu/RAIDframe before you ask again. Having used Vinum is production and on home boxes for some time, and having come in contact with Raidframe on NetBSD several times, I would distill this to several points. - Vinum is fairly fragile and a number of operations have vastly non-obvious steps. - Vinum's support for different types of RAID is limited. - Vinum's abstractions don't work for more complex cases. That said, we need a strong and robust software raid. Dave. -- |David Gilbert, Independent Contractor. | Two things can only be | |Mail: [EMAIL PROTECTED]| equal if and only if they | |http://daveg.ca | are precisely opposite. | =GLO ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Future of RAIDFrame
In message [EMAIL PROTECTED], David Gilbert writes: That said, we need a strong and robust software raid. And as long as we have something which mostly work there seems to be insufficient motivation to make that happen. Therefore my proposal to send both RF and Vinum in training camp in p4. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discussion on the future of floppies in 5.x and 6.x
On Sun, Jan 11, 2004 at 10:27:46AM +0100, Nicolas Rachinsky wrote: * Dag-Erling Smørgrav [EMAIL PROTECTED] [2004-01-11 10:19 +0100]: Paul Robinson [EMAIL PROTECTED] writes: Understood. I just think saying let's get rid of floppies is shooting a dog that happens to be near to hand because you don't like that dog, to stretch the analogy. I don't think you have any idea how difficult it is (and has been for a couple of years now) just to keep the install floppies alive. The kernel keeps growing, and the amount of must-have features (such as acpi) keeps growing, and every time the boot floppies overflow we have to toss out yet another driver that about a dozen people vehemently tell us they can't live without. Why not split the kernel onto 2 disks? The code to do this is already there and seems to work. And the people who think they absolutly need disks would have to deal with 4 disks, but that would be better than no disks. Look at the commit history of /usr/src/lib/libstand/splitfs.c. Is there a reason not to use it? If you could make this work such that you just stuffed GENERIC and the mfsroot onto however many floppies it takes, I think that would almost certaintly solve re's problems with floppies (i.e. if all they had to do when the kernel/mfsroot got too big was to bump a NUMFLOPPIES variable.) Sure that would suck for the floppy users, but that would put the pain in the place where it's most likely to cause someone to come up with some better. Now, who wants to give this a try? -- Brooks -- Any statement of the form X is the one, true Y is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 pgp0.pgp Description: PGP signature
Re: Discussion on the future of floppies in 5.x and 6.x
Marco van de Voort wrote: I also don't think it's the issue that needs to be dealt with - distribution is much, much, MUCH bigger an issue than shall we get rid of floppies? I sent this to the list before, but it got ignored, so I'll send it again, where Jordan points out we have bigger issues to deal with when discussing the floppy disk problem whilst discussing libh:- (http://rtp1.slowblink.com/~libh/sysinstall2/improvements.html): As I mentioned in Section 2.3, one of the more annoying problems with FreeBSD's current distribution format is the dividing line between distributions and packages. There should really only be one type of distribution format and, of course, it should be the package (There Can Be Only One). Achieving this means we're first going to have to grapple with several problems, however: First, eliminating the distribution format means either teaching the package tools how to deal with a split archive format (they currently do not) or divorcing ourselves forever from floppies as a distribution medium. This is an issue which would seem an easy one to decide but invariably becomes Highly Religious(tm) every time it's brought up. In some dark corner of the world, there always seems to be somebody still installing FreeBSD via floppies and even some of the fortune 500 folks can cite FreeBSD success stories where they resurrected some old 386 box (with only a floppy drive and no networking/CD/...) and turned it into the star of the office/saved the company/etc etc. That's not to say we can't still bite that particular bullet, just that it's not a decision which will go down easily with everyone and should be well thought-out. And I have to say, I agree. If abondoning floppies is part of some well-thought-out and well-planned package management strategy, I'm all for it. Otherwise, let sleeping dogs lie? It isn't as far as I can understand from that link. JKH is talking about doing floppy only install (some old 386 box (with only a floppy drive and no networking/CD/...) and turned it into the star of the office/saved the company/etc etc...) not loading an installation kernel and /stand from floppy and then transfer to network/cd later. This because when then base/packages need to fit on floppy. This isn't necessary for the current two-flop, then CD install which is discussed now. P.s. for the record, I prefer Slackware's approach to floppy booting. Multiple cut down bootsets (SCSI, NET etc) with the ability to simply extract extra kernel modules from CD to a floppy (on a separate machine) and load them from floppy while still in the initial system ramdisk (before mounting CD). The loading/mounting etc must be done by hand, no extra new functionality required. Maybe the basic idea should be to forget the equivalence of floppy and cd boot, and deliver a set of kernel modules on CD, and a few basic boot/root floppies, and for the rest let users create their own custom driver discs, and do some extra work to keep their floppy boot running. That ends the one boot/root for all idea, but is maybe more flexible, ( didn't have to make something with custom kernel to install my Proliant 1500, but only select the right kernel disc and copy some extra kernel moduless to an empty flop) and at the same time decrease release engineering on the floppies. I think this is a good compromise: Keep floppy option open, but shift some burden to the users. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] This idea dawned on me a few moments ago: If it's really such a big deal to get rid of floppy support, how about we get rid of it and make sure an older version of FreeBSD 4.x/5.x is always available for download? This way, floppy users could install an older version of the OS and cvsup to the latest version they want. I see the above as a decent compromise. This way, we no longer have to support newer floppy editions, but we leave people with floppy drives an option to perform the installation. What do you think? -- William Michael Grim Student, Southern Illinois University at Edwardsville Unix Network Administrator, SIUE, Computer Science dept. Phone: (217) 341-6552 Email: [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Assembler coding help needed.
Martin Nilsson wrote: I'm trying to find out why I can't boot 5.2 from USB CDROM on Supermicro motherboards. (I have an old Gateway P3 that can!). I've found out that that only 0x20 of 0x4c sectors of the loader are read in and it therfor traps when executed. (read is only called once). My last attempt at programming x86 assembler was ~15years ago so I'm a bit rusty :-) The below loop from cdboot.s is what I'm having problem understanding, how can this fail on one box but not on another? # # Load the binary into the buffer. Due to real mode addressing limitations # we have to read it in in 64k chunks. # mov DIR_SIZE(%bx),%eax# Read file length add $SECTOR_SIZE-1,%eax# Convert length to sectors shr $11,%eax %eax is 0x4c here on both machines! cmp $BUFFER_LEN,%eax jbe load_sizeok mov $msg_load2big,%si# Error message call error load_sizeok:movzbw %al,%cx# Num sectors to read mov DIR_EXTENT(%bx),%eax# Load extent xor %edx,%edx mov DIR_EA_LEN(%bx),%dl add %edx,%eax# Skip extended mov $MEM_READ_BUFFER,%ebx# Read into the buffer load_loop:mov %cl,%dh cmp $MAX_READ_SEC,%cl# Truncate to max read size jbe load_notrunc mov $MAX_READ_SEC,%dh load_notrunc:sub %dh,%cl# Update count push %eax# Save call read# Read it in The fun will be here. The rest is self contained and doesn't depend on CPU variant or periphery. pop %eax# Restore add $MAX_READ_SEC,%eax# Update LBA add $MAX_READ,%ebx# Update dest addr jcxz load_done# Done? jmp load_loop# Keep going load_done: ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Future of RAIDFrame and Vinum (was: Future of RAIDFrame)
Poul-Henning == Poul-Henning Kamp [EMAIL PROTECTED] writes: Poul-Henning In message [EMAIL PROTECTED], Poul-Henning Greg 'groggy' Lehey writes: Poul-Henning The reason I say this is that neither of you have the Poul-Henning time needed, and whoever picks up may have ideas, even Poul-Henning necesarry ideas, which would grind your spine seriously. Poul-Henning By letting go, I think you would give vinum a better Poul-Henning chance. In the p4 tree, we can easier add new talent to our developer force and I am pretty sure that some sort of merry band of developers would form around both RF and vinum there. ... now I thought I followed this list relatively well, but can someone point me at what 'p4' is? Dave. -- |David Gilbert, Independent Contractor. | Two things can only be | |Mail: [EMAIL PROTECTED]| equal if and only if they | |http://daveg.ca | are precisely opposite. | =GLO ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discussion on the future of floppies in 5.x and 6.x
* Brooks Davis [EMAIL PROTECTED] [2004-01-11 11:02 -0800]: If you could make this work such that you just stuffed GENERIC and the mfsroot onto however many floppies it takes, I think that would almost certaintly solve re's problems with floppies (i.e. if all they had to do when the kernel/mfsroot got too big was to bump a NUMFLOPPIES variable.) Sure that would suck for the floppy users, but that would put the pain in the place where it's most likely to cause someone to come up with some better. Now, who wants to give this a try? OK, I tried now the following: I made copies of the 4.9 RELEASE Floppies, split the half of the kernel and mfsroot to another floppy and added two appropriate splitfiles. Afterwards booting from these four disks worked fine. disk1: /boot /kernel.gz.split /kernel.gzaa Message from libstand disk2: /kernel.gzab Message from loader.rc disk3: /mfsroot.gz.split /mfsroot.gzaa Message from libstand disk4: /mfsroot.gzab I don't know the release build process, so I don't know how much effort is neccessary to create such floppies, but the loader seems to have all features needed to use such disks. Nicolas ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Future of RAIDFrame and Vinum (was: Future of RAIDFrame)
David Gilbert wrote: In the p4 tree, we can easier add new talent to our developer force and I am pretty sure that some sort of merry band of developers would form around both RF and vinum there. ... now I thought I followed this list relatively well, but can someone point me at what 'p4' is? p4 is an SCM, some will say the best money can buy :) http://www.perforce.com Some of the FreeBSD development takes place in a perforce repo, perforce.freebsd.org iirc. Cheers, -- Miguel Mendez [EMAIL PROTECTED] http://www.energyhq.es.eu.org PGP Key: 0xDC8514F1 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Future of RAIDFrame and Vinum (was: Future of RAIDFrame)
On 01/11/04 12:13:36 +0100 Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Alexander Leidinger writes: fine, but if I got it right, do you (Greg) agree to remove it from -current? My proposal is to do just that with both vinum and raidframe until one or possibly both are up to full strength again. and I'm pretty sure, that you'll provide means to migrate the vinum volumes on -current systems transparently and in-place to regular partitions? vinum (IMHO) is a quite valuable piece of software. I'm using it quite intensively; *especially* on -current-boxes I'm in need of most flexible storage management. -Andreas ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: [Freebsd-hackers] Re: FreeBSD 5.1 Installation probelms
Sorry to interupt, but i think that person x, since he has a weird name ;-) , means that the partitioning device of freebsd cannot access the extended partition at all. I had this with a friend of mine, and we could not access the devices anymore since it was packed inside another partition (we migrated from linux to freebsd) We needed to use a bit of software that could re-enable our partition. Perhaps Avinash can reply with the software name/ Also it is possible that your partition is held inside another one, how to resolve? No idea, i always started with a clean hdd, or a new one when the current on needed to be saved. Hope it helped a little. Cheers -- Kind regards, Remko Lodder Elvandar.org/DSINet.org www.mostly-harmless.nl Dutch community for helping newcomers on the hackerscene -Oorspronkelijk bericht- Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Daan Vreeken [PA4DAN] Verzonden: zondag 11 januari 2004 14:07 Aan: 70uf33q Hu5541n CC: [EMAIL PROTECTED] Onderwerp: [Freebsd-hackers] Re: FreeBSD 5.1 Installation probelms On Sunday 11 January 2004 11:29, 70uf33q Hu5541n wrote: hey guys, Just got my copy of FreeBSD 5.1. Spent about an hour going through the BSD Handbook and preparing a Installation checklist. ok here's my problem. I have a WD 40 GB HDD the primary partition is 10 GB, with the extended partition 28 GB.(the rest 2 GB is in WD's bank). OK , the extended partition has 3 logical drives. To create a slice for BSD, I resized one of the logical drives to free up some space. About 1.2 GB,cause that's all I can spare. When I run the installation through CDROM, and the point where I'm to creat the Freebsd slice,the new partition is not displayed in the FDISK utility. All I get is the primary (10GB) and the whole Extended (28 GB). The freespace I guess is locked into the Extended Partiton. Not sure though. Indeed you first have to resize the extended partition before you can use the space to create slices. The fdisk program that comes with Windows has no way to do this (except deleting all logicle drives in the extended partition and re-creating them). Have a look at the program Partition Magic. It can resize partitions and it has a nice user interface. grtz, Daan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ Freebsd-hackers mailing list [EMAIL PROTECTED] http://lists.elvandar.org/mailman/listinfo/freebsd-hackers ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Future of RAIDFrame
In message: [EMAIL PROTECTED] Poul-Henning Kamp [EMAIL PROTECTED] writes: : In message [EMAIL PROTECTED], David Gilbert writes: : That said, we need a strong and robust software raid. : : And as long as we have something which mostly work there seems to : be insufficient motivation to make that happen. : : Therefore my proposal to send both RF and Vinum in training camp in p4. This has been a fundamental disagreement in the development model for a long time. Some people think this is a great idea, others hate it. The pros are that open source tends to be written best when there's pain and suffering to overcome. The cons are that sometimes things that are shot in the head never come back to life, leaving our users in the lurch. Maybe this would be a good test-case for seeing how well it works? Maybe not. We do need to run a few more test-cases for things through this scenario... I'm not sure this one is well suited to it. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discussion on the future of floppies in 5.x and 6.x
On Sun, Jan 11, 2004 at 09:24:38PM +0100, Nicolas Rachinsky wrote: Now, who wants to give this a try? OK, I tried now the following: I made copies of the 4.9 RELEASE Floppies, split the half of the kernel and mfsroot to another floppy and added two appropriate splitfiles. Afterwards booting from these four disks worked fine. OK, someone help me out here :) I was going to try this with a range of floppies (4.8, 4.9, 5.1, 5.2, etc), but I can't figure out what to do with splitfs.c gcc -o splitfs /usr/src/lib/libstand/splitfs.c /usr/lib/crt1.o: In function `_start': /usr/lib/crt1.o(.text+0x85): undefined reference to `main' /tmp/cc1Xbt2V.o: In function `splitfs_open': /tmp/cc1Xbt2V.o(.text+0x239): undefined reference to `fgetstr' /tmp/cc1Xbt2V.o: In function `splitfs_seek': /tmp/cc1Xbt2V.o(.text+0x695): undefined reference to `panic' /tmp/cc1Xbt2V.o(.text+0x801): undefined reference to `panic' /tmp/cc1Xbt2V.o(.data+0x10): undefined reference to `null_write' /tmp/cc1Xbt2V.o(.data+0x1c): undefined reference to `null_readdir' I'm guessing that's not the right thing to do. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Assembler coding help needed. [solved, patch enclosed]
Marcin Dalecki wrote: Martin Nilsson wrote: I'm trying to find out why I can't boot 5.2 from USB CDROM on Supermicro motherboards. (I have an old Gateway P3 that can!). I've found out that that only 0x20 of 0x4c sectors of the loader are read in and it therfor traps when executed. (read is only called once). load_notrunc:sub %dh,%cl# Update count push %eax# Save call read# Read it in The fun will be here. The rest is self contained and doesn't depend on CPU variant or periphery. I found the problem! The bios trashes %cx when reading from USB CD but not when reading from ATAPI CD. The attached patch fixes this and two other small nits in sys/boot/i386/cdboot/cdboot.s Can somebody (jhb) commit this? This probably affects all Phoenix-Award bios equipped boxes. My old Gateway with AMI BIOS works as it should. /Martin *** cdboot.s-original Sun Jan 11 22:16:45 2004 --- cdboot.sSun Jan 11 22:16:13 2004 *** *** 165,171 # mov DIR_SIZE(%bx),%eax # Read file length add $SECTOR_SIZE-1,%eax # Convert length to sectors ! shr $11,%eax cmp $BUFFER_LEN,%eax jbe load_sizeok mov $msg_load2big,%si # Error message --- 165,171 # mov DIR_SIZE(%bx),%eax # Read file length add $SECTOR_SIZE-1,%eax # Convert length to sectors ! shr $SECTOR_SHIFT,%eax cmp $BUFFER_LEN,%eax jbe load_sizeok mov $msg_load2big,%si # Error message *** *** 182,189 mov $MAX_READ_SEC,%dh load_notrunc: sub %dh,%cl # Update count push %eax # Save call read # Read it in ! pop %eax# Restore add $MAX_READ_SEC,%eax # Update LBA add $MAX_READ,%ebx # Update dest addr jcxz load_done # Done? --- 182,191 mov $MAX_READ_SEC,%dh load_notrunc: sub %dh,%cl # Update count push %eax # Save + push %cx# Supermicro BIOS trashes cx when booting USB CD call read # Read it in ! pop %cx # Restore ! pop %eax add $MAX_READ_SEC,%eax # Update LBA add $MAX_READ,%ebx # Update dest addr jcxz load_done # Done? *** *** 460,465 --- 462,468 mov twiddle_chars,%bx # Address table inc %al # Next and $3,%al # char + mov %al,twiddle_index # Save index xlat# Get char call putc # Output it mov $8,%al # Backspace ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SCM options (was Re: Where is FreeBSD going?)
At 10:00 AM + 1/11/04, Doug Rabson wrote: On Sun, 2004-01-11 at 00:05, Peter Jeremy wrote: I disagree. Andrew raised two issues (type of license and port vs base location). The type of license is an input to the decision as to which SCM to choose - BSD preferable ... Subversion has a friendly BSD-ish license but it depends heavily on Sleepycat DB which doesn't. I imagine that if we do end up using it one day, it would be best managed as a port rather than part of the base system. I just don't see many people agreeing on importing subversion+db-4.2+apache2 into src/contrib... Another way of approaching that is to say subversion is not-likely to be imported *unless* we can find an acceptable BSD-licensed database mgr to go along with it. (I do not know how much of Apache is needed. Would svn *clients* need to have apache installed, or is that only needed for machines that hold a public repository?) -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SCM options (was Re: Where is FreeBSD going?)
On Jan 11, 2004, at 5:19 PM, Garance A Drosihn wrote: At 10:00 AM + 1/11/04, Doug Rabson wrote: On Sun, 2004-01-11 at 00:05, Peter Jeremy wrote: I disagree. Andrew raised two issues (type of license and port vs base location). The type of license is an input to the decision as to which SCM to choose - BSD preferable ... Subversion has a friendly BSD-ish license but it depends heavily on Sleepycat DB which doesn't. I imagine that if we do end up using it one day, it would be best managed as a port rather than part of the base system. I just don't see many people agreeing on importing subversion+db-4.2+apache2 into src/contrib... Another way of approaching that is to say subversion is not-likely to be imported *unless* we can find an acceptable BSD-licensed database mgr to go along with it. (I do not know how much of Apache is needed. Would svn *clients* need to have apache installed, or is that only needed for machines that hold a public repository?) Subversion servers require Berkeley DB and potentially Apache if you want to use mod_dav_svn as your server. If you don't want to use mod_dav_svn you can avoid the dependency on Apache. Subversion clients require APR (the Apache Portable Runtime) and potentially Neon (a webdav client library) if you want to use mod_dav_svn as your server. In any event, I'm not convinced that importing Subversion into the tree is necessary even if you do want to use it. There's no real reason it can't just live in the ports tree as it does now. -garrett ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: [Freebsd-hackers] Re: FreeBSD 5.1 Installation probelms
hey Remko, the FreeBSD sysinstall (i think) program does identify the extended partitions but not the logical drives contained in it. and yes, I've not introduced myself yet. :D btw, I'm Toufeeq from Chennai,India. 20 yrs old doing my Engineering final year. Been a linux user for 4 years now. FreeBSD , well I was interested more in the way the history/development of the OS took place and that got me hooked on and so I wanted to give it a try. Sadly though, my hard disk is causing problems.Though that wont stop me ;) btw, name uses wat some people call 'lewt' speak its just replacing alphabets with numbers, like 3 = e and a = 4. so 70uf33q is actually Toufeeq. love to explain more but its 4 am and I got a test on Monday. cheers, toufeeq --- Remko Lodder [EMAIL PROTECTED] wrote: Sorry to interupt, but i think that person x, since he has a weird name ;-) , means that the partitioning device of freebsd cannot access the extended partition at all. I had this with a friend of mine, and we could not access the devices anymore since it was packed inside another partition (we migrated from linux to freebsd) We needed to use a bit of software that could re-enable our partition. Perhaps Avinash can reply with the software name/ Also it is possible that your partition is held inside another one, how to resolve? No idea, i always started with a clean hdd, or a new one when the current on needed to be saved. Hope it helped a little. Cheers -- Kind regards, Remko Lodder Elvandar.org/DSINet.org www.mostly-harmless.nl Dutch community for helping newcomers on the hackerscene -Oorspronkelijk bericht- Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Daan Vreeken [PA4DAN] Verzonden: zondag 11 januari 2004 14:07 Aan: 70uf33q Hu5541n CC: [EMAIL PROTECTED] Onderwerp: [Freebsd-hackers] Re: FreeBSD 5.1 Installation probelms On Sunday 11 January 2004 11:29, 70uf33q Hu5541n wrote: hey guys, Just got my copy of FreeBSD 5.1. Spent about an hour going through the BSD Handbook and preparing a Installation checklist. ok here's my problem. I have a WD 40 GB HDD the primary partition is 10 GB, with the extended partition 28 GB.(the rest 2 GB is in WD's bank). OK , the extended partition has 3 logical drives. To create a slice for BSD, I resized one of the logical drives to free up some space. About 1.2 GB,cause that's all I can spare. When I run the installation through CDROM, and the point where I'm to creat the Freebsd slice,the new partition is not displayed in the FDISK utility. All I get is the primary (10GB) and the whole Extended (28 GB). The freespace I guess is locked into the Extended Partiton. Not sure though. Indeed you first have to resize the extended partition before you can use the space to create slices. The fdisk program that comes with Windows has no way to do this (except deleting all logicle drives in the extended partition and re-creating them). Have a look at the program Partition Magic. It can resize partitions and it has a nice user interface. grtz, Daan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ Freebsd-hackers mailing list [EMAIL PROTECTED] http://lists.elvandar.org/mailman/listinfo/freebsd-hackers ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] = Love is control,I'll die if I let go I will only let you breathe My air that you receive Then we'll see if I let you love me. -James Hetfield All Within My Hands,St.Anger Metallica __ Do you Yahoo!? Yahoo! Hotjobs: Enter the Signing Bonus Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: [Freebsd-hackers] Re: FreeBSD 5.1 Installation probelms
Excuse me, that is what i ment, (the logical drives) As said with Avinash, we could not access that as well, and he used to program he replied with (will be posted to this list when the admin approves :) ) to restore it's data. But perhaps that makes it also able to modify it a little to make it accessible by freebsd fdisk/disklabel (not sysinstall i think, since i think it calles fdisk or disklabel). Anyway i am not sure this will work and does the job, but perhaps you can have a look at it, Though i never had your problem, as said i just plugged in a little extra harddrive (450mb was my first and it worked perfect :) ) and i do know the l33t language, but i prefer the 'normal' language :) please to meet you toufeeq and success with your harddrive/freebsd and your test. -- Kind regards, Remko Lodder Elvandar.org/DSINet.org www.mostly-harmless.nl Dutch community for helping newcomers on the hackerscene -Oorspronkelijk bericht- Van: 70uf33q Hu5541n [mailto:[EMAIL PROTECTED] Verzonden: zondag 11 januari 2004 23:35 Aan: Remko Lodder CC: [EMAIL PROTECTED] Onderwerp: RE: [Freebsd-hackers] Re: FreeBSD 5.1 Installation probelms hey Remko, the FreeBSD sysinstall (i think) program does identify the extended partitions but not the logical drives contained in it. and yes, I've not introduced myself yet. :D btw, I'm Toufeeq from Chennai,India. 20 yrs old doing my Engineering final year. Been a linux user for 4 years now. FreeBSD , well I was interested more in the way the history/development of the OS took place and that got me hooked on and so I wanted to give it a try. Sadly though, my hard disk is causing problems.Though that wont stop me ;) btw, name uses wat some people call 'lewt' speak its just replacing alphabets with numbers, like 3 = e and a = 4. so 70uf33q is actually Toufeeq. love to explain more but its 4 am and I got a test on Monday. cheers, toufeeq --- Remko Lodder [EMAIL PROTECTED] wrote: Sorry to interupt, but i think that person x, since he has a weird name ;-) , means that the partitioning device of freebsd cannot access the extended partition at all. I had this with a friend of mine, and we could not access the devices anymore since it was packed inside another partition (we migrated from linux to freebsd) We needed to use a bit of software that could re-enable our partition. Perhaps Avinash can reply with the software name/ Also it is possible that your partition is held inside another one, how to resolve? No idea, i always started with a clean hdd, or a new one when the current on needed to be saved. Hope it helped a little. Cheers -- Kind regards, Remko Lodder Elvandar.org/DSINet.org www.mostly-harmless.nl Dutch community for helping newcomers on the hackerscene -Oorspronkelijk bericht- Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Daan Vreeken [PA4DAN] Verzonden: zondag 11 januari 2004 14:07 Aan: 70uf33q Hu5541n CC: [EMAIL PROTECTED] Onderwerp: [Freebsd-hackers] Re: FreeBSD 5.1 Installation probelms On Sunday 11 January 2004 11:29, 70uf33q Hu5541n wrote: hey guys, Just got my copy of FreeBSD 5.1. Spent about an hour going through the BSD Handbook and preparing a Installation checklist. ok here's my problem. I have a WD 40 GB HDD the primary partition is 10 GB, with the extended partition 28 GB.(the rest 2 GB is in WD's bank). OK , the extended partition has 3 logical drives. To create a slice for BSD, I resized one of the logical drives to free up some space. About 1.2 GB,cause that's all I can spare. When I run the installation through CDROM, and the point where I'm to creat the Freebsd slice,the new partition is not displayed in the FDISK utility. All I get is the primary (10GB) and the whole Extended (28 GB). The freespace I guess is locked into the Extended Partiton. Not sure though. Indeed you first have to resize the extended partition before you can use the space to create slices. The fdisk program that comes with Windows has no way to do this (except deleting all logicle drives in the extended partition and re-creating them). Have a look at the program Partition Magic. It can resize partitions and it has a nice user interface. grtz, Daan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ Freebsd-hackers mailing list [EMAIL PROTECTED] http://lists.elvandar.org/mailman/listinfo/freebsd-hackers ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] = Love is control,I'll die if I let go I will only let you breathe My air that you receive Then we'll see if I let you love me. -James Hetfield All Within My
RE: [Freebsd-hackers] Re: FreeBSD 5.1 Installation probelms
hey, ok noted. will wait for Avinash's software.will also check out if its possible under PartitionMagic 8 and let you know if that works out. great to be among this community. bye, Toufeeq --- Remko Lodder [EMAIL PROTECTED] wrote: Excuse me, that is what i ment, (the logical drives) As said with Avinash, we could not access that as well, and he used to program he replied with (will be posted to this list when the admin approves :) ) to restore it's data. But perhaps that makes it also able to modify it a little to make it accessible by freebsd fdisk/disklabel (not sysinstall i think, since i think it calles fdisk or disklabel). Anyway i am not sure this will work and does the job, but perhaps you can have a look at it, Though i never had your problem, as said i just plugged in a little extra harddrive (450mb was my first and it worked perfect :) ) and i do know the l33t language, but i prefer the 'normal' language :) please to meet you toufeeq and success with your harddrive/freebsd and your test. -- Kind regards, Remko Lodder Elvandar.org/DSINet.org www.mostly-harmless.nl Dutch community for helping newcomers on the hackerscene -Oorspronkelijk bericht- Van: 70uf33q Hu5541n [mailto:[EMAIL PROTECTED] Verzonden: zondag 11 januari 2004 23:35 Aan: Remko Lodder CC: [EMAIL PROTECTED] Onderwerp: RE: [Freebsd-hackers] Re: FreeBSD 5.1 Installation probelms hey Remko, the FreeBSD sysinstall (i think) program does identify the extended partitions but not the logical drives contained in it. and yes, I've not introduced myself yet. :D btw, I'm Toufeeq from Chennai,India. 20 yrs old doing my Engineering final year. Been a linux user for 4 years now. FreeBSD , well I was interested more in the way the history/development of the OS took place and that got me hooked on and so I wanted to give it a try. Sadly though, my hard disk is causing problems.Though that wont stop me ;) btw, name uses wat some people call 'lewt' speak its just replacing alphabets with numbers, like 3 = e and a = 4. so 70uf33q is actually Toufeeq. love to explain more but its 4 am and I got a test on Monday. cheers, toufeeq --- Remko Lodder [EMAIL PROTECTED] wrote: Sorry to interupt, but i think that person x, since he has a weird name ;-) , means that the partitioning device of freebsd cannot access the extended partition at all. I had this with a friend of mine, and we could not access the devices anymore since it was packed inside another partition (we migrated from linux to freebsd) We needed to use a bit of software that could re-enable our partition. Perhaps Avinash can reply with the software name/ Also it is possible that your partition is held inside another one, how to resolve? No idea, i always started with a clean hdd, or a new one when the current on needed to be saved. Hope it helped a little. Cheers -- Kind regards, Remko Lodder Elvandar.org/DSINet.org www.mostly-harmless.nl Dutch community for helping newcomers on the hackerscene -Oorspronkelijk bericht- Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Daan Vreeken [PA4DAN] Verzonden: zondag 11 januari 2004 14:07 Aan: 70uf33q Hu5541n CC: [EMAIL PROTECTED] Onderwerp: [Freebsd-hackers] Re: FreeBSD 5.1 Installation probelms On Sunday 11 January 2004 11:29, 70uf33q Hu5541n wrote: hey guys, Just got my copy of FreeBSD 5.1. Spent about an hour going through the BSD Handbook and preparing a Installation checklist. ok here's my problem. I have a WD 40 GB HDD the primary partition is 10 GB, with the extended partition 28 GB.(the rest 2 GB is in WD's bank). OK , the extended partition has 3 logical drives. To create a slice for BSD, I resized one of the logical drives to free up some space. About 1.2 GB,cause that's all I can spare. When I run the installation through CDROM, and the point where I'm to creat the Freebsd slice,the new partition is not displayed in the FDISK utility. All I get is the primary (10GB) and the whole Extended (28 GB). The freespace I guess is locked into the Extended Partiton. Not sure though. Indeed you first have to resize the extended partition before you can use the space to create slices. The fdisk program that comes with Windows has no way to do this (except deleting all logicle drives in the extended partition and re-creating them). Have a look at the program Partition Magic. It can resize partitions and it has a nice user interface. grtz, Daan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ Freebsd-hackers mailing list [EMAIL
Re: Discussion on the future of floppies in 5.x and 6.x
* Avleen Vig [EMAIL PROTECTED] [2004-01-11 13:34 -0800]: On Sun, Jan 11, 2004 at 09:24:38PM +0100, Nicolas Rachinsky wrote: Now, who wants to give this a try? OK, I tried now the following: I made copies of the 4.9 RELEASE Floppies, split the half of the kernel and mfsroot to another floppy and added two appropriate splitfiles. Afterwards booting from these four disks worked fine. OK, someone help me out here :) I was going to try this with a range of floppies (4.8, 4.9, 5.1, 5.2, etc), but I can't figure out what to do with splitfs.c Do nothing, the loader already contains it. Nicolas ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Future of RAIDFrame and Vinum (was: Future of RAIDFrame)
On Sun, 11 Jan 2004, Andreas Braukmann wrote: On 01/11/04 12:13:36 +0100 Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Alexander Leidinger writes: fine, but if I got it right, do you (Greg) agree to remove it from -current? My proposal is to do just that with both vinum and raidframe until one or possibly both are up to full strength again. and I'm pretty sure, that you'll provide means to migrate the vinum volumes on -current systems transparently and in-place to regular partitions? vinum (IMHO) is a quite valuable piece of software. I'm using it quite intensively; *especially* on -current-boxes I'm in need of most flexible storage management. oh yes - and please fix disklabel to support an arbirtary number of file system per a disk or slice in the process, because otherwise it will not be converting many setups. -Andreas ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 5.1 Installation probelms
hey Daan, :) I did use Partition mAgic 8 to resize the partition. PM8 resized the logical drive.Not the extended partition.SO though I have unused space on my HD, its locked away in the Extended Partition and not detected by F-BSD. Is it possible to resize the whole extended partition with PM8? Not a power-windows user, so havent used PM8 much. I hope the people behind FreeBSD could fix this problem. RedHat/other linux distros seem to use the free space perfectly fine. Also, does FreeBSD use FAT or ext2/3 partition? -just a doubt. cheers, TH --- Daacn Vreeken [PA4DAN] [EMAIL PROTECTED] wrote: On Sunday 11 January 2004 11:29, 70uf33q Hu5541n wrote: hey guys, Just got my copy of FreeBSD 5.1. Spent about an hour going through the BSD Handbook and preparing a Installation checklist. ok here's my problem. I have a WD 40 GB HDD the primary partition is 10 GB, with the extended partition 28 GB.(the rest 2 GB is in WD's bank). OK , the extended partition has 3 logical drives. To create a slice for BSD, I resized one of the logical drives to free up some space. About 1.2 GB,cause that's all I can spare. When I run the installation through CDROM, and the point where I'm to creat the Freebsd slice,the new partition is not displayed in the FDISK utility. All I get is the primary (10GB) and the whole Extended (28 GB). The freespace I guess is locked into the Extended Partiton. Not sure though. Indeed you first have to resize the extended partition before you can use the space to create slices. The fdisk program that comes with Windows has no way to do this (except deleting all logicle drives in the extended partition and re-creating them). Have a look at the program Partition Magic. It can resize partitions and it has a nice user interface. grtz, Daan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] = Love is control,I'll die if I let go I will only let you breathe My air that you receive Then we'll see if I let you love me. -James Hetfield All Within My Hands,St.Anger Metallica __ Do you Yahoo!? Yahoo! Hotjobs: Enter the Signing Bonus Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Future of RAIDFrame and Vinum (was: Future of RAIDFrame)
On Sun, Jan 11, 2004 at 12:13:36PM +0100, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Alexander Leidinge r writes: I'm a little bit confused. I've read Pouls mail as an suggestion to remove vinum from -current and let people modify it in the perforce repository. If I got this wrong, please tell me and everything is fine, but if I got it right, do you (Greg) agree to remove it from -current? My proposal is to do just that with both vinum and raidframe until one or possibly both are up to full strength again. On behalf of people like me who are mere users, let me protest that removing vinum would break working systems and create needless hardship. What would be gained? Are there upcoming changes in the rest of the OS that the presence of vinum would make harder? If not, then please branch vinum to perforce if you like, but leave it in -current until it's actually broken for most users, which is not the case now. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Future of RAIDFrame and Vinum
David Gilbert wrote: Poul-Henning == Poul-Henning Kamp [EMAIL PROTECTED] writes: Poul-Henning In message [EMAIL PROTECTED], Poul-Henning Greg 'groggy' Lehey writes: Poul-Henning The reason I say this is that neither of you have the Poul-Henning time needed, and whoever picks up may have ideas, even Poul-Henning necesarry ideas, which would grind your spine seriously. Poul-Henning By letting go, I think you would give vinum a better Poul-Henning chance. In the p4 tree, we can easier add new talent to our developer force and I am pretty sure that some sort of merry band of developers would form around both RF and vinum there. ... now I thought I followed this list relatively well, but can someone point me at what 'p4' is? Dave. p4 = perforce source control. I'd seen the perforce depot somewhere on freebsd's sites, but didn't previous to this discussion understand it's purpose. Someone with more of a clue than I can fill in the blanks, but it seems that the perforce depot is essentially open-access, (unlike needing the commit bit set in FreeBSDs CVS tree), or at least easier to get commit privs assigned, allowing people that are not currently FreeBSD commiters to contribute changes back to the repository...at some point, presumably, to be rolled back into the main development branch of FreeBSD by integrating back into CVSif a project at some point becomes 'release-worthy.' More info on perforce is available at www.perforce.com . I saw someone mention in this thread not liking perforce, although I'm not sure why- I used to be pretty heavily involved in SCM/DTS, and perforce IMHO was/is one of the few SCMs that generally 'did the right thing' in a usually unobtrusive way. Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: [Freebsd-hackers] Re: FreeBSD 5.1 Installation probelms
Hi, I had a similair problem as Remko described. I used R-Linux. U can download it from http://www.r-tt.com Put the hard drive, on which u can't reach the certain partition, in a pc with Windows installed on it, run R-Linux and u should be able to see the drive and partition that u couldn't read. Good luck ! Avinash Piare --- M [EMAIL PROTECTED], [EMAIL PROTECTED] Citeren Remko Lodder [EMAIL PROTECTED]: Sorry to interupt, but i think that person x, since he has a weird name ;-) , means that the partitioning device of freebsd cannot access the extended partition at all. I had this with a friend of mine, and we could not access the devices anymore since it was packed inside another partition (we migrated from linux to freebsd) We needed to use a bit of software that could re-enable our partition. Perhaps Avinash can reply with the software name/ Also it is possible that your partition is held inside another one, how to resolve? No idea, i always started with a clean hdd, or a new one when the current on needed to be saved. Hope it helped a little. Cheers -- Kind regards, Remko Lodder Elvandar.org/DSINet.org www.mostly-harmless.nl Dutch community for helping newcomers on the hackerscene -Oorspronkelijk bericht- Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Daan Vreeken [PA4DAN] Verzonden: zondag 11 januari 2004 14:07 Aan: 70uf33q Hu5541n CC: [EMAIL PROTECTED] Onderwerp: [Freebsd-hackers] Re: FreeBSD 5.1 Installation probelms On Sunday 11 January 2004 11:29, 70uf33q Hu5541n wrote: hey guys, Just got my copy of FreeBSD 5.1. Spent about an hour going through the BSD Handbook and preparing a Installation checklist. ok here's my problem. I have a WD 40 GB HDD the primary partition is 10 GB, with the extended partition 28 GB.(the rest 2 GB is in WD's bank). OK , the extended partition has 3 logical drives. To create a slice for BSD, I resized one of the logical drives to free up some space. About 1.2 GB,cause that's all I can spare. When I run the installation through CDROM, and the point where I'm to creat the Freebsd slice,the new partition is not displayed in the FDISK utility. All I get is the primary (10GB) and the whole Extended (28 GB). The freespace I guess is locked into the Extended Partiton. Not sure though. Indeed you first have to resize the extended partition before you can use the space to create slices. The fdisk program that comes with Windows has no way to do this (except deleting all logicle drives in the extended partition and re-creating them). Have a look at the program Partition Magic. It can resize partitions and it has a nice user interface. grtz, Daan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ Freebsd-hackers mailing list [EMAIL PROTECTED] http://lists.elvandar.org/mailman/listinfo/freebsd-hackers -- Email provided by elvandar.org Email [EMAIL PROTECTED] for an address ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SCM options (was Re: Where is FreeBSD going?)
On Sat, Jan 10, 2004 at 09:05:50AM -0800, Pedro F. Giffuni wrote: I think we must wait until a 1.0 version is available. SVN is meant to be a replacement to CVS. The projects repository is using perforce which happens to be a good tool, so moving it to svn is probably not a step forward IMHO ;-). No, the projects/ repository is in CVS. There's also a perforce repository that people use for development work, but it's not what Garance was talking about. Kris pgp0.pgp Description: PGP signature
RE: [Freebsd-hackers] Re: FreeBSD 5.1 Installation probelms !-==solved==-!
whew! Gentlemen, its done, freeBSD 5.1 has been installed.PartitionMagic 8 did the trick though :( sad that I had to use windows. anyway, this is what I did.(Daan deserves credit) 1.free disk space at the last logical drive of the extended partition. 2.resize the last logical drive to create unallocated space. 3.*here's the best part* Resize the Extended partition such that the unallocated part gets left out completely. 4.thats all, apply changes. please excuse me, I havent slept in 2 days and maybe I'm displaying bursts of euphoria. :D was hard though, but enjoyed every bit of it.Had to go through documentation about disk geometry,inodes and what not... anyway I'm thrilled. X config and all the rest was a breeze. setup GNOME , looks good. all set for a great ride. Thanks to Daan, Remko and Avinash couldnt have done it without you guys. ok think I'll stop. ;) cheers, toufeeq Its 9:30 am here, and I think I better go to sleep now cause the monitor seems to be spining around my head.just wanted to tell u guys about it. --- Avinash Piare [EMAIL PROTECTED] wrote: Hi, I had a similair problem as Remko described. I used R-Linux. U can download it from http://www.r-tt.com Put the hard drive, on which u can't reach the certain partition, in a pc with Windows installed on it, run R-Linux and u should be able to see the drive and partition that u couldn't read. Good luck ! Avinash Piare --- M [EMAIL PROTECTED], [EMAIL PROTECTED] Citeren Remko Lodder [EMAIL PROTECTED]: Sorry to interupt, but i think that person x, since he has a weird name ;-) , means that the partitioning device of freebsd cannot access the extended partition at all. I had this with a friend of mine, and we could not access the devices anymore since it was packed inside another partition (we migrated from linux to freebsd) We needed to use a bit of software that could re-enable our partition. Perhaps Avinash can reply with the software name/ Also it is possible that your partition is held inside another one, how to resolve? No idea, i always started with a clean hdd, or a new one when the current on needed to be saved. Hope it helped a little. Cheers -- Kind regards, Remko Lodder Elvandar.org/DSINet.org www.mostly-harmless.nl Dutch community for helping newcomers on the hackerscene -Oorspronkelijk bericht- Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Daan Vreeken [PA4DAN] Verzonden: zondag 11 januari 2004 14:07 Aan: 70uf33q Hu5541n CC: [EMAIL PROTECTED] Onderwerp: [Freebsd-hackers] Re: FreeBSD 5.1 Installation probelms On Sunday 11 January 2004 11:29, 70uf33q Hu5541n wrote: hey guys, Just got my copy of FreeBSD 5.1. Spent about an hour going through the BSD Handbook and preparing a Installation checklist. ok here's my problem. I have a WD 40 GB HDD the primary partition is 10 GB, with the extended partition 28 GB.(the rest 2 GB is in WD's bank). OK , the extended partition has 3 logical drives. To create a slice for BSD, I resized one of the logical drives to free up some space. About 1.2 GB,cause that's all I can spare. When I run the installation through CDROM, and the point where I'm to creat the Freebsd slice,the new partition is not displayed in the FDISK utility. All I get is the primary (10GB) and the whole Extended (28 GB). The freespace I guess is locked into the Extended Partiton. Not sure though. Indeed you first have to resize the extended partition before you can use the space to create slices. The fdisk program that comes with Windows has no way to do this (except deleting all logicle drives in the extended partition and re-creating them). Have a look at the program Partition Magic. It can resize partitions and it has a nice user interface. grtz, Daan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ Freebsd-hackers mailing list [EMAIL PROTECTED] http://lists.elvandar.org/mailman/listinfo/freebsd-hackers -- Email provided by elvandar.org Email [EMAIL PROTECTED] for an address ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] = Love is control,I'll die if I let go I will only let you breathe My air that you receive Then we'll see if I let you love me. -James Hetfield All Within My Hands,St.Anger Metallica __ Do you Yahoo!? Yahoo! Hotjobs: Enter the Signing Bonus Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus
Re: Future of RAIDFrame and Vinum (was: Future of RAIDFrame)
In message [EMAIL PROTECTED], Narvi writes: oh yes - and please fix disklabel to support an arbirtary number of file system per a disk or slice in the process, because otherwise it will not be converting many setups. We need to move to a different labeling format because bsdlabel has a number of problems going forward. GPT is our current candidate. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Future of RAIDFrame
In message [EMAIL PROTECTED], Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?= writes: M. Warner Losh [EMAIL PROTECTED] writes: Maybe this would be a good test-case for seeing how well it works? Maybe not. We do need to run a few more test-cases for things through this scenario... I'm not sure this one is well suited to it. If we toss out Vinum, there's a significant risk that 5.3 will ship without RAID support at all. I'm pretty certain we don't want that. If we don't do something drastic, there's a significant risk that 5.3 and all future releases will ship with partially broken RAID support. I'm pretty certain we don't want that either. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: UNIX / BSD parallel port programming documentation
On Saturday 10 January 2004 02:33, Vladimir Terziev wrote: I have to develop small server which has to manage custom microcontroller via parallel port interface. Does anyone know good manual/documentation about UNIX / BSD parallel port programming ? Someone mentioned the ppi etc pages which is good, there is also this port - /usr/ports/devel/avrprog - which programs an Atmel AVR micro via the parallel port (works quite well in my experience) you should be able to examine the source code for clues. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Gratituous ARP and the em driver
When I change IP addresses on my 'em' gigabit NIC, ARP isn't sent properly. This appears to be the problem in the following bug report, however i'm using the 'fixed' version of the em driver (in FreeBSD 4.9). http://www.freebsd.org/cgi/query-pr.cgi?pr=54488 Does anyone have any tips on how to get around this? I'm building new systems with gigabit ethernet support and this problem keeps cropping up. I have a failover system, and when moving an IP alias between machines, the em NIC driver doesn't properly send out gratituous ARP, resulting in the IP being inaccessible. - The problem does not occur when plugged into a 100BaseTX switch - FreeBSD 4.9p1 / em version 1.7.16 - Tried various gigabit switches. - One other odd thing is that when configuring the NIC (ifconfig) the machine locks up for several seconds. Thanks in advance. Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
