linux-apus-devel

Re: newbie needs help with modules

[Gordon H. <go...@gh...>]

fh...@at... wrote:

> ser_hypercom4.o: unresolved symbol unregister_serial
> ser_hypercom4.o: unresolved symbol register_serial

These should now be m68k_unregister_serial() and m68k_register_serial(),
Don't know why though. :)

Kind Regards,

Gordon.

Re: newbie needs help with modules

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

On Sat, 29 Jul 2000 fh...@at... wrote:
> I decided to try developing my driver projects as modules in order to save
> reboot cycles.  When I do this, trying to follow the module programming
> advice I got, I get unresolved symbols.  How do I get rid of these?  These
> symbols appear to be routines burried in the kernel various places. 

General solution: add `EXPORT_SYMBOL(unknown_symbol)' to some kernel source
file.

> The PowerUP SCSI module:
> 
> 53c770.o: unresolved symbol virt_to_phys

virt_to_phys() is an inline function (see include/asm-ppc/io.h), so this
should not happen.

 1. Does the compiler complain about functions without a prototype? Many
    functions are inline, but of course they are defined if you include the
    correct header files only.
 2. Do you compile with optimization? If not, enable optimization.
 3. Do you compile with -D__KERNEL__? virt_to_phys() is defined inside
    #idef __KERNEL_/#endif

The same is true for many other symbols.

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

newbie needs help with modules

[<fh...@at...>]

I decided to try developing my driver projects as modules in order to save
reboot cycles.  When I do this, trying to follow the module programming
advice I got, I get unresolved symbols.  How do I get rid of these?  These
symbols appear to be routines burried in the kernel various places. 

The PowerUP SCSI module:

53c770.o: unresolved symbol virt_to_phys
53c770.o: unresolved symbol in_be16
53c770.o: unresolved symbol out_8
53c770.o: unresolved symbol in_8
53c770.o: unresolved symbol init_timer
53c770.o: unresolved symbol __fswab32
53c770.o: unresolved symbol virt_to_bus
53c770.o: unresolved symbol out_be32
53c770.o: unresolved symbol __restore_flags
53c770.o: unresolved symbol out_be16
53c770.o: unresolved symbol udelay

The Delfina Plus module:

dsp56k.o: unresolved symbol __get_user_bad
dsp56k.o: unresolved symbol __put_user_bad
dsp56k.o: unresolved symbol udelay

The Hypercom4+ module:

ser_hypercom4.o: unresolved symbol queue_task
ser_hypercom4.o: unresolved symbol mark_bh
ser_hypercom4.o: unresolved symbol __restore_flags
ser_hypercom4.o: unresolved symbol unregister_serial
ser_hypercom4.o: unresolved symbol register_serial

Fred

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:
> 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.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)

[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

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)

[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

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: 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.

Re: 2.2.16 ?

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

On Wed, 26 Jul 2000, Michel [iso-8859-1] Dänzer wrote:
> Geert Uytterhoeven wrote:
> > > cvs tag -b merge-2-2-16
> > > cvs upd -r merge-2-2-16
> > > "patch <unofficial-m68k-2-2-16-patch -p x" or whatever is necessary to
> > > migrate cvs commit
> > >
> > > should  do the trick.
> > 
> > And don't forget to cvs {add,remove} the new/obsolete files and directories.
> 
> Yep, I also thought of that - are the scripts you posted once failsafe for
> this task?

No, the script doesn't check for new directories.

Fortunately you can run the script, and manually cvs add/remove the directories
it complained about, and rerun the script. CVS can live with multiple
adds/removes for the same file.

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

[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: 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

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: 2.2.16 ?

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

On Thu, 27 Jul 2000, Sven LUTHER wrote:

> No i don't have, but i think there is a version where it is ok.
> 
> In the debian util-linux package, before i had to comment out the
> /etc/init.d/hwclock.sh script, since it got called at each boot, and called a
> hwclock that crashed the machine. On later installs i think to remember i
> don't have this problem anymore, but maybe the script got changed.

I sync my time to the network machine that runs xntpd but I'd love to be
able to set the RTC.

Maybe oneday.

Ken.

 

Re: affs

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

On Thu, 27 Jul 2000, Michel [iso-8859-1] Dänzer wrote:

> Ken Tyler wrote:

> > I just updated 2.3 and attempted to compile, I see :
> > 
> > gcc  blah -c -o signal.o signal.c
> > signal.c: In function `do_sigaction':
> > signal.c:921: fixed or forbidden register 68 (0) was spilled for class
> > CR0_REGS.
> > This may be due to a compiler bug or to impossible asm
> > statements or clauses.
> > make[2]: *** [signal.o] Error 1
> 
> Which compiler do you use?

> AFAIK even Linus uses egcs-1.1.2 now *grin*

# gcc -v
Reading specs from /usr/lib/gcc-lib/ppc-redhat-linux/egcs-2.91.66/specs
gcc version egcs-2.91.66 19990314 (egcs-1.1.2 release)

Never failed before.

> I'm using gcc 2.95.2 ...

Maybe mines too old.

Ken.

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,

> > 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: affs

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

Hi,

> gcc  blah -c -o signal.o signal.c
> signal.c: In function `do_sigaction':
> signal.c:921: fixed or forbidden register 68 (0) was spilled for class
> CR0_REGS.
> This may be due to a compiler bug or to impossible asm
> statements or clauses.
> make[2]: *** [signal.o] Error 1

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

bye, Roman

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 ?

[Sven L. <lu...@dp...>]

On Thu, Jul 27, 2000 at 05:23:35PM +1000, Ken Tyler wrote:
> 
> 
> On Thu, 27 Jul 2000, Sven LUTHER wrote:
> 
> > I think you need to have a recent version of linux-utils or whatever package
> > contains hwclock.
> 
> I did that, someone said to use the clock or hwclock out of it, many
> crashes later I gave up.
> 
> Do you have a (hw)clock that works ?
> 
> What options does the kernel need ?

No i don't have, but i think there is a version where it is ok.

In the debian util-linux package, before i had to comment out the
/etc/init.d/hwclock.sh script, since it got called at each boot, and called a
hwclock that crashed the machine. On later installs i think to remember i
don't have this problem anymore, but maybe the script got changed.

Friendly,

Sven LUTHER

Re: affs

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

Ken Tyler wrote:

> > 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.
> 
> I just updated 2.3 and attempted to compile, I see :
> 
> gcc  blah -c -o signal.o signal.c
> signal.c: In function `do_sigaction':
> signal.c:921: fixed or forbidden register 68 (0) was spilled for class
> CR0_REGS.
> This may be due to a compiler bug or to impossible asm
> statements or clauses.
> make[2]: *** [signal.o] Error 1

Which compiler do you use?

AFAIK even Linus uses egcs-1.1.2 now *grin*

I'm using gcc 2.95.2 ...


Michel


-- 
Me? A skeptic? Can you prove it?
______________________________________________________________________________
Earthling Michel Dänzer (MrCooper)  \  CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \   member of XFree86, Team *AMIGA*, AUGS

Re: affs

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

On Wed, 26 Jul 2000, Roman Zippel wrote:

> Hi,

> 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.

I just updated 2.3 and attempted to compile, I see :

gcc  blah -c -o signal.o signal.c
signal.c: In function `do_sigaction':
signal.c:921: fixed or forbidden register 68 (0) was spilled for class
CR0_REGS.
This may be due to a compiler bug or to impossible asm
statements or clauses.
make[2]: *** [signal.o] Error 1

Ken.