SGI XFS on ppc

SGI XFS on ppc

[Thomas Graichen]

[this mal goes to two mailinglists: the sgi xfs list and the ppc-dev
list because i think i concerns both groups - so keep that in mind
for your replys]

i was a bit curious about how hard/easy it would be to get xfs working
on non intel machines - and this is what i found out about it so far ...

first the results till now:

[root@aqua /root]# uname -a
Linux aqua 2.4.0-test1 #11 Mon Jul 31 01:02:00 CEST 2000 ppc unknown
[root@aqua /root]# cat /proc/filesystems
nodev	shm
nodev	pipefs
nodev	proc
	ext2
	msdos
	vfat
	iso9660
	hfs
nodev	autofs
	xfs
nodev	nfs
nodev	devpts
[root@aqua /root]#

so - i got the kernel compiled with xfs support - it even runs
stable but it hangs on the try to mount and xfs filesystem :-(

ok - now some more details about my tries to get it at least built
and some questions ...

* tried to compile it brute force and looked at the errors
* the typo in arch/ppc/kernel/misc.c was easily fixed
* first thing in the pagebuf code was that at the ppc the local_bh_count
  seems to be defined in softirq.h instead of hardirq.h at the x86 - i
  just added softirq.h to page_buf.c (i think the ppc-dev people
  should have a look at how to fix this in a clean way)
* kernel now compiled fine but did not link due to unclear ifdefs
  for the kallsyms stuff (this should be propagated back to
  whom ever is maintaining the kallsyms stuff)
* kernel still did not link due to missing kernel support for
  some integer functions in the kernel (udivdi3 etc.)
* looks like sgi added support for this to arch/i386/lib via the
  file divdi3.c - so i did for arch/ppc/lib by copying the divdi3.c
  over from the i386 dir and replacing the asm's with the ppc
  asm's from gcc-2.95.2's longlong.h (question to the ppc-dev
  people: is that done correctly or does there some code for
  udiv_qrnnd or sdiv_qrnnd (would result in a simpler udiv_qrnnd
  than the one used) exist ? - for more details look at the
  gcc/longlong.h file)
* kernel linked now!
* building the tools is a problem due to too deep dependencies of
  them currently to the system headers - but sgi people are
  working on it to make them compilable without a lot of problems
  (right ?)
* kernel boots! and runs stable so far
* how to test the xfs filesystem without the tools? - i just made
  a small 32mb xfs filesystem on an x86 and dd'ed to a file which
  you can easily dd onto any partition and mount it as xfs fs there
  (verified to work on x86)
* trying to mount the dd'ed filesystem just hangs the machine - no
  output so far (xfs is compiled with debug and vnode tracing and
  syslog will give *.* to the console) ...

so - what next? - for me to go to bed now (it's half past two over
now :-) but i hope i have delivered enough info for others to jump
onto it and get this thing going - i am happy to test new and other
things if someone from the two camps (sgi or ppc-dev) have an idea
but so far i am at the end of my knowledge here :-(

all the diffs, configs, logs etc. i used for my tests can be found at

  http://innominate.org/~graichen/projects/xfs-ppc/

t

--
thomas.graichen@innominate.de
technical director                                       innominate AG
clustering & security                                networking people
fon: +49.30.308806-13 fax: -77 web: http://innominate.de pgp: /pgp/tgr

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: SGI XFS on ppc

[Keith Owens]

On 31 Jul 2000 00:33:57 GMT,
Thomas Graichen <news-innominate.list.linux.ppc.dev@innominate.denews-innominate.list.sgi.xfs@innominate.de> wrote:
>i was a bit curious about how hard/easy it would be to get xfs working
>on non intel machines - and this is what i found out about it so far ...
>* first thing in the pagebuf code was that at the ppc the local_bh_count
>  seems to be defined in softirq.h instead of hardirq.h at the x86 - i
>  just added softirq.h to page_buf.c (i think the ppc-dev people
>  should have a look at how to fix this in a clean way)

Linus wants softirq, local_irq_count, local_bh_count plus arch specific
per-cpu counts merged into a single structure which is used on all
systems.  I am doing the patch for this and will be mailing it to
various arch lists later today.

>* kernel now compiled fine but did not link due to unclear ifdefs
>  for the kallsyms stuff (this should be propagated back to
>  whom ever is maintaining the kallsyms stuff)

More specific please.  kallsyms has no ifdefs.  It should only be
included if you select kdb but kdb has not been ported to ppc.  I
maintain modutils, kallsyms and kdb.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: SGI XFS on ppc

[Dan Malek]

Keith Owens wrote:

> .....  It should only be
> included if you select kdb but kdb has not been ported to ppc.  I
> maintain modutils, kallsyms and kdb.


Ummm...I use kgdb and xmon on ppc, at least the ones with serial
ports.  Is there yet another debugger for the kernel?


	-- Dan

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: SGI XFS on ppc

[Keith Owens]

On Sun, 30 Jul 2000 21:20:38 -0400,
Dan Malek <dan@netx4.com> wrote:
>Keith Owens wrote:
>
>> .....  It should only be
>> included if you select kdb but kdb has not been ported to ppc.  I
>> maintain modutils, kallsyms and kdb.
>
>
>Ummm...I use kgdb and xmon on ppc, at least the ones with serial
>ports.  Is there yet another debugger for the kernel?

kgdb uses the remote gdb interface to debug the kernel and is very
useful provided the kernel is actually running.  The problem with
remote gdb is that it needs some support from the remote kernel for
things like page I/O.  If the cpu gets into a spin loop when interrupts
are disabled then you cannot access gdb to debug it.  Also things like
single step do not work work when interrupts are disabled.  However gdb
is very useful for debugging the higher layers of the kernel.

kdb is a really low level debugger, it can be used in interrupts and
has hooks to detects runaway spin loops and drop into the debugger.  It
requires no kernel support, it accesses the I/O hardware itself.  The
downside of kdb is you do not get the nice symbol printing that gdb can
do.  kdb knows where all the symbols are and can convert addresses to
symbols and offsets, but it cannot do source line listing nor do pretty
prints of structures.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: SGI XFS on ppc

[Dan Malek]

Keith Owens wrote:

> kdb is a really low level debugger,

This sounds like xmon....I guess I'll wait for Paul to reply and
tell me it is the same thing :-).


	-- Dan

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

SGI XFS on ppc

[Thomas Graichen]

[looks like this mail didn't make it into this list (if i am wrong
sorry for the resend) - please add linux-xfs@oss.sgi.com to the
cc list if useful]

