9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: "Eric Van Hensbergen" <ericvh@gmail.com>
To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu>
Subject: Re: [9fans] Question about v9fs on Gentoo
Date: Thu, 22 Feb 2007 13:57:22 -0600	[thread overview]
Message-ID: <a4e6962a0702221157j4720ed53je0c017efaff554b4@mail.gmail.com> (raw)
In-Reply-To: <45DDEEAB.9050708@tecmav.com>

On 2/22/07, Adriano Verardo <a.verardo@tecmav.com> wrote:
> Eric Van Hensbergen wrote:
>
> > On 2/22/07, Adriano Verardo <a.verardo@tecmav.com> wrote:
> >
> >> ron minnich wrote:
> >>
> >> Sorry, I was saying ...
> >>
> >> I tried both "9p" and "9P".
> >>
> >> I don't know whether or not there is a specialized mount utils,
> >> as in FreeBSD.
> >>
> >> If not, IMHO, mount should recognize the available fs from /proc.
> >> 9p is not listed in /proc/filesystem, also when statically linked in the
> >> kernel. I think It should be.
> >>
> >
> > If there is no 9p, 9p2000, or 9P in /proc/filesystems, there is
> > something wrong with the way you have built your kernel or kernel
> > module.
> I see.
> When you compile it as a module and than insmod it, do you
> > see anything funny in /var/log/messages or dmesg?
>
>
> I tried all possible ways to configure 9p.
>
> Loadable module: 9p is in the lsmod output.
> In-Kernel: in /var/log/dmesg I see "Activated 9P2000 ..."
>
> In any case:
> - no reference in /proc/filesystem
> - mount -t 9p 127.0.0.1 /mnt -o debug=0xf
>      -> Unknown file system type '9p'
>

Just realized there was a bug I fixed a while back "9p: fix bogus
return code checks during initialization" which is probably causing
your problem.

It went in Jan 26th, 2007, which would have been well after 2.6.19 was out.
If its easy, upgrade to 2.6.20 and the problem should go away, if that
isn't easy, backport just the fs/9p from 2.6.20 to 2.6.19.  This was
my bad -- there was a period between 2.6.17 and 2.6.20 where I didn't
do a good job regressing stuff, and some bogus return-code checks
slipped in which screw up initialization.

         -eric


  reply	other threads:[~2007-02-22 19:57 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-22 17:46 Adriano Verardo
2007-02-22 17:52 ` Latchesar Ionkov
2007-02-22 18:07   ` Adriano Verardo
2007-02-22 17:52 ` ron minnich
2007-02-22 18:14   ` Adriano Verardo
2007-02-22 19:13     ` ron minnich
2007-02-22 19:14     ` Eric Van Hensbergen
2007-02-22 19:27       ` Adriano Verardo
2007-02-22 19:57         ` Eric Van Hensbergen [this message]
2007-02-22 18:28   ` erik quanstrom
2007-02-22 17:59 ` Eric Van Hensbergen
2007-02-22 18:16   ` Adriano Verardo
2007-02-22 18:39     ` Eric Van Hensbergen
2007-02-22 18:36 Adriano Verardo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a4e6962a0702221157j4720ed53je0c017efaff554b4@mail.gmail.com \
    --to=ericvh@gmail.com \
    --cc=9fans@cse.psu.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).