linux-apus-devel

Re: 53c770 prob tracked down.

[Rene B. <re...@we...>]

On 2002.10.07 16:08 schneider wrote:
> If i start the kernel from my special linuxbootpartition (fast and just 
> the needed stuff in it), the SCSI driver won´t work.
>  If i boot the AmigaOS 3.9, and start the kernel, the driver works!!!

I also use such a start partition, without problems. No start of AmigaOS 
needed.

> Is there a Initerror at the ppc kernel or the scsi driver??

Some parts of the 53c770 isn't configured by the driver (especially the 
scsi burst mode) and needs to be initialized by the CSPPC-firmware. This 
is normaly done if the Amiga is switched on.
But maybe the different firmware-versions behaves different. As far as I 
know, the newest can be found at:

ftp://ftp.meanmachine.ch/pub/amiga/ppclib

Will be nice if you can check out your version.

> I tried the whole weekend, to get the biest running, lots of rebuilds
> and printks, just to see there is no prob with the 53c770 driver.
> Just booted the wrong partition and started linux anyway... and it works.
> WHY?
> Is there any way to give the 53c770 a seperate irq number?

Don't know. "IRQ_AMIGA_PORTS" is used and is stolen from other 
scsi-drivers.


Ciao, Renè

Re: irqs and last_ipl[2] already set ...

[Rene B. <re...@we...>]

On 2002.10.05 00:27 Ken Tyler wrote:
> 
> 
> On Fri, 4 Oct 2002, Rene Brothuhn wrote:
> 
> > On 2002.10.04 00:52 schneider wrote:
> 
> > > Do i have to take the unused cards out?
> >
> >
> > Normaly not. But I remember, that some of the early A4000(T) was
> delivered
> > with Buster rev. 09 which has some problems in Zorro-III mode. Buster
> rev.
> > 11 was fixed this way (as far as I remember).
> 
> Always thougt my machine had rev 11 but better check.
> 
> http://www.thule.no/haynie/ has lots of info about various buster / Zorro
> problems including one that was nerver fixed.

I can't find informations about Buster/Zorro problems here. Can you tell 
me where exactly it is?


Ciao, Renè

XFree86 4.1.0 and CyberstormPPC

[Giorgio T. <de...@ip...>]

Hello all,

as i said time ago i had problems with XFree86 some still remain
but one i think i have solved:
I had a problem of bad addressing during Xdm (Kdm-Gdm) loading
that trashed all the graphics with these symptoms: background sometimes
trashed, graphics and widgets in the greetings window become invisible
but selectable.
Note that these problems was found also before the CyberstormPPC
firmware upgrading.
After firmware upgrading i have seen that there was some differences between
the PCI addressing declaration in apus_pci.c & pm2fb.c files and what the new
ROM firmware reported.
I attack my dmesg file where is possible to see this adresses difference
and some (i think) non-influent Zorro vs. PCI address space conflicts.

I have tried the modifies below and now seems that this problem is solved:

diff -urN orig/apus_pci.c modif/apus_pci.c
--- orig/apus_pci.c	Sun Oct 28 12:44:01 2001
+++ modif/apus_pci.c	Sun Sep  1 11:46:07 2002
@@ -167,7 +167,9 @@
 	DEFW();
 	writel(CVPPC_FB_APERTURE_ONE, apus_hose->cfg_data + PCI_BASE_ADDRESS_1);
 	DEFW();
-	writel(CVPPC_FB_APERTURE_TWO, apus_hose->cfg_data + PCI_BASE_ADDRESS_2);
+	writel(0xe0800000, apus_hose->cfg_data + PCI_BASE_ADDRESS_2);
+	DEFW();
+	writel(CVPPC_FB_APERTURE_TWO, apus_hose->cfg_data + PCI_BASE_ADDRESS_3);
 	DEFW();
 	writel(CVPPC_ROM_ADDRESS, apus_hose->cfg_data + PCI_ROM_ADDRESS);
 	DEFW();
