Menu
▾
▴
linux-apus-devel
|
From: Jouko P. <py...@jy...> - 2000-06-15 10:54:59
|
Michel wrote: > > > It still doesn`t boot with pm2fb here, I get tons of `amiga_disable_irq: > > > trying to disable Amiga auto IRQ 3` messages. > > > > This shouldn`t happen anymore with my latest cvs changes (at least it > > went away for me... :) ), IMO it was a reentrancy problem for shared > > interrupts. > > I still have the problem, whether I build amifb in the kernel, as a > module or not at all. I have the same problem but also another one with include/asm/atomic.h: When compiling 2.3 from the CVS, i started getting errors with many files in kernel/. I'm at work and don't have the actual error message here but it was something like "protected or fixed register used, a bug in the compiler or impossible asm clauses". The problem seemed to be the inlined functions (atomic_inc, atomic_dec, ...) in include/asm/atomic.h. The errors went away when i #if 0'ed away the inlined functions and re-enabled the old ones in arch/ppc/kernel/misc.S. Since no-one else has mentioned this, it might be 603e specific? After that change it compiled ok but the kernel freezes on boot with those amiga_disable_irq messages... I didn't look at it further yet. Jouko |
|
From: Michel <dae...@st...> - 2000-06-15 11:00:24
|
Jouko Pynnonen wrote:
> > > > It still doesn`t boot with pm2fb here, I get tons of
> > > > `amiga_disable_irq: trying to disable Amiga auto IRQ 3` messages.
> > >
> > > This shouldn`t happen anymore with my latest cvs changes (at least it
> > > went away for me... :) ), IMO it was a reentrancy problem for shared
> > > interrupts.
> >
> > I still have the problem, whether I build amifb in the kernel, as a
> > module or not at all.
>
> I have the same problem but also another one with include/asm/atomic.h:
> When compiling 2.3 from the CVS, i started getting errors with many
> files in kernel/. I'm at work and don't have the actual error message
> here but it was something like "protected or fixed register used, a bug
> in the compiler or impossible asm clauses".
What compiler are you using? I use gcc 2.95.2.
> The problem seemed to be the inlined functions (atomic_inc, atomic_dec, ...)
> in include/asm/atomic.h. The errors went away when i #if 0'ed away the
> inlined functions and re-enabled the old ones in arch/ppc/kernel/misc.S.
> Since no-one else has mentioned this, it might be 603e specific?
I also have a 603e and haven't seen it. Shouldn't matter anyway as gcc
normally doesn't produce processor-specific code.
> After that change it compiled ok but the kernel freezes on boot with those
> amiga_disable_irq messages... I didn't look at it further yet.
Welcome to the club :-/
Michel
--
Press every key to continue.
______________________________________________________________________________
Earthling Michel Dänzer (MrCooper) \ CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \ member of XFree86, Team *AMIGA*, AUGS
|
|
From: Jouko P. <py...@jy...> - 2000-06-15 11:06:04
|
On Thu, 15 Jun 2000, Michel Dänzer wrote: > > here but it was something like "protected or fixed register used, a bug > > in the compiler or impossible asm clauses". > > What compiler are you using? I use gcc 2.95.2. The one that comes with egcs-1.1.2-12c.ppc.rpm, the latest one in linuxppc-1999 distribution. Jouko |
|
From: Michel <dae...@st...> - 2000-06-15 11:09:55
|
Jouko Pynnonen wrote: > > On Thu, 15 Jun 2000, Michel Dänzer wrote: > > > > here but it was something like "protected or fixed register used, a bug > > > in the compiler or impossible asm clauses". > > > > What compiler are you using? I use gcc 2.95.2. > > The one that comes with egcs-1.1.2-12c.ppc.rpm, the latest one in > linuxppc-1999 distribution. egcs is old and known to have lots of problems. I advise you upgrade to the latest gcc. Michel -- Therapy is expensive, popping bubble wrap is cheap. You choose. ______________________________________________________________________________ Earthling Michel Dänzer (MrCooper) \ CS student and free software enthusiast Debian GNU/Linux (powerpc,i386) user \ member of XFree86, Team *AMIGA*, AUGS |
|
From: Jouko P. <py...@jy...> - 2000-06-15 23:25:21
|
I changed a couple of things in my 2.3 kernel and got it running. I don't know which of the changes were important but anyway: 1) in amiints.c function amiga_free_irq() if you free an auto irq, it should probably return after the sys_free_irq() call on line 259, otherwise it goes to cia_free_irq() as well and tries to free it as a CIA interrupt. 2) in amiga_enable_irq() some vaues in ami_ablecount[] seemed to go negative, which can't be right? I added a check so it'll never be decreased below zero. 3) the old ami_int3 change: reinserted it to the amiga_default_handler[] array and free the irq in amifb.c after ami_init_copper() call. I doubt this isn't the Right Way though. After those it boots, was up for over an hour. I compiled stuff, ran X etc and saw no crashes. Btw one thing about PPP: do you need a new pppd specifically for 2.3 kernels? I couldn't get ppp running. It says the kernel doesn't have ppp support. I don't think (?) it's because of the serial driver, i kludged amiserial.c to compile and as far as i can see serial i/o works. Jouko |
|
From: <fp...@zu...> - 2000-06-16 06:46:28
|
On Fri, Jun 16, 2000 at 02:32:31AM +0300, Jouko Pynnonen wrote: > After those it boots, was up for over an hour. I compiled stuff, ran X > etc and saw no crashes. Using amifb, I guess? -- 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: Jouko P. <py...@jy...> - 2000-06-16 08:12:44
|
On Fri, 16 Jun 2000, Frank Petzold wrote: > On Fri, Jun 16, 2000 at 02:32:31AM +0300, Jouko Pynnonen wrote: > > After those it boots, was up for over an hour. I compiled stuff, ran X > > etc and saw no crashes. > > Using amifb, I guess? I used pm2fb, there is amifb compiled in the kernel but didn't try any amiga modes (no suitable monitor). Btw, about the PPP thing, you do need a new pppd (e.g. from ftp://linuxcare.com.au/pub/ppp/) and a new char device /dev/ppp. There's a problem with serial io though. It gets a lot of overruns even at speeds like 9600 bauds. This might be a problem with either my amiserial.c kludges or still something with interrupt handling. Jouko |
|
From: Michel <dae...@st...> - 2000-06-16 08:17:54
|
Jouko Pynnonen wrote: > > On Fri, 16 Jun 2000, Frank Petzold wrote: > > > On Fri, Jun 16, 2000 at 02:32:31AM +0300, Jouko Pynnonen wrote: > > > After those it boots, was up for over an hour. I compiled stuff, ran X > > > etc and saw no crashes. > > > > Using amifb, I guess? > > I used pm2fb, there is amifb compiled in the kernel but didn't try any > amiga modes (no suitable monitor). > > Btw, about the PPP thing, you do need a new pppd (e.g. from > ftp://linuxcare.com.au/pub/ppp/) and a new char device /dev/ppp. > There's a problem with serial io though. It gets a lot of overruns even at > speeds like 9600 bauds. This might be a problem with either my amiserial.c > kludges or still something with interrupt handling. :-/ Do you have SCSI (running)? Have you committed your changes? Michel -- I don't suffer from stress. I'm a carrier. ______________________________________________________________________________ Earthling Michel Dänzer (MrCooper) \ CS student and free software enthusiast Debian GNU/Linux (powerpc,i386) user \ member of XFree86, Team *AMIGA*, AUGS |
|
From: Jouko P. <py...@jy...> - 2000-06-16 08:34:23
|
On Fri, 16 Jun 2000, Michel Dänzer wrote: > > kludges or still something with interrupt handling. > > :-/ > > Do you have SCSI (running)? Have you committed your changes? Nope I don't have SCSI. I haven't committed them. What's the committing policy? Some of the changes are temporary fixes so i thought it's better to discuss on the list whether they make sense. I can post the diffs though. Jouko |
|
From: Frank P. <fp...@zu...> - 2000-06-16 09:25:40
|
On Fri, Jun 16, 2000 at 11:41:15AM +0300, Jouko Pynnonen wrote: > > Nope I don't have SCSI. I haven't committed them. What's the committing > policy? Some of the changes are temporary fixes so i thought it's better > to discuss on the list whether they make sense. I can post the diffs > though. It is probably best to spawn a branch and commit to that. I don't think we hava an official policy. And yes, it good to discuss changes on the ML. As stated in the CVS manual: CVS does not substitute communication. -- 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: Michel <dae...@st...> - 2000-06-16 09:49:10
|
Frank Petzold wrote: > > On Fri, Jun 16, 2000 at 11:41:15AM +0300, Jouko Pynnonen wrote: > > > > What's the committing policy? Some of the changes are temporary fixes so i > > thought it's better to discuss on the list whether they make sense. I can > > post the diffs though. > > It is probably best to spawn a branch and commit to that. I don't agree for the 2.3 module. Everybody knows that code in there is unstable. And what's the use of CVS if everybody spawns a branch for what he's working on? And at least in this case, I guess everyone likes to have a booting kernel in the first place, even if it may have its quirks. > I don't think we hava an official policy. No, but a discussion to get one might be good. > And yes, it good to discuss changes on the ML. As stated in the CVS manual: > CVS does not substitute communication. Of course :) Michel -- UNIX is like Sex: If you don't know it, you don't miss it. But if you know it, you'll need 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: Geert U. <ge...@li...> - 2000-06-16 09:59:19
|
On Fri, 16 Jun 2000, Michel Dänzer wrote:
> Frank Petzold wrote:
> > On Fri, Jun 16, 2000 at 11:41:15AM +0300, Jouko Pynnonen wrote:
> > > What's the committing policy? Some of the changes are temporary fixes so i
> > > thought it's better to discuss on the list whether they make sense. I can
> > > post the diffs though.
> >
> > It is probably best to spawn a branch and commit to that.
>
> I don't agree for the 2.3 module. Everybody knows that code in there is
> unstable. And what's the use of CVS if everybody spawns a branch for what he's
> working on?
>
> And at least in this case, I guess everyone likes to have a booting kernel in
> the first place, even if it may have its quirks.
If you have a quick fix, you can check it in on the main branch.
Branches are meant for larger subprojects that take more work to be finished.
When the subproject is finished, you merge the main branch to it and verify
that it still works. After that you merge the subproject branch to the main
branch.
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: Jouko P. <py...@jy...> - 2000-06-16 10:06:03
|
> And at least in this case, I guess everyone likes to have a booting kernel in
> the first place, even if it may have its quirks.
These worked for me...
--- amiints.c.orig Thu Jun 15 21:19:07 2000
+++ amiints.c Thu Jun 15 21:37:56 2000
@@ -255,9 +255,10 @@
return;
}
- if (irq >= IRQ_AMIGA_AUTO)
+ if (irq >= IRQ_AMIGA_AUTO) {
sys_free_irq(irq - IRQ_AMIGA_AUTO, dev_id);
-
+ return;
+ }
if (irq >= IRQ_AMIGA_CIAA) {
cia_free_irq(irq, dev_id);
return;
@@ -295,8 +296,9 @@
return;
}
- if (--ami_ablecount[irq])
- return;
+ ami_ablecount[irq]--;
+ if (ami_ablecount[irq]<0) ami_ablecount[irq]=0;
+ else if (ami_ablecount[irq]) return;
/* No action for auto-vector interrupts */
if (irq >= IRQ_AMIGA_AUTO){
@@ -463,7 +465,7 @@
and executes them in a loop. Having ami_badint at the end of the chain
is a bad idea. */
void (*amiga_default_handler[SYS_IRQS])(int, void *, struct pt_regs *) = {
- NULL, ami_int1, NULL, NULL /* FB expects to replace ami_int3*/,
+ NULL, ami_int1, NULL, ami_int3,
ami_int4, ami_int5, NULL, ami_int7
};
#else
--- amifb.c.orig Thu Jun 15 21:36:34 2000
+++ amifb.c Thu Jun 15 21:36:57 2000
@@ -1811,6 +1811,7 @@
*/
ami_init_copper();
+ free_irq(IRQ_AMIGA_AUTO_3,NULL);
#if 1
if (request_irq(IRQ_AMIGA_AUTO_3, amifb_interrupt, 0,
|
|
From: Roman Z. <zi...@fh...> - 2000-06-16 11:39:42
|
Hi, > These worked for me... The amiints.c changes look fine, can you commit them? For amifb.c I want to commit something else (I didn't test it yet, as much as I wanted, but I don't expect bigger problems.) bye, Roman > - if (--ami_ablecount[irq]) > - return; > + ami_ablecount[irq]--; > + if (ami_ablecount[irq]<0) ami_ablecount[irq]=0; > + else if (ami_ablecount[irq]) return; Could you indent that a bit? :) ami_ablecount should never go negativ, but the other ppc version don't have a count at all, so maybe somethings expects a broken behaviour... bye, Roman |
|
From: Jouko P. <py...@jy...> - 2000-06-16 11:51:35
|
On Fri, 16 Jun 2000, Roman Zippel wrote: > The amiints.c changes look fine, can you commit them? For amifb.c I want > to commit something else (I didn't test it yet, as much as I wanted, but I > don't expect bigger problems.) Sorry, I already committed both. > > - if (--ami_ablecount[irq]) > > - return; > > + ami_ablecount[irq]--; > > + if (ami_ablecount[irq]<0) ami_ablecount[irq]=0; > > + else if (ami_ablecount[irq]) return; > > Could you indent that a bit? :) Is there any doc or guideline about indenting/coding style we should follow? Jouko |
|
From: Michel <dae...@st...> - 2000-06-16 14:53:42
|
Jouko Pynnonen wrote: > > Could you indent that a bit? :) > > Is there any doc or guideline about indenting/coding style we should > follow? All I know is Documentation/CodingStyle. Michel -- The three Rs of Microsoft support: Retry, Reboot, Reinstall. ______________________________________________________________________________ Earthling Michel Dänzer (MrCooper) \ CS student and free software enthusiast Debian GNU/Linux (powerpc,i386) user \ member of XFree86, Team *AMIGA*, AUGS |
|
From: Roman Z. <zi...@fh...> - 2000-06-16 15:59:45
|
Hi,
> Sorry, I already committed both.
I appended the diff below for amifb.c, I don't know if the locking problem
is fixed before I leave into the weekend.
bye, Roman
Index: amifb.c
===================================================================
RCS file: /cvsroot/linux-apus/2.3/drivers/video/amifb.c,v
retrieving revision 1.4
diff -u -r1.4 amifb.c
--- amifb.c 2000/06/16 10:44:31 1.4
+++ amifb.c 2000/06/16 15:37:58
@@ -1811,9 +1811,8 @@
*/
ami_init_copper();
- free_irq(IRQ_AMIGA_AUTO_3,NULL);
-#if 1
+#if 0
if (request_irq(IRQ_AMIGA_AUTO_3, amifb_interrupt, 0,
"fb vertb handler", NULL)) {
err = -EBUSY;
@@ -1927,8 +1926,9 @@
static void amifb_interrupt(int irq, void *dev_id, struct pt_regs *fp)
{
- u_short ints = custom.intreqr & custom.intenar;
unsigned long flags;
+#if 0
+ u_short ints = custom.intreqr & custom.intenar;
if (ints & IF_BLIT) {
custom.intreq = IF_BLIT;
@@ -1937,6 +1937,7 @@
if (ints & IF_COPER) {
custom.intreq = IF_COPER;
+#endif
if (do_vmode_pan || do_vmode_full)
ami_update_display();
@@ -1971,6 +1972,7 @@
ami_reinit_copper();
do_vmode_full = 0;
}
+#if 0
amiga_do_irq_list(IRQ_AMIGA_VERTB, fp);
}
@@ -1978,6 +1980,7 @@
printk("%s: Warning: IF_VERTB was enabled\n", __FUNCTION__);
custom.intena = IF_VERTB;
}
+#endif
}
/*
|
|
From: Frank P. <fp...@zu...> - 2000-06-16 11:00:11
|
On Fri, Jun 16, 2000 at 11:45:42AM +0200, Michel Dänzer wrote: > And at least in this case, I guess everyone likes to have a booting kernel in > the first place, even if it may have its quirks. I agree on that one. -- 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. |
×
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