Menu
▾
▴
linux-apus-devel
|
From: Michel <dae...@st...> - 2000-07-26 00:59:10
|
Michael Fedrowitz kindly provided me with an unofficial m68k diff for 2.2.16 . I think this could be our chance to get a more recent "stable" kernel. How should we go about updating the 2.2.x tree? Spawn a branch (does that work now?)? Looking forward to comments and suggestions, Michel -- Death is just Nature's way of saying, "Hey! You're not alive anymore!" ______________________________________________________________________________ Earthling Michel Dänzer (MrCooper) \ CS student and free software enthusiast Debian GNU/Linux (powerpc,i386) user \ member of XFree86, Team *AMIGA*, AUGS |
|
From: Ken T. <ke...@we...> - 2000-07-26 03:07:25
|
On Wed, 26 Jul 2000, Michel [iso-8859-1] Dänzer wrote: > How should we go about updating the 2.2.x tree? Spawn a branch (does that work > now?)? I'd vote for a branch (no idea how to though) just in case "stable" isn't. Ken. |
|
From: <fp...@zu...> - 2000-07-26 06:48:46
|
On Wed, Jul 26, 2000 at 01:03:18PM +1000, Ken Tyler wrote: > > > On Wed, 26 Jul 2000, Michel [iso-8859-1] Dänzer wrote: > > > How should we go about updating the 2.2.x tree? Spawn a branch (does that work > > now?)? > > I'd vote for a branch (no idea how to though) just in case "stable" isn't. Me, too ;-) 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. -- 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. |
|
From: Geert U. <ge...@li...> - 2000-07-26 18:05:53
|
On Wed, 26 Jul 2000, Frank Petzold wrote:
> On Wed, Jul 26, 2000 at 01:03:18PM +1000, Ken Tyler wrote:
> > On Wed, 26 Jul 2000, Michel [iso-8859-1] Dänzer wrote:
> > > How should we go about updating the 2.2.x tree? Spawn a branch (does that work
> > > now?)?
> >
> > I'd vote for a branch (no idea how to though) just in case "stable" isn't.
>
> Me, too ;-)
>
> 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.
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
|
|
From: Michel <dae...@st...> - 2000-07-26 18:23:06
|
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?
Michel
--
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
|
|
From: Geert U. <ge...@li...> - 2000-07-27 19:16:03
|
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
|
|
From: Giorgio T. <de...@ip...> - 2000-08-24 05:54:34
|
Hi,
i have modified a bit some files in 2.2 kernel to export the
"more legal" symbols "register_serial" and "unregister serial".
They may sobstitute m68k_register_serial and m68k_unregister_serial
that remain untouched.
This modification follows a discussion at least 2 weeks old about
m68k_serial.c and some module problems.
I have also modified IOBlx driver to use the "legal" symbols.
May i cvs commit it ?
Files modified:
arch/ppc/kernel/apus_setup.c:
a) added configure.h and module.h include files
b) added a define for IOBlix where there are the other serial defines
c) added 26 rows below the involved EXPORT_SYMBOL() calls
arch/ppc/kernel/Makefile
a) apus_setup.c now exports its symbols and must be in OX_OBJS
drivers/char/ser_ioblx_zorro.c
a) changed the functions m68k_(un)register_serial() to the "standards".
Regards,
Giorgio Terzi
|
|
From: Michel <da...@re...> - 2000-08-24 08:45:22
|
Giorgio Terzi wrote: > i have modified a bit some files in 2.2 kernel to export the > "more legal" symbols "register_serial" and "unregister serial". > They may sobstitute m68k_register_serial and m68k_unregister_serial > that remain untouched. > This modification follows a discussion at least 2 weeks old about > m68k_serial.c and some module problems. > I have also modified IOBlx driver to use the "legal" symbols. > May i cvs commit it ? Go ahead. The old symbols stay so it shouldn't break anything. Michel -- Earthling Michel Dänzer (MrCooper) \ CS student and free software enthusiast Debian GNU/Linux (powerpc,i386) user \ member of XFree86 and the DRI project |
|
From: Michel <da...@re...> - 2000-07-26 10:18:13
|
Frank Petzold wrote: > > > How should we go about updating the 2.2.x tree? Spawn a branch (does > > > that work now?)? > > > > I'd vote for a branch (no idea how to though) just in case "stable" isn't. > > Me, too ;-) Me, too :) > cvs tag -b merge-2-2-16 > cvs upd -r merge-2-2-16 I've done: 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 What do you people think, would it be easier to replace the whole tree with native 2.2.16 now, then apply the m68k diff and finally try to get our stuff back in, or rather unapply the 2.2.10 m68k diff, apply relative diffs from 2.2.10 to 2.2.16, apply the m68k and fix our stuff? Michel -- I'm so hungry, I could almost eat health food. ______________________________________________________________________________ Earthling Michel Dänzer (MrCooper) \ CS student and free software enthusiast Debian GNU/Linux (powerpc,i386) user \ member of XFree86, Team *AMIGA*, AUGS |
|
From: Ken T. <ke...@we...> - 2000-07-26 13:03:46
|
On Wed, 26 Jul 2000, Michel [iso-8859-1] Dänzer wrote: > What do you people think, would it be easier to replace the whole tree with > native 2.2.16 now, then apply the m68k diff and finally try to get our stuff > back in, or rather unapply the 2.2.10 m68k diff, apply relative diffs from > 2.2.10 to 2.2.16, apply the m68k and fix our stuff? After a pause ... Is it really worth the effort to update to 2.2.16 given that 2.3 is almost working ? What changed between 2.2.10 and .16 ? Ken. |
|
From: Michel <da...@re...> - 2000-07-26 13:07:16
|
Ken Tyler wrote: > > What do you people think, would it be easier to replace the whole tree > > with native 2.2.16 now, then apply the m68k diff and finally try to get > > our stuff back in, or rather unapply the 2.2.10 m68k diff, apply relative > > diffs from 2.2.10 to 2.2.16, apply the m68k and fix our stuff? > > After a pause ... > > Is it really worth the effort to update to 2.2.16 given that 2.3 is almost > working ? That's a point, but I think most "normal" users only track development in 2.2 and so we could show them that we are making progress and not dead. > What changed between 2.2.10 and .16 ? Dunno exactly... Michel -- Men are from Earth. Women are from Earth. Deal with it. ______________________________________________________________________________ Earthling Michel Dänzer (MrCooper) \ CS student and free software enthusiast Debian GNU/Linux (powerpc,i386) user \ member of XFree86, Team *AMIGA*, AUGS |
|
From: Sven L. <lu...@dp...> - 2000-07-27 05:34:56
|
On Wed, Jul 26, 2000 at 03:06:48PM +0200, Michel Dänzer wrote: > Ken Tyler wrote: > > > > What do you people think, would it be easier to replace the whole tree > > > with native 2.2.16 now, then apply the m68k diff and finally try to get > > > our stuff back in, or rather unapply the 2.2.10 m68k diff, apply relative > > > diffs from 2.2.10 to 2.2.16, apply the m68k and fix our stuff? > > > > After a pause ... > > > > Is it really worth the effort to update to 2.2.16 given that 2.3 is almost > > working ? > > That's a point, but I think most "normal" users only track development in 2.2 > and so we could show them that we are making progress and not dead. > > > > 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 ? Friendly, Sven LUTHER |
|
From: Frank P. <fp...@zu...> - 2000-07-26 14:04:12
|
On Wed, Jul 26, 2000 at 10:59:38PM +1000, Ken Tyler wrote: > Is it really worth the effort to update to 2.2.16 given that 2.3 is almost > working ? Hmm. Not working (at least): Real time clock, Multiface III, *AFFS* At least, they don't work for me ATM. -- 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. |
|
From: Ken T. <ke...@we...> - 2000-07-26 15:08:33
|
On Wed, 26 Jul 2000, Frank Petzold wrote: > On Wed, Jul 26, 2000 at 10:59:38PM +1000, Ken Tyler wrote: > > Is it really worth the effort to update to 2.2.16 given that 2.3 is almost > > working ? > > Hmm. Not working (at least): Real time clock, Multiface III, *AFFS* > At least, they don't work for me ATM. The RTC has never worked for me in any kernel. Multiface III - don't have one. AFFS, the guy (Dave Jones) has it running in 2.3, I assume the changes in 'our' 2.3 are the latest. Ken. |
|
From: Frank P. <fp...@zu...> - 2000-07-26 15:49:46
|
On Thu, Jul 27, 2000 at 01:07:52AM +1000, Ken Tyler wrote: > > Hmm. Not working (at least): Real time clock, Multiface III, *AFFS* > > At least, they don't work for me ATM. > > The RTC has never worked for me in any kernel. Just to make sure we are speaking of the same: The Amiga builtin Realtime Clock. It works for me in 2.2. I can set it, and read it with hwclock. > Multiface III - don't have one. > > AFFS, the guy (Dave Jones) has it running in 2.3, I assume the changes in > 'our' 2.3 are the latest. The kernel hangs as soon as I try to mount an AFFS partition rw. Heartbeat is still on and I can change VTs, but I cannot login anymore or shut down. -- 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. |
|
From: Ken T. <ke...@we...> - 2000-07-27 05:52:59
|
On Wed, 26 Jul 2000, Frank Petzold wrote: > > The RTC has never worked for me in any kernel. > > Just to make sure we are speaking of the same: The Amiga builtin Realtime > Clock. It works for me in 2.2. I can set it, and read it with hwclock. That's the one - as opposed to the software 'kernel' clock. Please send me your hwclock, mine certainly does not work. Does it depend on anything else ? Ken. |
|
From: Sven L. <lu...@dp...> - 2000-07-27 06:29:58
|
On Thu, Jul 27, 2000 at 03:52:14PM +1000, Ken Tyler wrote: > > > On Wed, 26 Jul 2000, Frank Petzold wrote: > > > > The RTC has never worked for me in any kernel. > > > > Just to make sure we are speaking of the same: The Amiga builtin Realtime > > Clock. It works for me in 2.2. I can set it, and read it with hwclock. > > That's the one - as opposed to the software 'kernel' clock. > > Please send me your hwclock, mine certainly does not work. > > Does it depend on anything else ? I think you need to have a recent version of linux-utils or whatever package contains hwclock. Friendly, Sven LUTHER |
|
From: Ken T. <ke...@we...> - 2000-07-27 07:24:26
|
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 ? Ken. |
|
From: Sven L. <lu...@dp...> - 2000-07-27 07:57:26
|
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 |
|
From: Ken T. <ke...@we...> - 2000-07-27 10:15:25
|
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. |
|
From: Roman Z. <zi...@fh...> - 2000-07-26 17:00:02
|
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. bye, Roman |
|
From: Ken T. <ke...@we...> - 2000-07-27 07:26:56
|
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. |
|
From: Michel <da...@re...> - 2000-07-27 07:57:26
|
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 |
|
From: Ken T. <ke...@we...> - 2000-07-27 10:13:35
|
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. |
|
From: Roman Z. <zi...@fh...> - 2000-07-27 08:09:51
|
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 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X