diff -urN orig/pm2fb.c modif/pm2fb.c
--- orig/pm2fb.c	Tue Aug 20 14:47:29 2002
+++ modif/pm2fb.c	Sun Sep  1 11:47:22 2002
@@ -998,7 +998,8 @@
 		WR32(p->pci_config, PCI_CACHE_LINE_SIZE, 0xff00);
 	WR32(p->pci_config, PCI_BASE_ADDRESS_0, CVPPC_REGS_REGION);
 	WR32(p->pci_config, PCI_BASE_ADDRESS_1, CVPPC_FB_APERTURE_ONE);
-	WR32(p->pci_config, PCI_BASE_ADDRESS_2, CVPPC_FB_APERTURE_TWO);
+	WR32(p->pci_config, PCI_BASE_ADDRESS_2, 0xe0800000);
+	WR32(p->pci_config, PCI_BASE_ADDRESS_3, CVPPC_FB_APERTURE_TWO);
 	WR32(p->pci_config, PCI_ROM_ADDRESS, CVPPC_ROM_ADDRESS);
 	DEFW();
 	WR32(p->pci_config, PCI_COMMAND, 0xef000000 |

I wish to submit these modifies if you think they have "a sense" .

Remaining problems:

Note also that the vterminal exchange problem is still present as i wrote 
time ago. 
The warbled text problem i signaled succedes only in the X text windows as
Xterm or Mozilla and so on. I think this is a driver's limitation because 
with 1024x768x16 resolution this succedes only when the machine is very 
stressed but with 1152x864x16 and over this succedes everytime i open a 
window. With these high resolutions it warbles also the graphics.

Every suggestion is welcome.

Regards,

	Giorgio Terzi

53c770 prob tracked down.

[schneider <sch...@te...>]

If i start the kernel from my special linuxbootpartition (fast and just 
the needed stuff in it), the SCSI driver won´t work.
  If i boot the AmigaOS 3.9, and start the kernel, the driver works!!!
Is there a Initerror at the ppc kernel or the scsi driver??
I tried the whole weekend, to get the biest running, lots of rebuilds
and printks, just to see there is no prob with the 53c770 driver.
Just booted the wrong partition and started linux anyway... and it works.
WHY?
Is there any way to give the 53c770 a seperate irq number?

Axel

ps: i still get those ipl messages...

Re: irqs and last_ipl[2] already set ...

[schneider <sch...@te...>]

Ken Tyler wrote:
> 
> On Fri, 4 Oct 2002, Rene Brothuhn wrote:
> 
> 
>>On 2002.10.04 00:52 schneider wrote:
> 
> 
>>>Do i have to take the unused cards out?
>>
>>
>>Normaly not. But I remember, that some of the early A4000(T) was delivered 
>>with Buster rev. 09 which has some problems in Zorro-III mode. Buster rev. 
>>11 was fixed this way (as far as I remember).
> 
> 
> Always thougt my machine had rev 11 but better check.
> 
> http://www.thule.no/haynie/ has lots of info about various buster / Zorro
> problems including one that was nerver fixed.
> 
> Ken.
> 
> 
Well, i have a buster -11,but the bug is still present.
Netbsd is working proper. Also with amiga os there is no problem.

Axel

Re: irqs and last_ipl[2] already set ...

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

On Fri, 4 Oct 2002, Rene Brothuhn wrote:

> On 2002.10.04 00:52 schneider wrote:

> > Do i have to take the unused cards out?
> 
> 
> Normaly not. But I remember, that some of the early A4000(T) was delivered 
> with Buster rev. 09 which has some problems in Zorro-III mode. Buster rev. 
> 11 was fixed this way (as far as I remember).

Always thougt my machine had rev 11 but better check.

http://www.thule.no/haynie/ has lots of info about various buster / Zorro
problems including one that was nerver fixed.

Ken.

Re: irqs and last_ipl[2] already set ...

[Rene B. <re...@we...>]

On 2002.10.04 00:52 schneider wrote:
> >Rene Brothuhn wrote:
>> 
>> 
>> Hello!
>> 
>> Do you use some other hardware (Zorro-III or Zorro-II boards)?
>> 
> 
> Well, i have an Ariadne, MFC3, IsdnMaster, CyberVision and
> finally a ScandoublerCard.
> 
> Do i have to take the unused cards out?


Normaly not. But I remember, that some of the early A4000(T) was delivered 
with Buster rev. 09 which has some problems in Zorro-III mode. Buster rev. 
11 was fixed this way (as far as I remember).

I have an A4000 with Buster 11 and the 53c770 works fine, but I don't use 
any Zorro card. So maybe if you remove all of your Zorro cards, the SCSI 
deadlocks went away. But maybe not...
It is only an assumption that it has something todo with Buster/Zorro. 
Will be nice if you can test it and look what version of Buster you have.


Ciao, Renè

Re: irqs and last_ipl[2] already set ...

[schneider <sch...@te...>]

 >Rene Brothuhn wrote:
> 
> 
> Hello!
> 
> Do you use some other hardware (Zorro-III or Zorro-II boards)?
> 

Well, i have an Ariadne, MFC3, IsdnMaster, CyberVision and
finally a ScandoublerCard.

Do i have to take the unused cards out?

Axel

Re: irqs and last_ipl[2] already set ...

[Rene B. <re...@we...>]

Hello!

Do you use some other hardware (Zorro-III or Zorro-II boards)?


Ciao, Renè


On 2002.10.02 15:37 schneider wrote:
> I also have the problems with last_ipl and system stop.
> Only the standard ide controller work. I have an A4000T
> and tried the 53c770 driver and the a4000t 53c710.
> 
> Before the system stops (just stands still) i get those ipl
> messages. It seems like an infinite loop.
> 
> So the Kernel irq handling must be broken somewhere?!
> I tried some printk´s but without success.
> 
> Any ideas where to look closer?
> 
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-apus-devel

Re: irqs and last_ipl[2] already set ...

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

Hello,

> > Roman's post from July 24th.

I seemed to have missed a few posts around then.

Is the buggy interrupt hardware a suspected problem or is it a definite on
some hardware combination ?
 
> ...and it should be harmless.

should ? ;)

