headers
rmkml | 4 Aug 2006 20:02
Picon
Favicon

kernel panic on default cdrom boot dragonflybsd v1.6.0

Hi,
on my hardware (dual core amd64x2),
if I start with cdrom dragonfly v1.6.0 [boot default]
kernel panic :
  ...
  ad0: READ command timeout tag=0 serv=0 - resetting
  ata0: resetting devices .. instruction pointer = 0x8:0xc018c06c
  stack pointer = 0x10:0xc22bfcc8
  frame pointer = 0x10:0xc22bfd14
  code segment  = base 0x0, limit 0xfffff, type 0x1b
                = DPL 0, pres 1, def32 1, gran 1
  processor eflags = interrupt enabled, IOPL = 0
  current process = idle
  current thread = pri 14
  kernel: type 30 trap, code=0
  stopped at ata_reset+0x31: jmp ata_reset+0x36
  db>
anyone help me ? (but keyboard is locked)
hardware conf: amd x2, ide 180Go
boot and install on netbsd3/freebsd61/openbsd39 without pb
same old pb dfly144 : 
http://www.mail-archive.com/kernel <at> crater.dragonflybsd.org/msg01241.html
Regards
Rmkml
Permalink | Reply | 0 comments |
headers
Petr Janda | 6 Aug 2006 19:09
Picon

Just some information

Hi devs and thanks for all the good work,

I've been wondering what the devs are up to at the moment and in the 
near future, just out of sheer curiosity to prepare for whats coming :) 
I can't wait to start testing userland vfs and all the features planned 
for the next release, so please inform me! :)

Cheers,
Again, thanks much for this OS.

Petr
Permalink | Reply | 1 comment |
headers
Matthew Dillon | 6 Aug 2006 21:02

Re: Just some information


:Hi devs and thanks for all the good work,
:
:I've been wondering what the devs are up to at the moment and in the 
:near future, just out of sheer curiosity to prepare for whats coming :) 
:I can't wait to start testing userland vfs and all the features planned 
:for the next release, so please inform me! :)
:
:Cheers,
:Again, thanks much for this OS.
:
:Petr

    Well, I'm focused on getting the syslink protocol written and
    integrated into the system.  It is the transport protocol which
    will be used for userland VFS and clustering and many other things.

					-Matt
					Matthew Dillon 
					<dillon <at> backplane.com>
Permalink | Reply | 0 comments |
headers
Csaba Henk | 7 Aug 2006 01:09
Picon

VOP_RENAME of the future

Hi,

VOP_RENAME is a notorious beast, and, IIRC, Matt (and maybe others) has
claimed that it should be tamed. I wonder what are we to expect here...

As I see, the main issues are the following:

1) Many things has to be locked at the same time.
2) It should be checked if the target dir is not under the source dir 
   in the fs tree.
3) It's hard to ensure consistency (eg. preserving validity of the check
   in 2)) when other topology modifying events (typically, another rename)
   can occur during the rename.

The idealistic thing would be an effective treatment of these at the VFS
level, such that an fs implementer shouldn't care about these things at
all, still everything would be just fine.

See how it's tackled in the various open Unices.

Linux goes for the nice API and gets it via a blunt solution: the Linux
VFS does take care about 1)-3). For 3), they just have a per-vfs rename
lock which ensures that only one rename can run at a time.

Based on remarks in the OpenSolaris code, Solaris 9 used to do this,
too.

Sol 10 and the BSDs choose a more fine-grained scheme, but the work has
to be done for each particular VFS. However, my impression is that the
SUN guys have actually took the effort to do it carefully enough, while
(Continue reading)

Permalink | Reply | 9 comments |
headers
Matthew Dillon | 7 Aug 2006 07:11

Re: VOP_RENAME of the future


:to be done for each particular VFS. However, my impression is that the
:SUN guys have actually took the effort to do it carefully enough, while
:the BSDs just let the old hacky 4.4 BSD code rot further peacefully. At
:least, all four of them has the lines
:
:        if ((error = vn_lock(fvp, LK_EXCLUSIVE)) != 0)
:	        goto abortit;

    That's pretty much how the BSD's do it, because the old filesystems
    like UFS require an atomic LOOKUP + OP (e.g. LOOKUP + CREATE,
    LOOKUP + REMOVE) combination.  UFS stores side effects from the LOOKUP
    which are then used in the later CREATE/REMOVE/RENAME/SYMLINK/MKNOD/RMDIR,
    etc.  The vnode must remain locked through both operations.

