Re: What's the status of the USB stack port?
Hello, On Sat, Sep 01, 2012 at 07:44:47PM +1000, elekktrett...@exemail.com.au wrote: Hi all, Last time I heard there was someone working on the port. I'd be willing to test (my dragonfly installation is long not used because my USB peripherals - keyboard etc are not working with the existing USB stack) Thanks for your offer! I am currently caught up in getting my PhD submitted. Once that is done and I have settled in at my new work space I will finish the port pretty quickly I guess. I also thank Sascha for putting the effort in to get USB into master. I guess by the end of September you will be able to use the USB stack as a replacement for the old one. Markus -- Markus Pfeiffer, University of St Andrews email: markus.pfeif...@morphism.de | xmpp: markus.pfeif...@jabber.morphism.de pgpqd7QtE5d82.pgp Description: PGP signature
Re: ghc linker problem with __thread int errno
Dear all, On Sat, Mar 03, 2012 at 07:55:29AM +0100, Thomas Nikolajsen wrote: as of yesterday a fix for dragonfly's rtld and I have a 5 line patch against ghc head that makes ghci and template haskell work. I successfully compiled ghc 7.4.1 and ghc head with this. Thanks; more currying please! We like Haskel B. Curry! (found Foundations of Mathematical Logic by Curry, 1963 edition w/ jacket on Amazon) (schönfinkeling is too tounge breaking, we also like Moses Schönfinkel) Finally my patch against GHC has made it into ghc master. I will test building all the latest GHC goodness soon. Markus -- Markus Pfeiffer, University of St Andrews email: markus.pfeif...@morphism.de | xmpp: markus.pfeif...@jabber.morphism.de pgp1oftSyCgt5.pgp Description: PGP signature
Re: Unable to mount hammer file system Undo failed
On Thu, Jul 19, 2012 at 12:42:02PM +0200, Wojciech Puchar wrote: UFS use flat on disk structure. inodes are at known places. I don't know how HAMMER data is placed, but seems everything is dynamic. any link to description of HAMMER on disk layout? Please, read hammer(8) (at the subcommand recover). thank you very much. While such recovery is painfully slow (it scans entire image not just selected predefined areas like fsck_ffs) it DO EXIST. Seems i have to make some more tests with intentionally broken hardware, which i don't have at the moment. just dd /dev/random and overwrite a few sectors? Markus -- Markus Pfeiffer, University of St Andrews email: markus.pfeif...@morphism.de | xmpp: markus.pfeif...@jabber.morphism.de pgp6zMu1T4MDJ.pgp Description: PGP signature
Re: ghc linker problem with __thread int errno
on x86_64. So the next point on my todo list for ghc is, to recompile ghc without my errno access wrapper, take the .got value from the resulting binary and recompile ghc again with the linker inserting this value, check that the .got value hasn't changed, and see what happens. If this goes well, the next steps would be to (a) find out, how to calculate the .got value inside the linker, and (b) think about an experiment, that could show me what has to be done, when there is more than one tls variable. Hmm, maybe I should try also from the opposite side: How important is this static __inline on the __error function? Are there any situations, where one would notice a performance impact? -- Goetz Isenmann -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Michael Heinrichs, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Philippe Miltin Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 -- Markus Pfeiffer, University of St. Andrews email: markus.pfeif...@morphism.de | xmpp: markus.pfeif...@jabber.morphism.de pgppRNLgL8u31.pgp Description: PGP signature
Re: w3m / boehm-gc issue (really is getcontext in x86_64)
Hello,
On 2011-12-17, Matthias Rampke matth...@rampke.de wrote:
On Friday, 16. December 2011 at 13:28, John Marino wrote:
FYI, Per bugs #2108, Alex created the getContext.S function a few months ago:
http://leaf.dragonflybsd.org/~alexh/0001-getcontext-x86_64-implementation.patch
FWIW, here's my (failed) stab at taking Alex' getcontext.S and the old x86_64
makecontext.c and signalcontext.c from before the removal:
http://2p.grade.so/dfly/getmakesignalcontext.patch
It does not compile, because there is no PIC_PROLOGUE and PIC_EPILOGUE for
x86_64 – I don't know why (not needed?) and my last and only steps with
assembler were a long long time ago and involved only a quarter of bits so I
really don't know where to go from that. But maybe the {make,signal}context
implementations are of any use?
This code is wrong in numerous places (wrong registers used for parameter
passing, wrong size of arguments etc). I posted a patch to the issue tracker
but that seems to have problems too. I will try to fix those tomorrow and also
provide setcontext and swapcontext.
Cheers,
Markus
--
Markus Pfeiffer, University of St. Andrews
email: markus.pfeif...@morphism.de | xmpp: markus.pfeif...@jabber.morphism.de
w3m / boehm-gc issue (really is getcontext in x86_64)
Dear all, I started using dragonfly not too long ago. I wanted to build w3m from pkgsrc on x86_64. Configure failed in a check for libgc, which is installed. I found out that libgc uses getcontext (and assumes it to exist) which it doesn't on x86_64 dragonfly. To fix boehm-gc + w3m, I just inserted a defined(__DragonFly__) into mach_deps.c Would it be a good idea to port the i386 version of getcontext into x86_64? I am willing to do that, then. Markus