Ken.

irqs and last_ipl[2] already set ...

[schneider <sch...@te...>]

I also have the problems with last_ipl and system stop.
Only the standard ide controller work. I have an A4000T
and tried the 53c770 driver and the a4000t 53c710.

Before the system stops (just stands still) i get those ipl
messages. It seems like an infinite loop.

So the Kernel irq handling must be broken somewhere?!
I tried some printk´s but without success.

Any ideas where to look closer?

Re: irqs and last_ipl[2] already set ...

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

On Sun, 29 Sep 2002, Alan Buxey wrote:

> Roman's post from July 24th.

Will search it out

> "It's some interrupt event history (positive number for interrupt entry,
> negative for exit). It's printed when it sees unexpected interrupts."

I'll endeavour to decode the output into less cryptic form

Ken.

Re: irqs and last_ipl[2] already set ...

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

Hi,

On Sun, 29 Sep 2002, Alan Buxey wrote:

> > Any ideas on the Last ipl[] messages ?
>
> Roman's post from July 24th.
>
> "It's some interrupt event history (positive number for interrupt entry,
> negative for exit). It's printed when it sees unexpected interrupts."

...and it should be harmless.

bye, Roman

Re: Joystick support

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

On Mon, 30 Sep 2002, [iso-8859-2] Krystian Bac=B3awski wrote:
> I've tried to compile joystick support as a module, and I've found out
> that amiga joystick support in 2.4.18 is completely broken. I've tried =
to
> some how fix it (there's a lot of syntax errors), but there is no
> amijoy_timer procedure! Can anybody take a look at it ?

You may want to take a look at drivers/input/joystick/amijoy.c in 2.5.x.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m6=
8k.org

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

Joystick support

[<cah...@po...>]

Hi there !

I've tried to compile joystick support as a module, and I've found out
that amiga joystick support in 2.4.18 is completely broken. I've tried to
some how fix it (there's a lot of syntax errors), but there is no
amijoy_timer procedure! Can anybody take a look at it ?

Regards
Krystian Baclawski

Re: irqs and last_ipl[2] already set ...

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

hi,

> Any ideas on the Last ipl[] messages ?

Roman's post from July 24th.


"It's some interrupt event history (positive number for interrupt entry,
negative for exit). It's printed when it sees unexpected interrupts."


alan

Re: irqs and last_ipl[2] already set ...

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

On Sun, 29 Sep 2002, Geert Uytterhoeven wrote:

> On Sun, 29 Sep 2002, Ken Tyler wrote:

Hello,

> The main interrupt handler doesn't know for which device the interrupt is
> meant. It just calls all registered device interrupt handlers for that
> interrupt chain with the corresponding dev_id parameter, as passed to
> request_irq().

I eventually figured this out, each drivers interrupt handler gets called
but only with the correct dev_id for that device's handler, from the
irq_desc and ircaction structures.  For each PORTS and EXTERN interrupt,
every handler on that interrupt's list gets 'tried'. 

> How do they handle the side effects on other architectures? Or do they always
> have the 53c710 on its own interrupt line?

I don't know why the 53c7xx driver works for the A4000T and Blizzard
accelerators but not for the A4091.  Probably nothing to do with
interrupts but I have to start (again) somewhere.

Any ideas on the Last ipl[] messages ?

Thanks, Ken.

Re: irqs and last_ipl[2] already set ...

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

On Sun, 29 Sep 2002, Ken Tyler wrote:
> Secondly, does each device drivers's interrupt handler need to check the
> dev_id parameter that's passed to determine if the interrupt is from/for
> that device ?

The main interrupt handler doesn't know for which device the interrupt is
meant. It just calls all registered device interrupt handlers for that
interrupt chain with the corresponding dev_id parameter, as passed to
request_irq().

> (Reading the two interrupt status registers of the 53c710 has side effects
> with or without pending interrupts)

I'm afraid you do have to use the interrupt status registers of the 53c710. How
else to find out that it was the 53c710 or some other device that posted the
interrupt?

How do they handle the side effects on other architectures? Or do they always
have the 53c710 on its own interrupt line?

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

irqs and last_ipl[2] already set ...

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

I'm having yet another go at getting the 53c7xx.c driver to drive my A4091
reliably.  Last time I tried I came to the conclusion it was some
ZORRO3/PPC timing glitch.  As the new 53c770.c UW SCSI driver displays the
same problem, it might not be a timing glitch.

First question, are the kernel messages I see sometimes of the form:

last_ipl[2] already set to 2f, now 2d!
207863: 2 -2 2 -2 2 -2 2 -2 2 -2 2 -2 2 3 -3 2

indicative of some error in interrupt handling ?

Secondly, does each device drivers's interrupt handler need to check the
dev_id parameter that's passed to determine if the interrupt is from/for
that device ?

(Reading the two interrupt status registers of the 53c710 has side effects
with or without pending interrupts)

ken.

FASTATA 1200 driver

[<cah...@po...>]

On Thu, 26 Sep 2002, Roman Zippel wrote:

> Hi,
>=20
> "Krystian Bac=B3awski" wrote:
>=20
> > I don't know how, but my kernel's started booting. I modified kernel as
> > you said:
>=20
> Great. I just committed a change which moves the call to the proper
> location. Could you try this one too (after reverting your changes)?

I'll try. But there's another problem, I've used ide_config_drive_speed in
fastata driver and that procedure also doesn't work without ack_intr...
(so I patched it) I think that this problem will affect us many times so
maybe other solution is needed.

FastATA driver currently changes drive speed and switches to another
register set, but it's really easy to broke that driver (I've managed to
do this with hdparm).

