linux-apus-devel

Re: The PCI saga continues

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

Geert Uytterhoeven wrote:
> 
> On Tue, 20 Jun 2000, Michel Dänzer wrote:
> > - Buddha, Magic Sysrq and DRM don't build
> 
> Buddha and Magic Sysrq do build on my m68k box, though.

Ken should be able to fix Magic Sysrq (he has a fix for 2.2).


Michel


-- 
True programmers never die, they just branch to an odd address.
______________________________________________________________________________
Earthling Michel Dänzer (MrCooper)  \  CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \   member of XFree86, Team *AMIGA*, AUGS

[Bug #108029] Kernel hangs when mounting AFFS partitions

[<no...@so...>]

Bug #108029, was updated on 06/21/00 00:11
Here is a current snapshot of the bug.

Project: Linux/APUS Kernel
Category: Kernel
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Kernel hangs when mounting AFFS partitions

Details: The 2.3 kernel hangs when it tries to mount an AFFS
partition. Ext2 seems to work fine.

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=108029&group_id=5907

Re: The PCI saga continues

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

On Tue, 20 Jun 2000, Michel Dänzer wrote:
> - Buddha, Magic Sysrq and DRM don't build

Buddha and Magic Sysrq do build on my m68k box, though.

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

The PCI saga continues

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

I've been doing quite a bit:

2.2:

- really really fixed everything about PCI

  It doesn't get built now if you disable it and builds and works if you
  enable it ;)

- Fixed building of GVP IO Extender stuff as modules

- Disabled debug output in pm2fb


2.3:

