Re: New mirror in Russia
On Tue, February 24, 2009 11:43 am, Constantine A. Murenin wrote: Speaking of mirrors in Russia, there is no internet in the Asian part of Russia, let alone any mirrors, so it's a bit strange that Russian mirrors are still listed in the Asian section of the mirrors page. :) Would that mean Russia is considered part of the European content? I was always taught that Asia was the continent from Ukraine on westwards, but that was back when Czechoslovakia and the USSR still existed. Reading the Wikipedia entries for "Europe" and "Asia" is quite interesting. For example, both include Russia under various categorizations. Should we remove the by-continent distinctions? FreeBSD simply provides a list of countries and mirrors. Perhaps we should do the same. -- Matt Emmerton
Re: Release 1.10 update - 31-Jul-07
"Simon 'corecode' Schubert" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Matthew Dillon wrote: > > No. We only include kernel sources on the CD. Generally speaking there > > isn't much of a point including anything else on a CD, but I would love > > to see an nrelease target for a DVD which preinstalls all sorts of > > nice packages and contains the full pkgsrc tree and full sources to > > everything, uncompressed and ready to use. > > For that we'd need some sort of compressed filesystem, otherwise there won't be much fitting even on a DVD. But hopefully we'll get to a userland interface this year and then the world is open to all kind of fancy filesystem ideas. For pkgsrc, why couldn't we just include a recent snapshot of /usr/pkgsrc on the CD (much like how FreeBSD provides a snapshot of /usr/ports). The tree that I updated last night is 387MB uncompressed, 195MB compressed. As a seasoned FreeBSD user, it took me a while to figure out how to get the pkgsrc tree on my machine. I didn't consider installing binary packages as my experience with RPMs has left me jaded. (I'm sure pkgsrc is much, much better than the mess of RPMs.) If we provided the option to install the pkgsrc tree, then folks could at least build/install packages from sources. Once their tree gets stale enough, the can figure out how to update it with cvs (just as folks in FreeBSD land have to figure out how to use csup/cvsup) or investigate how to use binary packages. Regards, -- Matt Emmerton
Re: Help with confusing C code in loader?
"walt" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > I'm trying to debug a problem in /boot/loader but I'm stumped by > this line in sys/boot/common/module.c: > > error = (file_formats[i]->l_load)(filename, loadaddr, &fp); > > This seems to refer to a line in common/bootstrap.h: > > int (* l_load)(char *filename, u_int64_t dest, struct preloaded_file **result); > > And that's where I lose the thread. I can't figure out what the > (* l_load) means because 'l_load' doesn't seem to be defined in > any obvious place. l_load is a function pointer, and a member of struct file_formats, which is declared "extern struct file_format *file_formats[]" in common/bootstrap.h. The comments say that this structure is provided by the consumer, so more digging is required. sys/boot/ARCH/loader/conf.c appears to be the "consumer", as each defines *file_formats[]. In the ARCH=pc32 case, the array contains pointers to two file formats: i386_elf and amd64_elf. These are declared extern, so their definitions reside somewhere else. Yet more digging. These two are defined in sys/boot/pc32/libi3864/elf32_freebsd.c and elf64_freebsd.c. >From these structure defs, they are implicitly initialized, so the l_load function pointer (which isn't explicitly mentioned!) is either elf32_loadfile or elf64_loadfile, depending on whether you're looking at i386_elf or amd64_elf. So where is *_loadfile implemented? I don't know. This is where I lost the thread. HTH, -- Matt Emmerton
Re: cvs commit: src/sys/dev/disk/fd fd.c fdc.h
> Francois Tigeot wrote: > > On Mon, May 21, 2007 at 08:34:57PM -0400, Matt Emmerton wrote: > > > >>> Gergo Szakal wrote: > >>> > >>>> On Mon, 21 May 2007 18:57:29 +0200 > >>>> Erik Wikström <[EMAIL PROTECTED]> wrote: > >>>> > >>>> > >>>>> Isn't it about time to drop support for floppies soon? > >>>>> > >>>> No, floppies are still great, especially on legacy hardware. > >>>> > >>>> > >>> Yeah indeed, but I would drop (E)ISA bus support and hardware that uses > >>> (E)ISA. I haven't seen anyone use it for a looong time. > >>> > >> EISA is long dead and can go away > >> ISA is still used on modern hardware -- anything without USB mouse/keyboard > >> uses ISA under the covers, along with other stuff. > > > > And you can still buy modern machines with real ISA expansion slots. Core2 Duo > > PCs with ISA slots seem a bit weird, but they exist. > > > You are right, but I think because DragonFly is a small sized project we > should be trying to support the most common modern hardware, instead of > ancient hardware that barely no one uses these days. You may be interested to know that my primary DFly development machine is an AMD Sempron-based system with a BIOS date of late 2004. This machine could hardly be considered "ancient", but yet it has ISA slots and numerous other devices that rely on the ISA bus architecture. Be careful what you wish for -- removing ISA support will prevent a great deal of hardware from running DFly, and I don't think anyone is interested in taking that step. -- Matt Emmerton
Re: cvs commit: src/sys/dev/disk/fd fd.c fdc.h
> Gergo Szakal wrote: > > On Mon, 21 May 2007 18:57:29 +0200 > > Erik Wikström <[EMAIL PROTECTED]> wrote: > > > >> Isn't it about time to drop support for floppies soon? > > > > No, floppies are still great, especially on legacy hardware. > > > Yeah indeed, but I would drop (E)ISA bus support and hardware that uses > (E)ISA. I haven't seen anyone use it for a looong time. EISA is long dead and can go away ISA is still used on modern hardware -- anything without USB mouse/keyboard uses ISA under the covers, along with other stuff. -- Matt Emmerton
Re: Did I bork my compiler?
> Matt Emmerton wrote: > > Just updated to latest HEAD, and now buildworld is busted. I did a > > buildworld/installworld around this time yesterday, and am wondering if I > > managed to break my compiler in the process. > > No, I did :) > > sorry to all who trashed their compiler. I quickly committed a fix, so the window was fairly small. > > For everybody experiencing this problem: > > /usr/libexec/binutils215/elf/ld: crt1.o: No such file: No such file or > > directory > > do a > > cp /usr/lib/crt*.o /usr/lib/gcc34 > > the next build/quickworld will then correctly install the new files to this location. I've managed to boostrap my system by copying over gcc from a recent -snap (prior to the 3.4.6 update). Thanks for the quick response though! -- Matt Emmerton
Did I bork my compiler?
Just updated to latest HEAD, and now buildworld is busted. I did a buildworld/installworld around this time yesterday, and am wondering if I managed to break my compiler in the process. -- >>> stage 1: bootstrap tools -- cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj/usr/src/btools_i386 OBJTREE=/usr/obj DESTDIR=/usr/obj/usr/src/btools_i386 PATH=/usr/obj/usr/src/btools_i386/usr/sbin:/usr/obj/usr/src/btools_i386/usr/ bin:/usr/obj/usr/src/btools_i386/bin:/usr/obj/usr/src/btools_i386/usr/games: /sbin:/bin:/usr/sbin:/usr/bin INSTALL="sh /usr/src/tools/install.sh" make -f Makefile.inc1 -DBOOTSTRAPPING -DNOINFO -DNOMAN -DNOPIC -DNOPROFILE -DNOSHAR ED -DNO_WERROR -DNO_NLS bootstrap-tools ln -fs /bin/date /usr/obj/usr/src/btools_i386/bin/date echo "===> games/fortune/strfile (bootstrap-tools)"; cd /usr/src/games/fortune/strfile; make DIRPRFX=games/fortune/strfile/ obj; make DIRPRFX=games/fortune/strfile/ depend; make DIRPRFX=games/fortune/strfile/ all; make DIRPRFX=games/fortune/strfile/ DESTDIR=/usr/obj/usr/src/btools_i386 install ===> games/fortune/strfile (bootstrap-tools) /usr/obj/usr/src/btools_i386/usr/src/games/fortune/strfile created for /usr/src/games/fortune/strfile rm -f .depend mkdep -f .depend -a /usr/src/games/fortune/strfile/strfile.c echo strfile: /usr/obj/usr/src/btools_i386/usr/lib/libc.a >> .depend cc -O -pipe -mtune=pentiumpro -Wunknown-pragmas -Wsystem-headers -Wall -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcas t-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wchar-subscripts -Win line -Wnested-externs -Wredundant-decls -c /usr/src/games/fortune/strfile/strfile.c cc -O -pipe -mtune=pentiumpro -Wunknown-pragmas -Wsystem-headers -Wall -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcas t-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wchar-subscripts -Win line -Wnested-externs -Wredundant-decls -static -o strfile strfile.o /usr/libexec/binutils215/elf/ld: crt1.o: No such file: No such file or directory *** Error code 1 -- Matt Emmerton
Re: Request for swapcontext and getcontext to be ported to our libc [ revision 3 ]
> > :Code changes uploaded to website, rev4. > : > :-- > :Matt Emmerton > > Ok, looks pretty good. I'm going to run with this so don't post any > more updates. rev4 had some kernel cruft left over from rev3. I > removed it. > > -Matt I revisited these two kernel files and agree partially with your assessment: - machdep.c fixed a missing linebreak; the other change (mc_len) was cruft. - ucontext.h contains the protos for the *context routines; they still need to be somewhere so autoconf can find them, and I felt that this was the best place for them. The other stuff (uc_flags, UCF_SWAPPED) was cruft. -- Matt Emmerton
Re: Request for swapcontext and getcontext to be ported to our libc [ revision 3 ]
Matt, > :A first cut of the libc-based implementation, using a (new) syscall to > :get/set the signal its is available, and can be found here: > :http://www.gsicomp.on.ca/~matt/dfly/ (rev3, bottom of page) > > Ok, I see a few things, all easy to fix: > > * sigpend is not swapped in and out. This is the bitmask of pending > signals. It stays as it is. I misunderstood your earlier comment about the pending mask. > * sigmask must be adjusted by the kernel to remove unmaskable signals > using SIG_CANTMASK(sigmask); > > * There is a naming conflict between the sigmask() system call and > thethe 'sigmask' identifier, but (see next item)... > > * You shouldn't need a new system call anyway, the sigprocmask() system > call can be used to retrieve and set the signal mask. I recommend > using that. Absolutely. The only reason I invented a new syscall was because of my misunderstanding above :) > There is one more issue, and that is an atomicy issue. We want the > new signal mask to be set simultaniously with the restoration of the > context (or most of it). This means that all signals must be masked > temporarily while restoring the context. But don't worry about it, > I can handle that part as well. It does mean an extra system call > but that isn't our concern at the moment. > > I can fill in the missing code assembly, no problem. If you do one > more rev using sigprocmask() instead of creating a new system call > I can then take it from there. Code changes uploaded to website, rev4. -- Matt Emmerton
Re: Request for swapcontext and getcontext to be ported to our libc [ revision 3 ]
> :I agree with the assessment. Last night I moved all the requisite bits from > :kernel-space into libc, with the exception of the low-level > :[get|set]_mcontext routines. (My Intel assembly knowledge is very limited, > :especially for anything after the 8086, so I could use some help to write > :this code.) I'm almost done the syscall work to get/set the signal mask and > :pending signal mask, so should have something up on the web before the end > :of the afternoon (EST) for review. > :-- > :Matt Emmerton > > I can do that bit. If you post the bits you have I can supply and > test the low level switch code. > > -Matt > Matthew Dillon A first cut of the libc-based implementation, using a (new) syscall to get/set the signal its is available, and can be found here: http://www.gsicomp.on.ca/~matt/dfly/ (rev3, bottom of page) Note that this implementation is not complete, as it is missing the userland get/set_mcontext code. I'm sure I've also missed some nuance wrt signal handling (locking, ordering, etc) in the design and use of the new sigmask syscall. -- Matt Emmerton
Re: Request for swapcontext and getcontext to be ported to our libc
> :So is the current context code going into cvs HEAD or whats happening? > : > :Petr > > I'm going to let the discussion continue for another day or two but > I will note that Matt is the person doing the work so it depends on > how much time he has available to do the libc version prior to the > release (assuming he agrees with the assessment that it is better to > do the libc version for the release then the syscall version). > > -Matt I agree with the assessment. Last night I moved all the requisite bits from kernel-space into libc, with the exception of the low-level [get|set]_mcontext routines. (My Intel assembly knowledge is very limited, especially for anything after the 8086, so I could use some help to write this code.) I'm almost done the syscall work to get/set the signal mask and pending signal mask, so should have something up on the web before the end of the afternoon (EST) for review. Regards, -- Matt Emmerton
Re: Request for swapcontext and getcontext to be ported to our libc
Petr, Based on information scattered about the Internet, as well as what the FreeBSD folks have done, it appears that powerdns-recursor requires gcc-3.4.6 to compile properly. This is a problem as DFly's native gcc is 3.4.5 and the pkgsrc version of 3.4.6 does not support DFly. To do this right, we will need DFly to support the 3.4.6 compiler before we can support this package. Regards, -- Matt Emmerton > > I see. > > What about getting someone to get powerdns-recusor compiling and running? > > > > Once that is done we shall arrange for your payment. > > > > Petr > > > > > > Matt Emmerton wrote: > > >> Hey, > > >> Any progress on the fully libc *context functions? > > >> > > > > > > I've toyed with it a bit, but there are some issues I'm not sure how to > > > solve (such as accessing curthread -- a kernel construct -- from > userland). > > > I would welcome discussion with the person who suggested it (corecode?). > > > > > > Also, I felt it pertinent to focus on the quick-start FreeBSD port to > get it > > > into the 1.8-release. > > > > > > -- > > > Matt Emmerton > > > > > > > > >
Re: Request for swapcontext and getcontext to be ported to our libc
I think we're debating whether to "do it right" or "do it now". Tuesday is a long way off yet :) -- Matt Emmerton > So is the current context code going into cvs HEAD or whats happening? > > Petr > > Simon 'corecode' Schubert wrote: > > Matthew Dillon wrote: > >> The answer is: yes, it is possible. There is no reason why the > >> signal mask (and signal pending bitmap) couldn't be stored in user > >> memory, allowing the userland threading system to swap out the mask > >> without entering the kernel. > > > > I absolutely agree. I am thinking of a special page mapped in kernel > > and userspace memory, where things like signal mask and pending (per > > thread) are located, and maybe also a timecounter, pid, etc. > > > >> So I think there is a very good argument for making the current > >> release > >> implementation do these calls in libc and not as system calls, and > >> initially have libc just get the signal mask with a system call, > >> then > >> at some later date add the feature sthat allow the userland context > >> routines to run fully without having to make any system calls at > >> all. > > > > If Matt Emmerton finds the time to implement it, I am all for it. > > Having these functions as syscalls seems wrong in my eyes. > > > > cheers > > simon > > >
Re: Request for swapcontext and getcontext to be ported to our libc
Simon wrote: > Matt Emmerton wrote: > > I've toyed with it a bit, but there are some issues I'm not sure how to > > solve (such as accessing curthread -- a kernel construct -- from userland). > > I would welcome discussion with the person who suggested it (corecode?). > > In which way do you have to access curthread? That's a kernel-only > entity, I don't think you have to access that in userland. Besides, if we > take in the system call version, there is no need for a pure libc based > version anymore. Point taken, and that's definitely the path we're going down at the moment. However, I recall it being mentioned that the proliferation of syscalls is unneccessary, so a libc implementation would keep the kernel lean. The reason we need curthread is to get access to the frame construct, which is neccessary to save the context. Regards, -- Matt Emmerton
Re: Request for swapcontext and getcontext to be ported to our libc
Petr, I'm starting on that now :) -- Matt Emmerton > I see. > What about getting someone to get powerdns-recusor compiling and running? > > Once that is done we shall arrange for your payment. > > Petr > > > Matt Emmerton wrote: > >> Hey, > >> Any progress on the fully libc *context functions? > >> > > > > I've toyed with it a bit, but there are some issues I'm not sure how to > > solve (such as accessing curthread -- a kernel construct -- from userland). > > I would welcome discussion with the person who suggested it (corecode?). > > > > Also, I felt it pertinent to focus on the quick-start FreeBSD port to get it > > into the 1.8-release. > > > > -- > > Matt Emmerton > > > > >
Re: RFR: Port of FreeBSD *context routines to DFly
> > :I have completed the port of [set|get|make|swap]context from FreeBSD to > :DFly. > : > :The latest patch set against HEAD (current as of Jan 12, 00:00 EST) is > :available here: http://www.gsicomp.on.ca/~matt/dfly > : > :I (and others) would really like to see this get into the release, so I > :would appreciate reviews and comments. Nothing too earth-shattering here - > :it's a straight port with some minor modifications due ot Matt's recent > :VKERNEL and trapframe changes. > : > :Regards, > :-- > :Matt Emmerton > > I will put it into the release. It looks good. The only thing I > would change is to put the new context code you added to > machine/pc32/i386/machdep.c into a new file in cpu/i386/misc instead, > so it can be used by both the VKERNEL and the PC32 builds. > > Unless you say otherwise, I will commit it later this evening. This sounds fine by me. I will let you do this -- it seems to me that there are other functions in machdep.c that really belong in the cpu/ hierarchy as well, although I don't have a very keen eye for the cpu/machine distinction (at least on i386). Regards, -- Matt Emmerton
Re: Request for swapcontext and getcontext to be ported to our libc
> Hey, > Any progress on the fully libc *context functions? I've toyed with it a bit, but there are some issues I'm not sure how to solve (such as accessing curthread -- a kernel construct -- from userland). I would welcome discussion with the person who suggested it (corecode?). Also, I felt it pertinent to focus on the quick-start FreeBSD port to get it into the 1.8-release. -- Matt Emmerton
RFR: Port of FreeBSD *context routines to DFly
I have completed the port of [set|get|make|swap]context from FreeBSD to DFly. The latest patch set against HEAD (current as of Jan 12, 00:00 EST) is available here: http://www.gsicomp.on.ca/~matt/dfly I (and others) would really like to see this get into the release, so I would appreciate reviews and comments. Nothing too earth-shattering here - it's a straight port with some minor modifications due ot Matt's recent VKERNEL and trapframe changes. Regards, -- Matt Emmerton
Re: Request for swapcontext and getcontext to be ported to our libc
> Just letting you know that mtasker now compiles after > buildworld/installworld. I assume the "mt" test program runs correctly? I should output an alternating stream of "a" or "b" characters. You can terminate with ^C. > Though, wip/powerdns-recusor doesnt compile yet > (a new error), not mtasker related. > > If someone could please take a look at it, I would be very happy. I'm looking into it. After the error you cite is fixed, there are many more, and I will have to work with the pkgsrc and PowerDNS folks to get them fixed. -- Matt Emmerton
Re: Request for swapcontext and getcontext to be ported to our libc
[ top-posting corrected ] > Petr Janda wrote: > > Matt Emmerton wrote: > > The first cut of this work has been completed. I've ported over the FreeBSD > > i386 work, which is a hybrid libc + kernel syscall implementation. > > > > You can find the source changes and a tiny test program here: > > http://www.gsicomp.on.ca/~matt/dfly/ > > > > I hope to have a libc-only implementation completed before the end of the > > week. > > > Libc and kernel compiled, but wip/powerdns-recursor still gives me the > mtasker errors. I'm assuming that you did installworld/installkernel/reboot before attempting to build wip/powerdns-recursor. After a bit of searching, I added the wip/ bits to my pkgsrc installation and have found that powerdns-recursor has compile warnings/errors/ICE on DFly that are totally unrelated to the *context functions. I'm curious to know what patches/tweaks you are using in your environment to get to the point where you see *context-related failures. # uname -a DragonFly jekell.gsicomp.on.ca 1.7.0-DEVELOPMENT DragonFly 1.7.0-DEVELOPMENT #0: Wed Jan 3 18:21:26 EST 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 # gcc -v Using built-in specs. Configured with: DragonFly/i386 system compiler Thread model: posix gcc version 3.4.5 20050809 (prerelease) [DragonFly] (propolice, visibility) # grep DISTNAME /usr/pkgsrc/wip/powerdns-recursor/Makefile DISTNAME= pdns-recursor-3.1.4 Regards, -- Matt Emmerton
Re: Request for swapcontext and getcontext to be ported to our libc
The first cut of this work has been completed. I've ported over the FreeBSD i386 work, which is a hybrid libc + kernel syscall implementation. You can find the source changes and a tiny test program here: http://www.gsicomp.on.ca/~matt/dfly/ I hope to have a libc-only implementation completed before the end of the week. -- Matt Emmerton
Re: Release Schedule for 1.8
> I would like people to start testing release oriented bits if possible. > We have about two weeks before the CVS tree is branched, and two weeks > after it is branched for fine-tuning and package building. So if there > are things you want to get into the 1.8 release but haven't gotten to yet, > now is the time. I'm hoping to have the [get|set|make|swap]context functions ported to DFly in time for the release. I have all the code bits in place (kernel, libc, libc_r) and am working on debugging right now. Regards, -- Matt Emmerton
Re: Problems booting - stack overflow at boot menu [ updated ]
> :I just downloaded/burned the 1.6-rel image and encounter the same problem. > : > :FreeBSD 4.x installs fine, although the 6.x loader is hit or miss -- > :sometimes it locks up during the countdown sequence, and sometimes it works > :'normally'. Is it possible that my hardware is crap and needs to be put to > :rest? > > I don't think its your hardware. I think the loader is just too complex > and it makes it a real pain to figure out what the cause of these > failures are. Is the loader neccessarily complex? Or could we simplify things some more? (I know folks have worked on this in the past, so this is just a casual inquiry as to what more could be done.) -- Matt Emmerton
Re: Request for swapcontext and getcontext to be ported to our libc
Petr, Given that I'm doing a fair amount of learning-as-I-go with this particular task, it would be unfair to charge my usual hourly rate. I am aware of your budget and I am willing to work within it, regardless of how long this task ultimately takes me. Regards, -- Matt Emmerton > Hey Matt, > Sweet as. How much do you charge per hour? > > Petr > > Matt Emmerton wrote: > >> Noone? Im willing to pay up to $150 AUD ($110 USD, approx 80-90 euro) > >> for those couple of functions + ensuring that PowerDNS-Recursor works > >> after that. Please consider an estimate of how long its going to take > >> and let me know(i suppose it might take only like 30 mins for some of > >> you). Let me know your hourly charge. However keep in mind that i will > >> always double check with other devs that im not being ripped off(not > >> that im cheap, but i know you understand i dont do C thus i cant say how > >> long its going to take...parents taught me to always be careful with > >> money and all) > >> > > > > I've started working on this, using the FreeBSD implementation as a first > > cut for DFly. > > > > It was asked earlier on in the thread why FreeBSD used syscalls for this -- > > it's best to look at the commit comments for rev 1.9 of ucontext.h for their > > reasons -- > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/i386/include/ucontext.h > > > > I'll be following the FreeBSD lead for the first cut; I'll see what we can > > do to improve on this in our world as a follow-on. > > > > Regards, > > -- > > Matt Emmerton > > > > >
Re: Request for swapcontext and getcontext to be ported to our libc
> Noone? Im willing to pay up to $150 AUD ($110 USD, approx 80-90 euro) > for those couple of functions + ensuring that PowerDNS-Recursor works > after that. Please consider an estimate of how long its going to take > and let me know(i suppose it might take only like 30 mins for some of > you). Let me know your hourly charge. However keep in mind that i will > always double check with other devs that im not being ripped off(not > that im cheap, but i know you understand i dont do C thus i cant say how > long its going to take...parents taught me to always be careful with > money and all) I've started working on this, using the FreeBSD implementation as a first cut for DFly. It was asked earlier on in the thread why FreeBSD used syscalls for this -- it's best to look at the commit comments for rev 1.9 of ucontext.h for their reasons -- http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/i386/include/ucontext.h I'll be following the FreeBSD lead for the first cut; I'll see what we can do to improve on this in our world as a follow-on. Regards, -- Matt Emmerton
Re: Problems booting - stack overflow at boot menu [ updated and solved ]
> > On Wed, December 27, 2006 10:30 pm, Matt Emmerton wrote: > > > > > This still happens for the current latest 1.6 snap (09-Dec-06) when > > > booting > > > from the live CD for me.I'd love to get DFly installed on this machine > > > (since 1.2 and 1.4 worked fine), but 1.6 is proving to be a > challenge.I've > > > seen the suggestions of using gcc-2 to build boot0, but is difficult > since > > > I don't have a DFly build environment nor a livecd instance.Any ideas on > > > how to fix this?--Matt Emmerton > > > > It sounds like this wierd error so far has only happened on snap release > > versions; have you tried the release image? > > I just downloaded/burned the 1.6-rel image and encounter the same problem. > > FreeBSD 4.x installs fine, although the 6.x loader is hit or miss -- > sometimes it locks up during the countdown sequence, and sometimes it works > 'normally'. Is it possible that my hardware is crap and needs to be put to > rest? Crap hardware it is! I retired my klunky P233 box in favour of an Athlon 2400. The December snap works fine on this box. -- Matt Emmerton
Re: Problems booting - stack overflow at boot menu [ updated ]
> On Wed, December 27, 2006 10:30 pm, Matt Emmerton wrote: > > > This still happens for the current latest 1.6 snap (09-Dec-06) when > > booting > > from the live CD for me.I'd love to get DFly installed on this machine > > (since 1.2 and 1.4 worked fine), but 1.6 is proving to be a challenge.I've > > seen the suggestions of using gcc-2 to build boot0, but is difficult since > > I don't have a DFly build environment nor a livecd instance.Any ideas on > > how to fix this?--Matt Emmerton > > It sounds like this wierd error so far has only happened on snap release > versions; have you tried the release image? I just downloaded/burned the 1.6-rel image and encounter the same problem. FreeBSD 4.x installs fine, although the 6.x loader is hit or miss -- sometimes it locks up during the countdown sequence, and sometimes it works 'normally'. Is it possible that my hardware is crap and needs to be put to rest? -- Matt Emmerton
Problems booting - stack overflow at boot menu [ updated ]
Matt wrote:> I just pulled down the latest 1.6 snapshot (03-Oct-06) and it> fails to boot. When the loader menu is presented, I get a> "stack overflow" error. > > See http://www.gsicomp.on.ca/~matt/stack.jpg for a digicam> shot of the screen. > > What's most odd is that I don't have a hexdump, but a repeating> sequence of 15 spaces follows by ASCII 0x0F (star-like character). This still happens for the current latest 1.6 snap (09-Dec-06) when booting from the live CD for me.I'd love to get DFly installed on this machine (since 1.2 and 1.4 worked fine), but 1.6 is proving to be a challenge.I've seen the suggestions of using gcc-2 to build boot0, but is difficult since I don't have a DFly build environment nor a livecd instance.Any ideas on how to fix this?--Matt Emmerton
Problems booting - stack overflow at boot menu
I just pulled down the latest 1.6 snapshot (03-Oct-06) and it fails to boot. When the loader menu is presented, I get a "stack overflow" error. See http://www.gsicomp.on.ca/~matt/stack.jpg for a digicam shot of the screen. What's most odd is that I don't have a hexdump, but a repeating sequence of 15 spaces follows by ASCII 0x0F (star-like character). Regards, -- Matt Emmerton
Re: "The future of NetBSD" by Charles M. Hannum
> On Thu, Aug 31, 2006 at 09:58:59AM -0700, Matthew Dillon wrote: > : that 75% of the interest in our project has nothing to do with my > : project goals but instead are directly associated with work being done > : by our relatively small community. I truely appreciate that effort > : because it allows me to focus on the part that is most near and dear > : to my own heart. > > Big question: after all the work that will go into the clustering, other than > scientific research, what will the average user be able to use such advanced > capability for? Average user? Not much. But for anyone who administers server farms, the single-system-image style of clustering is a promise that multiple vendors have tried to deliver, but all have failed (in my memory). Putting on my flame-suit, SCO's Non-Stop Clusters with UnixWare was the best implementation I've seen, but that failed to mature and was axed after the Caldera takeover. (Bill Hacker will likely disagree, but I will point out that I've only been active in the U*ix space for ~10 years at most.) This is where DFly can really steal FreeBSD's thunder. Many of those who use FreeBSD do so in an ISP context. Many of those installations have multiple servers either for load-balancing or redundancy issues. But maintaining many separate servers is a pain. Being able to have multiple DFly boxes that are clustered together and can be administered (at least from the application space) as a single-system-image environment will provide a great boost to productivity. Sure, Xen and virtualization have their place, but there still is a place for huge systems -- whether it's a multi-million dollar 64-way machine (like I use at my "day job"), or a cluster of 32 quad-core Opterons. Regards, -- Matt Emmerton
Re: DFly 1.4.4 and tulip NICs
>Matt Dillon wrote: >:I installed DFly 1.4.4 today and it proply panic'd with a problem in >:tulip_rx_intr(), as described in this mail thread: >:http://leaf.dragonflybsd.org/mailarchive/bugs/2006-02/msg00010.html > Try burning a recent build of HEAD. There's a good chance that the > particular panic referenced (a serializer panic) is fixed in HEAD. If > not it can probably be fixed quickly. Burned and installed a recent snapshot of HEAD, everything is working fine now. >:I was dismayed to find that the DFly ISOs don't include sources, so I >: can't patch this system and get it on the LAN. >:[ Curiosity -- why is this done? I tend to run on ancient hardware with >:FreeBSD and having the sources around has allowed me to patch up drivers to >:get the systems running. Are the sources really too large to include in the >:DFly ISO? ] > The ISO has historically been made as minimal as possible. I agree > with you that the ISO should contain compilable kernel sources. They > dont have to be automatically installed, but we ought to be add them > to the ISO as a gzip'd tar. I see that Matt [ Dillon ] added this three days ago. Yay! Now that's what I call an efficient process! -- Matt Emmerton
DFly 1.4.4 and tulip NICs
I installed DFly 1.4.4 today and it proply panic'd with a problem in tulip_rx_intr(), as described in this mail thread: http://leaf.dragonflybsd.org/mailarchive/bugs/2006-02/msg00010.html I was dismayed to find that the DFly ISOs don't include sources, so I can't patch this system and get it on the LAN. [ Curiosity -- why is this done? I tend to run on ancient hardware with FreeBSD and having the sources around has allowed me to patch up drivers to get the systems running. Are the sources really too large to include in the DFly ISO? ] What's the easiest way to get this machine running? Burn the sources to CD and copy them over, patch/rebuild/reboot? Regards, -- Matt Emmerton
