linux-apus-devel

Re: affs

[Ken T. <ke...@we...>]

On Thu, 27 Jul 2000, Roman Zippel wrote:

> Which signal.c? I see no asm construct in my signal.c at line 921.

Line 921 is '}', was just posting what the compiler reported.

What compiler do you use ? 

Ken.

Re: affs

[Geert U. <ge...@li...>]

On Wed, 26 Jul 2000, Roman Zippel wrote:
> > AFFS, the guy (Dave Jones) has it running in 2.3, I assume the changes in
> > 'our' 2.3 are the latest.
> 
> Yes, they are and I just commited some more changes, but there is still a 
> bit to do. OFS is probably still completly broken and FFS writes stop
> somewhere at 4.5MB (the extended block caching is broken).
> It would be great if someone could test the current stuff a bit, but
> please do any tests only on a seperate partition or only with a backup. I

Or on a loopback device.

> don't have disksalv or something like that, so I can't really test if the
> fs structure is still consistent.

It would be nice if someone would write an affsck and mkaffs. A full affsck
that does repairs is probably asked to much for now (given that even a working
affs seems difficult). But an affsck that checks the consistency only is IMHO
something that the guy who wants to fix affs needs anyway.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

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

Re: affs

[Roman Z. <zi...@fh...>]

Hi,

> It would be nice if someone would write an affsck and mkaffs. A full affsck
> that does repairs is probably asked to much for now (given that even a working
> affs seems difficult). But an affsck that checks the consistency only is IMHO
> something that the guy who wants to fix affs needs anyway.

mkaffs should be easy and a simple affsck should be possible, too. The
problem in the kernel is that it uses some tricks to reduce the memory
usage, what you don't need to do in user space. Hmm, maybe I give it a try
over the weekend...

bye, Roman

Re: affs

[Frank P. <fp...@zu...>]

On Wed, Jul 26, 2000 at 06:50:29PM +0200, Roman Zippel wrote:
> Hi,
> 
> > AFFS, the guy (Dave Jones) has it running in 2.3, I assume the changes in
> > 'our' 2.3 are the latest.
> 
> Yes, they are and I just commited some more changes, but there is still a 
> bit to do. OFS is probably still completly broken and FFS writes stop
> somewhere at 4.5MB (the extended block caching is broken).
> It would be great if someone could test the current stuff a bit, but
> please do any tests only on a seperate partition or only with a backup. I
> don't have disksalv or something like that, so I can't really test if the
> fs structure is still consistent.

Mounting AFFS rw works now. I have written something to an AFFS partition,
but not verified, yet.

Could somebody please close the bug on sourceforge?
-- 
Frank Petzold, IBM Zurich Research Laboratory, Säumerstrasse 4,
CH-8803 Rüschlikon/Switzerland, Tel.  +41-1-724-84-42  Fax.   +41-1-724-89-56
 Business email: fp...@zu...          Private email: pe...@he...
   The opinions expressed here are mine and not necessarily those of IBM.

2.4.0-test4 success (Re: affs)

[Michel <dae...@st...>]

Frank Petzold wrote:

> > > AFFS, the guy (Dave Jones) has it running in 2.3, I assume the changes
> > > in 'our' 2.3 are the latest.
> >
> > Yes, they are and I just commited some more changes, but there is still a
> > bit to do. OFS is probably still completly broken and FFS writes stop
> > somewhere at 4.5MB (the extended block caching is broken).
> > It would be great if someone could test the current stuff a bit, but
> > please do any tests only on a seperate partition or only with a backup. I
> > don't have disksalv or something like that, so I can't really test if the
> > fs structure is still consistent.
> 
> Mounting AFFS rw works now. I have written something to an AFFS partition,
> but not verified, yet.

I have written and verified several files now, including an almost 2 meg
kernel image. No problems so far. Even the problems when overwriting big files
seem to be gone in 2.4 as well :)


The strange behaviour I experienced seems to be due to debug=mem! Removing
that one made it boot. Any idea what broke that?


However, pm2fb only works with an old boothack (I use 990106). With the latest
one, dmesg output starts like this:

parse_bootinfo: unknown tag 0x8008 ignored
parse_bootinfo: unknown tag 0x8009 ignored

I take it 2.4 isn't adapted to the latest boothack yet.

Also, with the latest boothack, these lines appear:

nhandled interrupt 18, disabled
amiga_disable_irq: Trying to disable auto-vector IRQ 0
Unhandled interrupt 18, disabled

The last one is then repeated from time to time.


And also this line caught my eye:

amiga_insert_irq: Warning: dev_id of fb vertb handler is zero

it appears with both boothacks, before amifb is initialized. I attach
/proc/interrupts, hoping it's helpful.


Otherwise everything seems to be working fine, which is exciting!


