Re: Request for swapcontext and getcontext to be ported to our libc [ revision 3 ]
Hi There, Running latest head with libc-only *context function. mtasker test program works, but powerdns-recursor still doesnt compile (even with gcc 3.4.6) /usr/include/machine/endian.h:70:1: warning: this is the location of the previous definition pdns_recursor.cc: In function `void startDoResolve(void*)': pdns_recursor.cc:563: error: invalid conversion from `void*' to `char*' pdns_recursor.cc:564: error: invalid conversion from `void*' to `char*' pdns_recursor.cc:1139: confused by earlier errors, bailing out [wrapper.sh] note: The real command line, after the pkgsrc wrapper, was: /usr/obj/pkgsrc/wip/powerdns-recursor/work/.gcc/bin/g++ -O -pipe -I/usr/obj/pkgsrc/wip/powerdns-recursor/work/.buildlink/include -Wall -O3 -c -o pdns_recursor.o pdns_recursor.cc -L/usr/obj/pkgsrc/wip/powerdns-recursor/work/.buildlink/lib gmake: *** [pdns_recursor.o] Error 1 *** Error code 2 Stop. bmake: stopped in /usr/pkgsrc/wip/powerdns-recursor *** Error code 1 Stop. bmake: stopped in /usr/pkgsrc/wip/powerdns-recursor Petr [EMAIL PROTECTED] wrote: :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 Ok, I restored those bits. I have implemented the assembly and done some other cleanups and a bit of testing. I am committing the completed work now. I have not yet implemented the floating point save/restore. I will check save-used for FP registers and see if I can optimize what gets saved. When switching occurs synchronously I don't think the FP regs need to be saved/restored unless the prorgam is compiled to use FP regs and general regs so this may be good enough for the moment. Switching from a signal dispatch is more problematic. That almost certainly requires FP save/restore. Now we need some comprehensive testing with packages that actually use this beast! -Matt Matthew Dillon <[EMAIL PROTECTED]>
Re: ipw3945 WLAN driver
On 1/17/07, Nuno Antunes <[EMAIL PROTECTED]> wrote: On 11/19/06, Sepherosa Ziehau <[EMAIL PROTECTED]> wrote: > On 19 Nov 2006 09:15:38 GMT, Johannes Hofmann <[EMAIL PROTECTED]> wrote: > > Thomas Schlesinger <[EMAIL PROTECTED]> wrote: > > > Am Dienstag, 14. November 2006 18:40 schrieb Thomas Schlesinger: > > >> Hi, > > >> > > >> are there plans to port the ipw3945 driver from OpenBSD in the near future? > > >> > > >> Thomas > > > > > > Ok, I take this as "no" ;-) > > I did a preliminary port several months ago: > http://leaf.dragonflybsd.org/~sephe/wpi.tbz > > It is known to crash some place arround firmware loading. I do not > have hardware to keep going, so if you are interested, you can > continue it or start from scratch (NetBSD's wpi port may be a better > start point than OpenBSD's) > > I will be glad to commit it, if you can knock it out :-) > > Best Regards, > sephe > Hello Sephe, I have the hardware and I am willing to test this and try to make it work on my laptop. I tweaked your preliminary port a bit so that it compiles on HEAD. The interface is correctly detected when I load the module. But now I'm stuck. How do I upload the firmware? I've installed pkgsrc sysutils/wpi-firmware. I tried the following but I get an error: class# ipwcontrol wpi0 -f /usr/pkg/libdata/if_wpi/ipw3945.ucode ipwcontrol: Can't load /usr/pkg/libdata/if_wpi/ipw3945.ucode to driver: Bad address wpicontrol is needed to upload firmware into wpiX. umm, I forgot to put wpicontrol in that tarball. I will put it on leaf once I get home. Please prepare to panic once you have uploaded the firmware and 'ifconfig wpi0 up' ;] There are very informative guide about how to debug: http://wiki.dragonflybsd.org/index.cgi/Development Best Regards, sephe -- Live Free or Die
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
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. cheers simon -- Serve - BSD +++ RENT this banner advert +++ASCII Ribbon /"\ Work - Mac +++ space for low €€€ NOW!1 +++ Campaign \ / Party Enjoy Relax | http://dragonflybsd.org Against HTML \ Dude 2c 2 the max ! http://golden-apple.biz Mail + News / \
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: ipw3945 WLAN driver
On 11/19/06, Sepherosa Ziehau <[EMAIL PROTECTED]> wrote: On 19 Nov 2006 09:15:38 GMT, Johannes Hofmann <[EMAIL PROTECTED]> wrote: > Thomas Schlesinger <[EMAIL PROTECTED]> wrote: > > Am Dienstag, 14. November 2006 18:40 schrieb Thomas Schlesinger: > >> Hi, > >> > >> are there plans to port the ipw3945 driver from OpenBSD in the near future? > >> > >> Thomas > > > > Ok, I take this as "no" ;-) I did a preliminary port several months ago: http://leaf.dragonflybsd.org/~sephe/wpi.tbz It is known to crash some place arround firmware loading. I do not have hardware to keep going, so if you are interested, you can continue it or start from scratch (NetBSD's wpi port may be a better start point than OpenBSD's) I will be glad to commit it, if you can knock it out :-) Best Regards, sephe Hello Sephe, I have the hardware and I am willing to test this and try to make it work on my laptop. I tweaked your preliminary port a bit so that it compiles on HEAD. The interface is correctly detected when I load the module. But now I'm stuck. How do I upload the firmware? I've installed pkgsrc sysutils/wpi-firmware. I tried the following but I get an error: class# ipwcontrol wpi0 -f /usr/pkg/libdata/if_wpi/ipw3945.ucode ipwcontrol: Can't load /usr/pkg/libdata/if_wpi/ipw3945.ucode to driver: Bad address Thanks, Nuno
Re: Watching TV with DragonFly
:Hi Guys, : :I want to watch TV with my Hauppauge WinTV/PCI (bt848) on my :DragonFlyBSD-box. : :The card works: : :bktr0: mem 0xdff0-0xdff00fff irq 11 at device 9.0 on :pci0 :bktr0: Hauppauge Model 60124 C1V :bktr0: Detected a MSP3400C-C6 at 0x80 :bktr0: Hauppauge WinCast/TV, Philips FR1216 PAL FM tuner, msp3400c stereo. : :I can watch TV with xawtv using grabdisplay (with overlay-mode I only got a :black screen). My favorite TV-application on BSD is mplayer, but I can't :get it working on DragonFly: : :Playing tv://. :TV file format detected. :No such driver: bsdbt848 : :Any hints how to build mplayer with DragonFly-Support? : :Thanks in advance. I've never had much luck getting bktr0 to work with mplayer. I'm not entirely sure but I think mplayer tries to mmap() the video frame and I think our bktr might be deficient in handling that case. Matthew Dillon <[EMAIL PROTECTED]>
Re: Journals and jscan
: : :> I have at last got two DragonFly boxes up and it seems like a good :> idea to get some data security with jscan based mirrors. I don't think it's production ready for that sort of thing. The main problem is that the link represents a choke point and reduces filesystem performance greatly. A second issue is that a frontend has to be written to reconnect and restart the journaling stream when the connection is lost and to deal long term connection failures (i.e. if one of the boxes is brought down). : Just to follow up - I had a play while I was waiting :) I hit a :problem which may be a bug (or may be me) - I tried this: : :#mkdir /home/journal_test :#cd /home/journal_test :#cpdup /tmp tmp :#cd tmp :#mountctl -a /tmp:test | jscan -m stdin : : I got this response pretty quickly: : :/tmp:test added :Bad path: /vi.recover/vi.fH1xrt :Bad path: /vi.recover/vi.fH1xrt :Bad path: /vi.recover/vi.fH1xrt Hmm. The path shouldn't be absolute. Try using the -D option to jscan to specify the base directory for mirroring operations. ... | jscan -m stdin -D /home/hournal_test/tmp Mirroring that way should mostly work. It is fairly easy to debug issues that pop up by also using the -d option to generate human readable debug output. -Matt Matthew Dillon <[EMAIL PROTECTED]>
Re: Journals and jscan
> I have at last got two DragonFly boxes up and it seems like a good > idea to get some data security with jscan based mirrors. Just to follow up - I had a play while I was waiting :) I hit a problem which may be a bug (or may be me) - I tried this: #mkdir /home/journal_test #cd /home/journal_test #cpdup /tmp tmp #cd tmp #mountctl -a /tmp:test | jscan -m stdin I got this response pretty quickly: /tmp:test added Bad path: /vi.recover/vi.fH1xrt Bad path: /vi.recover/vi.fH1xrt Bad path: /vi.recover/vi.fH1xrt -- C:>WIN | Directable Mirror Arrays The computer obeys and wins.| A better way to focus the sun You lose and Bill collects. |licences available see |http://www.sohara.org/
Journals and jscan
Hi, I have at last got two DragonFly boxes up and it seems like a good idea to get some data security with jscan based mirrors. The only thing is the man pages say that most of the features are unimplemented but don't give any idea how much actually is implemented. So the quick question before I drive myself crazy trying things and wondering if I've screwed up is - is there enough implemented to manage mirrors of selected filesystems across my LAN ? -- C:>WIN | Directable Mirror Arrays The computer obeys and wins.| A better way to focus the sun You lose and Bill collects. |licences available see |http://www.sohara.org/
