On Wed, Jul 25, 2012 at 11:30 AM, Matthew Dillon
dil...@apollo.backplane.com wrote:
Well, the media looks corrupted to me. It hit a fairly serious
assertion. If you need the data on that media you should be able
to 'hammer recover' it to another filesystem on a different
:Hi,
:
:I tried to destroy the PFS after unmounting
:
:1. after downgrading
:2. with latest dev snapshot usb stick
:3. in single user mode
:4. after creating a link
:DataNew - @@-1:8
:
:The system always core dumps.
:
:I guess Matt will be busy working on HAMMER2 and wonder if i should
:keep
Hi,
I was destroying a master PFS on the ROOT volume and the system (
v3.1.0.827.gf6167a5-DEVELOPMENT )core dumped.
I tried today's latest snapshot and got the same result.
The Coredump is uploaded to sgeorge@leaf:~/crash/Coredump20120718.tbz
I have reported this through redmine. Is that enough
-DEVELOPMENT )core dumped.
I tried today's latest snapshot and got the same result.
The Coredump is uploaded to sgeorge@leaf:~/crash/Coredump20120718.tbz
I have reported this through redmine. Is that enough or should I
notify bugs@ also?
https://bugs.dragonflybsd.org/issues/2396
Thanks
Siju
On 11/15/2011 9:05 AM, Siju George wrote:
On Tue, Nov 15, 2011 at 1:03 PM, John Marinodragonfly...@marino.st wrote:
BTW, that's not really a useful message. The useful message is in the
file /var/crash/core.text.X where X is the crash number of the saved
dump. Look in there for the 1-2 line
Hi,
On Mon, Nov 14, 2011 at 01:17:24PM +0530, Siju George wrote:
After praying in Tongues I rebooted again :-)
Data is back safe!
Is there something special about the re boot just after a core dump?
The dumped core is usually read from the swap area and put in a file; besides
that boot
Hi,
I didn't receive any response to the core dump message i sent yesterday.
Should i be sending these messages to bugs instead? please let me know.
I have put the coredump at leaf:/home/sgeorge/crash/Coredump2015.tbz
My kernel version is DragonFly v2.13.0.154.g481b38-DEVELOPMENT
These Core
version is DragonFly v2.13.0.154.g481b38-DEVELOPMENT
These Core dumps does not happen every time.
Now I have removed a 512 MB RAM from the machine and I have got the
system up now and I am upgrading to the latest src.
Thanks
--Siju
The core dump message was
The devs are very busy with MP
Hi,
Hammer Core Dumped on My v2.13.0.154.g481b38-DEVELOPMENT.
I have uploaded the core dump to leaf:/home/sgeorge/crash/Coredump2014.tbz
Files are
Coredump2014/
Coredump2014/kern.2
Coredump2014/info.2
Coredump2014/vmcore.2
Coredump2014/bounds
Coredump2014/core.txt.2
for device
Thanks :-)
--Siju
On Mon, Nov 14, 2011 at 10:16 AM, Siju George sgeorge...@gmail.com wrote:
Hi,
Hammer Core Dumped on My v2.13.0.154.g481b38-DEVELOPMENT.
I have uploaded the core dump to
leaf:/home/sgeorge/crash/Coredump2014.tbz
Files are
Coredump2014
long.
RedHat likes being the boss and need to control the development of
keys products. It's not bad thing but is the truth. In Xen they aren't
the boss.
Oh yes, they suffer from an accute case of Not-invented-here. But i can
also empathize them with not wanting to take over on the technologies
development the
developer will have a 512MB VPS. If you need more please let me know.
The environment is a standard de facto in hosting industry. The boot
manager is pvgrub and it's very easy to setup for to run various
systems. You will have a external ssh console for to control your VPS
the developer will need only the minimum requirements for to boot
DragonFlyBSD (128MB? 256MB?) but for the future development the developer
will have a 512MB VPS. If you need more please let me know.
The environment is a standard de facto in hosting industry. The boot manager
is pvgrub and it's very
providers and other types of hosting. Here you
need to control the distribution of resources (and cpu time) according
to type of client.
KVM is superior for other types of virtualization like the testing of
applications for developers.
RedHat likes being the boss and need to control the development
On Fri, May 13, 2011 at 8:45 PM, Matthew Dillon
dil...@apollo.backplane.com wrote:
:Siju,
:
:I NFS mount /usr/src and /usr/obj in the slow machine (being the NFS
:server the faster machine) and then I issue the usual
:installkernel/installworld/upgrade commands.
:
:Cheers,
:Antonio Huete
:Siju,
:
:I NFS mount /usr/src and /usr/obj in the slow machine (being the NFS
:server the faster machine) and then I issue the usual
:installkernel/installworld/upgrade commands.
:
:Cheers,
:Antonio Huete
I do the same thing. In fact, sometimes I even NFS-mount /usr/obj
across the
Hi,
I have a Backup Server on another Floor.
It runs on Qemu with the OS on a qcow2 Virtual Disk ( file ) and
Backup Data on Two Physical Disks.
It mirrors from Master PFSes on backup server on another floor. Also
It's own master PFSes are backed up by the slaves on the other one.
On Thu, May 12, 2011 at 2:23 PM, Siju George sgeorge...@gmail.com wrote:
Hi,
I have a Backup Server on another Floor.
It runs on Qemu with the OS on a qcow2 Virtual Disk ( file ) and
Backup Data on Two Physical Disks.
It mirrors from Master PFSes on backup server on another floor. Also
On Thu, May 12, 2011 at 12:09 PM, Sepherosa Ziehau sepher...@gmail.com wrote:
I usually buildworld on the fastest box around me then cpdup the
/usr/obj to the relative slow boxes. However, I still let slow boxes
compile their own kernels.
Kernel is alright :-)
Thanks
--Siju
Siju,
I NFS mount /usr/src and /usr/obj in the slow machine (being the NFS
server the faster machine) and then I issue the usual
installkernel/installworld/upgrade commands.
Cheers,
Antonio Huete
2011/5/12 Siju George sgeorge...@gmail.com:
On Thu, May 12, 2011 at 12:09 PM, Sepherosa Ziehau
:Hi Matt,
:
:Here is my janitoring item for tmpfs.
:I would really appreciate your effort to polish on tmpfs,
:Also I would do small pieces of janitors in parallel.
:
:The attachment is a patch to enable option -u, -g and -m as NetBSD
:does. We can mount with non root uid, gid or even with sticky
a very nice port by Naoya Sugioka of TMPFS from NetBSD
in our main development branch. It is brand new and still considered
experimental but should be reasonably stable.
TMPFS is a better alternative to MFS and MD for temporary filesystems.
It doesn't have the data duplication issue
We now have a very nice port by Naoya Sugioka of TMPFS from NetBSD
in our main development branch. It is brand new and still considered
experimental but should be reasonably stable.
TMPFS is a better alternative to MFS and MD for temporary filesystems.
It doesn't have
Hi! I want to know the status of AMD-64 platform development in
DragonFly BSD? Because I have gone to AMD web site at their developer
center section https://devcenter.amd.com/about/index.php that they are
offering AMD-64-based machines to be tested remotely over VPN
https://devcenter.amd.com/about
On Tue, July 22, 2008 2:59 am, Archimedes Gaviola wrote:
Hi! I want to know the status of AMD-64 platform development in
DragonFly BSD? Because I have gone to AMD web site at their developer
center section https://devcenter.amd.com/about/index.php that they are
offering AMD-64-based machines
Thanks Justin for this information. I will just wait for a release
once it is ready.
On 7/23/08, Justin C. Sherrill [EMAIL PROTECTED] wrote:
On Tue, July 22, 2008 2:59 am, Archimedes Gaviola wrote:
Hi! I want to know the status of AMD-64 platform development in
DragonFly BSD? Because I have
On Tue, Jan 15, 2008 at 11:06:21AM +0100, Matthias Schmidt wrote:
* Francois Tigeot wrote:
I recently upgraded a machine from Dragonfly 1.10.1 to a recent
1.11.0-DEVELOPMENT (as of today).
An Epson Perfection 1240U USB scanner which worked fine with 1.10.1 is now
unrecognized
Hasso Tepper wrote:
Francois Tigeot wrote:
However, I found out there's was a difference between a standalone
uscanner module and one compiled in the kernel.
Standalone module:
- original - nothing
- patched - nothing
Note that loading module doesn't rescan devices. You have
On Jan 16, 2008 8:14 PM, Simon 'corecode' Schubert
[EMAIL PROTECTED] wrote:
Hasso Tepper wrote:
Francois Tigeot wrote:
However, I found out there's was a difference between a standalone
uscanner module and one compiled in the kernel.
Standalone module:
- original - nothing
Sepherosa Ziehau wrote:
On Jan 16, 2008 8:14 PM, Simon 'corecode' Schubert
[EMAIL PROTECTED] wrote:
Hasso Tepper wrote:
Francois Tigeot wrote:
However, I found out there's was a difference between a standalone
uscanner module and one compiled in the kernel.
Standalone module:
- original
On Wed, Jan 16, 2008 at 12:45:49PM +0200, Hasso Tepper wrote:
Francois Tigeot wrote:
However, I found out there's was a difference between a standalone
uscanner module and one compiled in the kernel.
Standalone module:
- original - nothing
- patched - nothing
Note that
Hi,
I recently upgraded a machine from Dragonfly 1.10.1 to a recent
1.11.0-DEVELOPMENT (as of today).
An Epson Perfection 1240U USB scanner which worked fine with 1.10.1 is now
unrecognized. Pluging and unpluging the USB cord doesn't result in any
kernel message visible in dmesg.
I know the USB
On Tue, 15 Jan 2008 11:06:21 +0100
Matthias Schmidt [EMAIL PROTECTED] wrote:
I'm currently preparing a mass update of USB quirks
Sorry for the hijack - but could you include this one :)
Index: sys/bus/cam/scsi/scsi_da.c
* Steve O'Hara-Smith wrote:
It may help to know that I am running a recent 1.11.0 (Jan 12 or
thereabouts) which does recognise my Perfection 1240U and it works (quick
test, I haven't had to use it in a while).
Could you please post the dmesg output (if there is any :)?
On Tue, 15 Jan 2008 10:24:59 +0100
Francois Tigeot [EMAIL PROTECTED] wrote:
Hi,
I recently upgraded a machine from Dragonfly 1.10.1 to a recent
1.11.0-DEVELOPMENT (as of today).
An Epson Perfection 1240U USB scanner which worked fine with 1.10.1 is now
unrecognized. Pluging and unpluging
On Tue, 15 Jan 2008 15:02:33 +0100
Matthias Schmidt [EMAIL PROTECTED] wrote:
* Steve O'Hara-Smith wrote:
It may help to know that I am running a recent 1.11.0 (Jan 12 or
thereabouts) which does recognise my Perfection 1240U and it works
(quick test, I haven't had to use it in a
Simon corecode Schubert wrote:
However, there won't be any C++ in the list of things to do. The only thing
which uses C++ in DragonFly is groff, and I would be happier without this.
was just thinking about this issue - any thoughts about:
http://heirloom.sourceforge.net/doctools.html
, and it could blow something up, like a
filesystem, so this is a head's up that the development tree should
be considered unstable this week.
Eventually this will allow us to implement a pluggable disklabeling
scheme (e.g. a 64 bit disklabel or GPT or something like that). I'm
On Sun, May 13, 2007 8:00 am, km b wrote:
On 5/13/07, Simon corecode Schubert [EMAIL PROTECTED] wrote:
follow-fork-mode for gdb, or maybe even start/finish the amd64 port.
just wondering whether anybody has done any work on amd64 port earlier?
Matt had done some work before when he first
Thanks for the input everyone! Once I decide on what to tackle, I'll
solicit some help / advice from you guys. I think firstly, a C++ wrapper
for any DragonFly specific system libraries or system calls would be a
good thing. This would also facilitate easier contribution by other C++
developers.
Just my 2 cents...
While any new commiter is very valuable, I hardly can see any point in
any DFLY-specific C++ libs. Thats more of Linux way - creating
non-portable and OS-centric apps.
Even more, I can hardly remember any of DFLY-specific libraries in our OS.
What am I considering as a good
On 2007-05-13 17:31, Dennis Melentyev wrote:
2007/5/13, [EMAIL PROTECTED] [EMAIL PROTECTED]:
Thanks for the input everyone! Once I decide on what to tackle, I'll
solicit some help / advice from you guys. I think firstly, a C++ wrapper
for any DragonFly specific system libraries or system calls
:
:On Sun, May 13, 2007 8:00 am, km b wrote:
: On 5/13/07, Simon corecode Schubert [EMAIL PROTECTED] wrote:
: follow-fork-mode for gdb, or maybe even start/finish the amd64 port.
:
: just wondering whether anybody has done any work on amd64 port earlier?
:
:Matt had done some work before when he
On Sat, May 12, 2007 12:31 am, Influenza wrote:
Greetings all,
I would very much like to contribute to the DragonflyBSD project in
any way possible.
http://wiki.dragonflybsd.org/index.cgi/ProjectsPage
Getting DRM to work, or figuring out why splash screens don't work are
possible
Greetings all,
I would very much like to contribute to the DragonflyBSD project in any
way possible. I have excellent C++ skills and a strong knowledge base of
data structures. I know that UNIX prefers C code, but hopefully C++ can be
used somewhere. I also have a server (only up rarely, will
I am interested in taking part of DF development. I have pretty good
programming skils in C, C++ and Java.
I bought the book The design and Implementation of the FreeBSD
Operating System (I read that someone recommended that) and now I am
reading it. Unfortunately the book is so theoretical
Tero Mäntyvaara wrote:
I would like to have more practical documentation with example codes
like the hello world. What other documentation could I use to learn
programming for DF (web/printed)? I could not find any suitable
documentation on wiki for me.
Uh. basically reading the code :)
I installed the development snapshot dated 12/30/06 and also a full kde
install from the development binaries. No issues. AMD 3000.
Video, audio, scsi, network, etc.. all working. I'll wipe and reinstall the
system again doing a buildworld, buildkernel, source kde install and post
when
On Fri, Aug 05, 2005 at 05:42:52PM +0100, Hiten Pandya wrote:
What about time related fields, are they currently 64-bits wide?
Nope and quite frankly, I hope that IA32 is dead when this becomes a
problem. When we add support for other 32bit platforms, we can think
about making them 64bit, but I
RELEASE and DEVELOPMENT,
we have decided that we are NOT going to be bumping the library major
revs again, let alone three times.
This means that both the recent work in DEVELOPMENT/HEAD and shortly
upcoming work will require a full recompile of everything... world,
plus any
50 matches
Mail list logo