Michel


PS: I can still hang the machine with 'cat /proc/iomem' ...

-- 
Here I am! Now what are your other two wishes?
______________________________________________________________________________
Earthling Michel Dänzer (MrCooper)  \  CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \   member of XFree86, Team *AMIGA*, AUGS

Re: 2.4.0-test4 success (Re: affs)

[Roman Z. <zi...@fh...>]

Hi,

> The strange behaviour I experienced seems to be due to debug=mem! Removing
> that one made it boot. Any idea what broke that?

Hmm, I'm almost sure I did use it once, have to check that...

> However, pm2fb only works with an old boothack (I use 990106). With the latest
> one, dmesg output starts like this:
> 
> parse_bootinfo: unknown tag 0x8008 ignored
> parse_bootinfo: unknown tag 0x8009 ignored
> 
> I take it 2.4 isn't adapted to the latest boothack yet.

Porting the changes from 2.2 shouldn't be difficult. :-)

> nhandled interrupt 18, disabled
> amiga_disable_irq: Trying to disable auto-vector IRQ 0
> Unhandled interrupt 18, disabled
> 
> The last one is then repeated from time to time.

That's the parallel port, I have no idea what should go wrong there, but I
also have nothing connected there, so I can't test it.

> And also this line caught my eye:
> 
> amiga_insert_irq: Warning: dev_id of fb vertb handler is zero

Nothing serious, except you want to use it as module, but I'll fix it.

bye, Roman

Re: 2.4.0-test4 success (Re: affs)

[Michel <dae...@st...>]

Roman Zippel wrote:

> > parse_bootinfo: unknown tag 0x8008 ignored
> > parse_bootinfo: unknown tag 0x8009 ignored
> >
> > I take it 2.4 isn't adapted to the latest boothack yet.
> 
> Porting the changes from 2.2 shouldn't be difficult. :-)

Yep, the biggest difficulty for me being the lack of time :(


> > amiga_insert_irq: Warning: dev_id of fb vertb handler is zero
> 
> Nothing serious, except you want to use it as module, but I'll fix it.

Thanks a lot for your great work Roman!


What about /proc/iomem?


This success has changed my mind wrt 2.2.16 btw, I think everyone should now
concentrate on 2.4! People who have written drivers for 2.2 please port them
to the current kernel, and let's get out a test kernel for the "masses" ASAP!


I wish everyone a nice weekend,

Michel


PS: More bugs I forgot to mention ;)

The Z2 RAM module is missing the symbols Ken added to the 2.2 tree lately.

'make modules_install' tries to install dmasound.o (which doesn't exist
anymore) instead of dmasound_paula.o and dmasound_core.o

That's (hopefully) all for now folks...

-- 
Here I am! Now what are your other two wishes?
______________________________________________________________________________
Earthling Michel Dänzer (MrCooper)  \  CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \   member of XFree86, Team *AMIGA*, AUGS

bogus dmasound.o module (was: Re: 2.4.0-test4 success (Re: affs))

[Geert U. <ge...@li...>]

On Fri, 28 Jul 2000, Michel [iso-8859-1] Dänzer wrote:
> 'make modules_install' tries to install dmasound.o (which doesn't exist
> anymore) instead of dmasound_paula.o and dmasound_core.o

Does this help? IIRC, I have it in my tree since a while, but I forgot about
it.

--- linux-2.4.0-test5/drivers/sound/Makefile.orig	Tue Jul 18 14:09:03 2000
+++ linux-2.4.0-test5/drivers/sound/Makefile	Sat Jul 29 14:37:01 2000
@@ -92,11 +92,11 @@
 
 ifeq ($(CONFIG_DMASOUND),y)
   SUB_DIRS += dmasound
-  MOD_SUB_DIRS += dmasound
+  MOD_IN_SUB_DIRS += dmasound
   obj-y += dmasound/dmasound.o
 else
   ifeq ($(CONFIG_DMASOUND),m)
-    MOD_SUB_DIRS += dmasound
+    MOD_IN_SUB_DIRS += dmasound
   endif
 endif
 

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

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

Re: 2.4.0-test4 success (Re: affs)

[Geert U. <ge...@li...>]

On Fri, 28 Jul 2000, Michel [iso-8859-1] Dänzer wrote:
> PS: I can still hang the machine with 'cat /proc/iomem' ...

That's something which must not happen. All it does is walk the resource tree
and print it.

Is it a real lock up, or a panic (probably with NULL pointer dereference or bad
address access)? /proc/iomem works on both my m68k Amiga and my PPC CHRP box.

Can you add debugging code in kernel/resource.c:do_resource_list(), so we know
where it happens? If /proc/iomem doesn't work, changes are high that your box
will crash also when some driver wants to use the resource tree.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

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