- Add PCI support like in 2.2 (pm2fb isn't unified yet, nor is PCI tested)

- small condition fix in arch/ppc/kernel/ppc_ksyms.c



Some things I noticed in 2.3:

- Buddha, Magic Sysrq and DRM don't build

- It really boots now - thanks Roman and Jouko!

- The sim710 driver doesn't work on Blizzards out of the box


Michel


-- 
People who are wrong the most are wrong the loudest.
______________________________________________________________________________
Earthling Michel Dänzer (MrCooper)  \  CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \   member of XFree86, Team *AMIGA*, AUGS

Re: amiserial.c in 2.3

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

On Tue, 20 Jun 2000, Jouko Pynnonen wrote:
> On Tue, 20 Jun 2000, Roman Zippel wrote:
> > > must still be something weird with the interrupt system. I get a lot of
> > > overruns even at 4800 bps.
> > 
> > With or without disk activities? Did you try hdparm?
> 
> Didn't try hdparm but killed the update process and there hasn't been any
> big activity while I've been trying it. And it's not just some random
> overruns now and then, it's more like constant overruns most of the time.
> For instance when using 'cu' at 9600 bps and typing "AT", it can't often
> even reply "OK" without trouble. For the same reason pppd often fails even
> before dialing.
> 
> Btw I've seen there are mb() calls after reading or writing to custom
> registers but there aren't any after r/w to cia registers... could this be
> a problem?

Yes, especially if you use CTS/RTS handshaking.

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: amiserial.c in 2.3

[Jouko P. <py...@jy...>]

On Tue, 20 Jun 2000, Roman Zippel wrote:

> > must still be something weird with the interrupt system. I get a lot of
> > overruns even at 4800 bps.
> 
> With or without disk activities? Did you try hdparm?

Didn't try hdparm but killed the update process and there hasn't been any
big activity while I've been trying it. And it's not just some random
overruns now and then, it's more like constant overruns most of the time.
For instance when using 'cu' at 9600 bps and typing "AT", it can't often
even reply "OK" without trouble. For the same reason pppd often fails even
before dialing.

Btw I've seen there are mb() calls after reading or writing to custom
registers but there aren't any after r/w to cia registers... could this be
a problem?

  Jouko

Re: amiserial.c in 2.3

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

Hi,

> Does this new serial driver work under linux/m68k? If it does, then there
> must still be something weird with the interrupt system. I get a lot of
> overruns even at 4800 bps.

With or without disk activities? Did you try hdparm?

> However the SA_INTERRUPT flag isn't checked in any relevant place, and
> afaik the serial rx interrupt still runs with all other interrupts
> enabled. This can't be the main problem though, 'cos it's not checked in
> 2.2.x either and the serial i/o in 2.2.x works decently.

The serial interrupt has still the highest priority, so it will not be
interrupted, but other interrupts might block the serial one. BTW The
interrupt stuff in arch/ppc/kernel/irq.c is used to.

bye, Roman

Re: LinuxPPC 2000 CDs

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

hi,

> I think I read somewhere that they contain a peculiar file system to make it 
> boot on all Macs.

they're probably HFS formatted - Amiga CD fielsystems can handle this, but
the kernel will have to have that support compiled in,
 
Alan - still with Q3 1999

amiserial.c in 2.3

[Jouko P. <py...@jy...>]

Does this new serial driver work under linux/m68k? If it does, then there
must still be something weird with the interrupt system. I get a lot of
overruns even at 4800 bps. Amiserial.c is compilable with some little
changes concerning the xmit buffer (I'll commit it in CVS unless someone
has better ideas?).

The serial rx interrupt is requested with the SA_INTERRUPT flag.
In amiints.c it says:

 *           normal and fast handlers, fast handlers being
 *           marked with SA_INTERRUPT and runs with all other interrupts
 *           disabled.

However the SA_INTERRUPT flag isn't checked in any relevant place, and
afaik the serial rx interrupt still runs with all other interrupts
enabled. This can't be the main problem though, 'cos it's not checked in
2.2.x either and the serial i/o in 2.2.x works decently.

  Jouko

Re: LinuxPPC 2000 CDs

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

On Sat, 17 Jun 2000, Michel [iso-8859-1] Dänzer wrote:

> I think I read somewhere that they contain a peculiar file system to make it 
> boot on all Macs.

Oh goodie.
 
> You could ask on linuxppc-{dev,user} for details.

I will.

Thanks, Ken. 

Re: LinuxPPC 2000 CDs

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

Ken Tyler wrote:
> 
> Anyone have the LinuxPPC 2000 CDs ?
> 
> Any trouble mounting them ?
> 
> Can access them from Amiga but can't mount them under Linux.

I think I read somewhere that they contain a peculiar file system to make it 
boot on all Macs.

You could ask on linuxppc-{dev,user} for details.


Michel


-- 
                               Reboot America.
______________________________________________________________________________
Earthling Michel Dänzer (MrCooper)  \  CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \   member of XFree86, Team *AMIGA*, AUGS

LinuxPPC 2000 CDs

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

Anyone have the LinuxPPC 2000 CDs ?

Any trouble mounting them ?

Can access them from Amiga but can't mount them under Linux.

Ken.
 

Re: CVS commit notice

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

Roman Zippel wrote:

> > > > Looks like CVS puts only its special files explicitly in CVSROOT on
> > > > the
> > > > server side...
> > >
> > > It's a script. Is it executable?
> >
> > Yep, at least when I check it out. I have now set PreservePermissions=yes
> > in CVSROOT/config, could that do the trick?
> 
> I removed it and call perl directly. It's a bit annoying and cvs
> segfaulted sometimes. :(

It did for me once, which caused the repository to remain locked...


> But the script still isn't there...

No, to get it we'd need a support request, either to fix just that or to
replace the whole cvsroot, including Jesper's old one (anyone has time? :)


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

Re: 2.3 and ami_int3

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

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
 }
 
 	/*

Re: CVS commit notice

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

Hi,

> I removed it and call perl directly. It's a bit annoying and cvs
> segfaulted sometimes. :(

And another support request... :-(

bye, Roman
> 

Re: CVS commit notice

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

Hi,

> > > Looks like CVS puts only its special files explicitly in CVSROOT on the
> > > server side...
> > 
> > It's a script. Is it executable?
> 
> Yep, at least when I check it out. I have now set PreservePermissions=yes in
> CVSROOT/config, could that do the trick?

I removed it and call perl directly. It's a bit annoying and cvs
segfaulted sometimes. :(
But the script still isn't there...

bye, Roman

Re: 2.3 and ami_int3

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

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

Re: 2.3 and ami_int3

[Jouko P. <py...@jy...>]

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

Re: 2.3 and ami_int3

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

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

Re: 2.3 and ami_int3

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

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.

Re: 2.3 and ami_int3

[Jouko P. <py...@jy...>]

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

Re: 2.3 and ami_int3

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

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

Re: 2.3 and ami_int3

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

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

Re: 2.3 and ami_int3

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

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.

Re: 2.3 and ami_int3

[Jouko P. <py...@jy...>]

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