Take a look at it. I know it's not a clean code, it's rather a quick and
dirty hack :)

Here's a part of dmesg:

ide0: FastATA 1200 IDE interface
ide1: FastATA 1200 IDE interface
hda: ST31720A, ATA DISK drive
hda: best pio is 4
hda: current register set is 80da2000
hda: changing speed
hda: changing register set to 00db4000
hda: speed changed
hdc: BCD 16XA CD-ROM, ATAPI CD/DVD-ROM drive
hdc: best pio is 4
hdc: current register set is 80da3000
hdc: changing speed
hdc: changing register set to 00db5000
hdc: speed changed
ide0 at 80db4208 on irq 0x0000000c
ide1 at 80db5208 on irq 0x0000000c (shared with ide0)
hda: 3329424 sectors (1705MB), CHS=3D3303/16/63
hdc: lost interrupt
hdc: lost interrupt
hdc: lost interrupt
hdc: ATAPI 10X CD-ROM drive, 128kB Cache
Uniform CD-ROM driver Revision: 3.12
Partition check:
 hda: RDSK hda1 hda2 hda3 hda4

hda works (writing wasn't tested, reading is only twice as fast as gayle),
hdc wasn't tested.

Regards
Krystian Baclawski

Re: IDE problem source ?

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

hi,

> > I don't know how, but my kernel's started booting. I modified kernel as
> > you said:
> 
> Great. I just committed a change which moves the call to the proper
> location. Could you try this one too (after reverting your changes)?

i didnt even have chance to make the original change
last night - my harddisk died!! :-(

looking to see if i can fix this....i really hope i can..as
there hasnt been a recent backup for ages :-|

alan

Re: IDE problem source ?

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

Hi,

"Krystian Bac=B3awski" wrote:

> I don't know how, but my kernel's started booting. I modified kernel as
> you said:

Great. I just committed a change which moves the call to the proper
location. Could you try this one too (after reverting your changes)?

bye, Roman

CVS Update: 2.3 (branch: trunk)

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

CVSROOT:	/cvsroot/linux-apus
Module name:	2.3
Repository:	2.3/drivers/ide/
Changes by:	zippel@usw-pr-cvs1.	02/09/25 15:24:50

Log message:
  acknowledge interrupt also during probing

Modified files:
      2.3/drivers/ide/:
        ide-probe.c 
  
  Revision      Changes    Path
  1.6           +1 -0      2.3/drivers/ide/ide-probe.c

Re: IDE problem source ?

[<cah...@po...>]

On Wed, 25 Sep 2002, Alan Buxey wrote:

> wow, this is all interesting/great news folks!  I've been away for a couple
> of weeks - but i can shove this into my system and see what comes out
> ---i thought IRQ's may have been down to it - but i'd not had time
> to stick printk's into all of the ide-probe.c

Only about twelve printk's, I've just had luck.

Did you try to use sound in 2.4.18 ? XMMS plays only for first 5 sec :(

Regards
Krystian Baclawski

Re: IDE problem source ?

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

hi,

> > 
> >         __restore_flags(flags); /* local CPU only */
> >         if (hwif->hw.ack_intr && hwif->irq)
> >         {
> >                 hwif->hw.ack_intr(hwif);
> >                 enable_irq(hwif->irq);
> >         }
> 
> Nice!
> 
> You're using an A1200? Probably because gayle_ack_intr_a1200() has to do more
> than gayle_ack_intr_a4000().

wow, this is all interesting/great news folks!  I've been away for a couple
of weeks - but i can shove this into my system and see what comes out
---i thought IRQ's may have been down to it - but i'd not had time
to stick printk's into all of the ide-probe.c

great going guys!

alan