Re: 2.4.0-test4 success (Re: affs)

[Michel <dae...@st...>]

Geert Uytterhoeven wrote:
> 
> On Fri, 28 Jul 2000, Michel [iso-8859-1] Dänzer wrote:
> > PS: I can still hang the machine with 'cat /proc/iomem' ...
> 
> That's something which must not happen.

Guessed so ("A hang is not supposed?" ;)

> All it does is walk the resource tree and print it.
> 
> Is it a real lock up, or a panic (probably with NULL pointer dereference or
> bad address access.

I've only tried it from a remote machine yet - will try at the console.

> /proc/iomem works on both my m68k Amiga and my PPC CHRP box.

I thought it might be related to the fact that we don't have an iobase, but I
guess then it shouldn't work on your m68k box either...


> Can you add debugging code in kernel/resource.c:do_resource_list(), so we
> know where it happens? If /proc/iomem doesn't work, changes are high that
> your box will crash also when some driver wants to use the resource tree.

That would be pretty bad - which Amiga drivers would want to use it?


Michel


-- 
I'm not tense, just terribly, terribly alert.
______________________________________________________________________________
Earthling Michel Dänzer (MrCooper)  \  CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \   member of XFree86, Team *AMIGA*, AUGS

Re: 2.4.0-test4 success (Re: affs)

[Geert U. <ge...@li...>]

On Fri, 28 Jul 2000, Michel [iso-8859-1] Dänzer wrote:
> Geert Uytterhoeven wrote:
> > Is it a real lock up, or a panic (probably with NULL pointer dereference or
> > bad address access.
> 
> I've only tried it from a remote machine yet - will try at the console.

Probably there's an interesting message on your console.

> > /proc/iomem works on both my m68k Amiga and my PPC CHRP box.
> 
> I thought it might be related to the fact that we don't have an iobase, but I
> guess then it shouldn't work on your m68k box either...

So /proc/ioports is empty, but /proc/iomem is full (remember, all I/O on m68k
and PPC is memory mapped).

> > Can you add debugging code in kernel/resource.c:do_resource_list(), so we
> > know where it happens? If /proc/iomem doesn't work, changes are high that
> > your box will crash also when some driver wants to use the resource tree.
> 
> That would be pretty bad - which Amiga drivers would want to use it?

Lot's of drivers. I converted almost all of them (including all drivers for
Zorro boards) and the rest is just waiting here to be tested. Look for
request_mem_region().

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

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

Re: 2.2.16 ?

[Michel <da...@re...>]

Sven LUTHER wrote:

> > > What changed between 2.2.10 and .16 ?
> >
> > Dunno exactly...
> 
> I was told that lot of ppc related stuff did improve, ... Was it not you
> michel who told me that ?

Hmm, don't remember honestly - when would that have been?

Anyway, I've put the diff into the v2.2 directory in the FTP area, if anyone
wants to stab at it...


Michel


-- 
Man invented language to satisfy his deep need to complain.
______________________________________________________________________________
Earthling Michel Dänzer (MrCooper)  \  CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \   member of XFree86, Team *AMIGA*, AUGS

Re: 2.2.16 ?

[Alan B. <al...@ms...>]

hi,

> > I was told that lot of ppc related stuff did improve, ... Was it not you
> > michel who told me that ?
> 
> Hmm, don't remember honestly - when would that have been?
> 
> Anyway, I've put the diff into the v2.2 directory in the FTP area, if anyone
> wants to stab at it...

I guess that by examining the diff we can see the changes/improvements,
but there must be a CHANGELOG, or CVS comment'-tree' somewhere that'll
give us a clear improvment list - perhaps for an APUS press release?

alan

Re: 2.2.16 ?

[Michel <da...@re...>]

Alan Buxey wrote:

> > Anyway, I've put the diff into the v2.2 directory in the FTP area, if
> > anyone wants to stab at it...
> 
> I guess that by examining the diff we can see the changes/improvements,

The diff turns a native 2.2.16 into an m68k 2.2.16. Nothing more, nothing
less.


> but there must be a CHANGELOG, or CVS comment'-tree' somewhere that'll
> give us a clear improvment list

AFAIK everyone has posted their commits here so far, so someone just has to
collect that information.

> - perhaps for an APUS press release?

You were talking about that already when we started at sourceforge...


Michel


-- 
Earth first!  We'll strip-mine the other planets later.
______________________________________________________________________________
Earthling Michel Dänzer (MrCooper)  \  CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \   member of XFree86, Team *AMIGA*, AUGS

Re: 2.2.16 ?

[Alan B. <al...@ms...>]

hi,

> > - perhaps for an APUS press release?
> 
> You were talking about that already when we started at sourceforge...

our move to sourceforge.net was released to the Amiga news sites.

alan