i was a bit curious about how hard/easy it would be to get xfs working
on non intel machines - and this is what i found out about it so far ...

first the results till now:

[root@aqua /root]# uname -a
Linux aqua 2.4.0-test1 #11 Mon Jul 31 01:02:00 CEST 2000 ppc unknown
[root@aqua /root]# cat /proc/filesystems
nodev	shm
nodev	pipefs
nodev	proc
	ext2
	msdos
	vfat
	iso9660
	hfs
nodev	autofs
	xfs
nodev	nfs
nodev	devpts
[root@aqua /root]#

so - i got the kernel compiled with xfs support - it even runs
stable but it hangs on the try to mount and xfs filesystem :-(

ok - now some more details about my tries to get it at least built
and some questions ...

* tried to compile it brute force and looked at the errors
* the typo in arch/ppc/kernel/misc.c was easily fixed
* first thing in the pagebuf code was that at the ppc the local_bh_count
  seems to be defined in softirq.h instead of hardirq.h at the x86 - i
  just added softirq.h to page_buf.c (i think the ppc-dev people
  should have a look at how to fix this in a clean way)
* kernel now compiled fine but did not link due to unclear ifdefs
  for the kallsyms stuff (this should be propagated back to
  whom ever is maintaining the kallsyms stuff)
* kernel still did not link due to missing kernel support for
  some integer functions in the kernel (udivdi3 etc.)
* looks like sgi added support for this to arch/i386/lib via the
  file divdi3.c - so i did for arch/ppc/lib by copying the divdi3.c
  over from the i386 dir and replacing the asm's with the ppc
  asm's from gcc-2.95.2's longlong.h (question to the ppc-dev
  people: is that done correctly or does there some code for
  udiv_qrnnd or sdiv_qrnnd (would result in a simpler udiv_qrnnd
  than the one used) exist ? - for more details look at the
  gcc/longlong.h file)
* kernel linked now!
* building the tools is a problem due to too deep dependencies of
  them currently to the system headers - but sgi people are
  working on it to make them compilable without a lot of problems
  (right ?)
* kernel boots! and runs stable so far
* how to test the xfs filesystem without the tools? - i just made
  a small 32mb xfs filesystem on an x86 and dd'ed to a file which
  you can easily dd onto any partition and mount it as xfs fs there
  (verified to work on x86)
* trying to mount the dd'ed filesystem just hangs the machine - no
  output so far (xfs is compiled with debug and vnode tracing and
  syslog will give *.* to the console) ...

so - what next? - for me to go to bed now (it's half past two over
now :-) but i hope i have delivered enough info for others to jump
onto it and get this thing going - i am happy to test new and other
things if someone from the two camps (sgi or ppc-dev) have an idea
but so far i am at the end of my knowledge here :-(

all the diffs, configs, logs etc. i used for my tests can be found at

  http://innominate.org/~graichen/projects/xfs-ppc/

t

--
thomas.graichen@innominate.de
technical director                                       innominate AG
clustering & security                                networking people
fon: +49.30.308806-13 fax: -77 web: http://innominate.de pgp: /pgp/tgr

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: SGI XFS on ppc

[Keith Owens]

On 31 Jul 2000 06:12:29 GMT,
Thomas Graichen <news-innominate.list.sgi.xfs@innominate.de> wrote:
>Keith Owens <kaos@ocs.com.au> wrote:
>> More specific please.  kallsyms has no ifdefs.  It should only be
>> included if you select kdb but kdb has not been ported to ppc.  I
>> maintain modutils, kallsyms and kdb.
>
>just have a look at the diff at
>
>  http://innominate.org/~graichen/projects/xfs-ppc/

I can see the problem but need some ppc help in fixing it.  Part of the
kallsyms patch updates arch/xxx/vmlinux.lds on every arch.  I did not
patch arch/ppc/vmlinux.lds because it did not have any entries for
section __ksymtab.  kallsyms is module related and the absence of
__ksymtab in arch/ppc/vmlinux.lds made me think that ppc does not use
modules.

Does ppc support modules?  I know that modutils has an obj-ppc.c file
but I don't think I have ever seen any ppc bug reports for modutils.
If ppc does use modutils then we need lines like this in
arch/ppc/vmlinux.lds.

  __start___ksymtab = .;        /* Kernel symbol table */
  __ksymtab : { *(__ksymtab) }
  __stop___ksymtab = .;

  __start___kallsyms = .;       /* All kernel symbols */
  __kallsyms : { *(__kallsyms) }
  __stop___kallsyms = .;

The first section is standard for any arch that supports modules but is
not in pppc for some reason.  The second section is part of kallsyms.
Most of the kallsyms code needs to be wrapped in #ifdef but
arch/xxx/vmlinux.lds, include/modules.h and kernel/module.c do not,
they are global to provide a standard userspace ABI, independent of
kernel options.

If ppc does not support modules then forget the above update.  However
the code in kernel/module.c that refers to kallsyms entries should not
be compiled when CONFIG_MODULES=n is set, why is it being compiled?


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: SGI XFS on ppc

[Thomas Graichen]

On Mon, 31 Jul 2000, Keith Owens wrote:

> Does ppc support modules?  I know that modutils has an obj-ppc.c file
> but I don't think I have ever seen any ppc bug reports for modutils.
> If ppc does use modutils then we need lines like this in
> arch/ppc/vmlinux.lds.
>
>   __start___ksymtab = .;        /* Kernel symbol table */
>   __ksymtab : { *(__ksymtab) }
>   __stop___ksymtab = .;
>
>   __start___kallsyms = .;       /* All kernel symbols */
>   __kallsyms : { *(__kallsyms) }
>   __stop___kallsyms = .;
>
> The first section is standard for any arch that supports modules but is
> not in pppc for some reason.  The second section is part of kallsyms.
> Most of the kallsyms code needs to be wrapped in #ifdef but
> arch/xxx/vmlinux.lds, include/modules.h and kernel/module.c do not,
> they are global to provide a standard userspace ABI, independent of
> kernel options.

i think this is something for the ppc guys ...

> If ppc does not support modules then forget the above update.  However
> the code in kernel/module.c that refers to kallsyms entries should not
> be compiled when CONFIG_MODULES=n is set, why is it being compiled?

maybe due to the "||" (kernel/modules.c) ?

#if defined(CONFIG_MODULES) || defined(CONFIG_KALLSYMS)

t

--
thomas.graichen@innominate.de
technical director                                       innominate AG
clustering & security                                networking people
fon: +49.30.308806-13 fax: -77 web: http://innominate.de pgp: /pgp/tgr


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: SGI XFS on ppc

[Michel Dänzer]

Keith Owens wrote:

> Does ppc support modules?

Yes.


> I know that modutils has an obj-ppc.c file but I don't think I have ever
> seen any ppc bug reports for modutils.

Maybe because it works fine? :)


> If ppc does use modutils then we need lines like this in
> arch/ppc/vmlinux.lds.

Can't comment on this.


Michel


--
Apologies are so hard to give. Would you accept some potatoes instead?
______________________________________________________________________________
Earthling Michel Dänzer (MrCooper)  \  CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \   member of XFree86, Team *AMIGA*, AUGS

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: SGI XFS on ppc

[Geert Uytterhoeven]

On 31 Jul 2000, Thomas Graichen wrote:
> * how to test the xfs filesystem without the tools? - i just made
>   a small 32mb xfs filesystem on an x86 and dd'ed to a file which
>   you can easily dd onto any partition and mount it as xfs fs there
>   (verified to work on x86)
> * trying to mount the dd'ed filesystem just hangs the machine - no
>   output so far (xfs is compiled with debug and vnode tracing and
>   syslog will give *.* to the console) ...

Is XFS now always big endian (as we discussed about at Linux-Kongreß 1999),
or is it still native endian, so you cannot use an x86 image on big endian
machines?

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: SGI XFS on ppc

[Steve Lord]

> On 31 Jul 2000, Thomas Graichen wrote:
> > * how to test the xfs filesystem without the tools? - i just made
> >   a small 32mb xfs filesystem on an x86 and dd'ed to a file which
> >   you can easily dd onto any partition and mount it as xfs fs there
> >   (verified to work on x86)
> > * trying to mount the dd'ed filesystem just hangs the machine - no
> >   output so far (xfs is compiled with debug and vnode tracing and
> >   syslog will give *.* to the console) ...
> =

> Is XFS now always big endian (as we discussed about at Linux-Kongre=DF =
1999),
> or is it still native endian, so you cannot use an x86 image on big end=
ian
> machines?
> =

> Gr{oetje,eeting}s,
> =

> 						Geert
> =



XFS is now always bigendian - it should be possible to move a disk image
between systems. =


As for debugging this hang - it is a little tricky without something like=

kdb. Getting a stack trace for the mount process would be critical to wor=
king
out what went wrong. I suspect some read of a block from disk did not wak=
e
up the requesting thread. There is tracing in the pagebuf module, but it
relied on kdb to dump the results, mapping these trace calls onto printk
messages, or some other mechanism may help.

Steve


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/