:in their ufs_rename() -- ie., let's treat issue 1) naively, if it fails,
:well... goddam the bloody thing -- which doesn't seem to be too much a
:product of a well-tought-out design. (All these are really just my
:impressions after a quick run-through of the code, take these judgements
:with a piece of salt please. It's not intended to be a flame bait.)
:
:In particular, how DragonFly looks like?
:
:1) has been partially solved, because namecache locking is taken care by
:the VFS layer. However, vnode-level locking still has do be done by the
:particular file systems (and it suffers from issues like the presence
:of the above two lines). I wonder if updating the filesystems so that
:they will directly use the namecache API will automagically solve this,
:or there is still some hard work to be done at the VFS level...
(Continue reading)

Permalink | Reply | 8 comments |
headers
Karthik Subramanian | 7 Aug 2006 08:53
Picon

Any way to get DragonFly sources other than CVSup/CVSync?

Hi Folks,

Till recently I was using CVSup to sync my DF source tree.

I've been firewalled at work, and am not able to use CVSup anymore.
CVSync neither.

Is there any other way I can get hold of DF sources?

Thanks,
Karthik.

--

-- 
There are things known and things unknown, in between lie the Doors
Permalink | Reply | 4 comments |
headers
Erik Wikström | 7 Aug 2006 09:24
Picon

Re: Any way to get DragonFly sources other than CVSup/CVSync?

On 2006-08-07 08:53, Karthik Subramanian wrote:
> Hi Folks,
> 
> Till recently I was using CVSup to sync my DF source tree.
> 
> I've been firewalled at work, and am not able to use CVSup anymore.
> CVSync neither.
> 
> Is there any other way I can get hold of DF sources?
> 
> Thanks,
> Karthik.
> 

Some of the mirrors offers rsync too, check out the download page: 
http://www.dragonflybsd.org/community/download.cgi

--
Erik Wikström
Permalink | Reply | 0 comments |
headers
Sascha Wildner | 7 Aug 2006 09:26
Picon

Re: Any way to get DragonFly sources other than CVSup/CVSync?

Karthik Subramanian wrote:
> Hi Folks,
> 
> Till recently I was using CVSup to sync my DF source tree.
> 
> I've been firewalled at work, and am not able to use CVSup anymore.
> CVSync neither.
> 
> Is there any other way I can get hold of DF sources?

Check out http://chlamydia.fs.ei.tum.de/pub/DragonFly/snapshots/src/

Sascha

--

-- 
http://yoyodyne.ath.cx
Permalink | Reply | 1 comment |
headers
Karthik Subramanian | 7 Aug 2006 10:41
Picon

Re: Any way to get DragonFly sources other than CVSup/CVSync?

Thanks a lot, guys!

Also discovered that plain vanilla CVS works within my firewall. It's
a little more painful than using CVSup, but well - it works :)

Thanks again,
K.

On 8/7/06, Sascha Wildner <saw <at> online.de> wrote:
> Karthik Subramanian wrote:
> > Hi Folks,
> >
> > Till recently I was using CVSup to sync my DF source tree.
> >
> > I've been firewalled at work, and am not able to use CVSup anymore.
> > CVSync neither.
> >
> > Is there any other way I can get hold of DF sources?
>
> Check out http://chlamydia.fs.ei.tum.de/pub/DragonFly/snapshots/src/
>
> Sascha
>
> --
> http://yoyodyne.ath.cx
>

--

-- 
There are things known and things unknown, in between lie the Doors
(Continue reading)

Permalink | Reply | 0 comments |
headers
Csaba Henk | 7 Aug 2006 17:11
Picon

Re: VOP_RENAME of the future

On 2006-08-07, Matthew Dillon <dillon <at> apollo.backplane.com> wrote:
>:
>:        if ((error = vn_lock(fvp, LK_EXCLUSIVE)) != 0)
>:	        goto abortit;
>
>     That's pretty much how the BSD's do it, because the old filesystems
>     like UFS require an atomic LOOKUP + OP (e.g. LOOKUP + CREATE,
>     LOOKUP + REMOVE) combination.  UFS stores side effects from the LOOKUP
>     which are then used in the later CREATE/REMOVE/RENAME/SYMLINK/MKNOD/RMDIR,
>     etc.  The vnode must remain locked through both operations.

Well, it's OK that fvp has to be locked, but giving up when the first
lock attempt fails looks poor to me. Isn't it just gambling that someone
else won't take the lock between entering ufs_rename() and trying to
lock fvp?

Or you mean that the locking patterns used by ufs/BSD VFS implies that
there is no safety here?

>     I am not intending to do any more work on UFS then I have to.  Any

Understandable...

>     *NEW* VFS ports can just use the new VOP_N*() calls and not implement
>     the old junk at all.
>
>     As part of the clustering and userland VFS work I may remove the high
>     level vnode locking requirements for nearly all the VOP ops, but all
>     that means is that most of the filesystems (e.g. UFS) would have to do
>     the locking internally, themselves.  It isn't really removing any
(Continue reading)

Permalink | Reply | 7 comments |

Gmane