Re: Atari TT

Re: Atari TT

[Geert Uytterhoeven]

On Thu, Jan 5, 2012 at 13:55, Alan Hourihane <alanh@fairlite.co.uk> wrote:
> Linux version 3.1.0-atari-00246-gbff0dc7 (root@server) (gcc version

bff0dc7 = m68k-v3.1. That kernel still has the SCC driver, but it depends on
BROKEN, so you cannot select it.
If you revert 173808aa9203cf752518acd80fde3c9c910ddd0f ("m68k/atari: SCC
- Mark Atari serial driver BROKEN") you can select CONFIG_ATARI_SCC again,
and get a real serial console.

But first the interrupt storm must be fixed.

> unexpected interrupt from 112

That's the vector number, so the actual IRQ number is 112 / 4 = 28, which is
IRQ_TT_MFP_TIMD. Sorry, no clues.

Can you please try a pristine v3.1? The only relevant differences are the
conversion to the genirq framework and the Atari SCC driver.

If that works, I guess it's a regression introduced by the genirq conversion.
Then you can bisect between v3.1 and m68k-v3.1.

BTW, in between 9fa434585e5f6cfeae685505b4cd8465dbab1dff ("m68k/irq:
Add genirq support") and 971ae31663e817a5e5b673d30c7652d9160145f0
("m68k/irq: Remove obsolete m68k irq framework"), genirq support is a config
option that can be turned on or off.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.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

Re: Atari TT

[Andreas Schwab]

Geert Uytterhoeven <geert@linux-m68k.org> writes:

> On Thu, Jan 5, 2012 at 13:55, Alan Hourihane <alanh@fairlite.co.uk> wrote:
>> Linux version 3.1.0-atari-00246-gbff0dc7 (root@server) (gcc version
>
> bff0dc7 = m68k-v3.1. That kernel still has the SCC driver, but it depends on
> BROKEN, so you cannot select it.
> If you revert 173808aa9203cf752518acd80fde3c9c910ddd0f ("m68k/atari: SCC
> - Mark Atari serial driver BROKEN") you can select CONFIG_ATARI_SCC again,
> and get a real serial console.
>
> But first the interrupt storm must be fixed.
>
>> unexpected interrupt from 112
>
> That's the vector number, so the actual IRQ number is 112 / 4 = 28, which is
> IRQ_TT_MFP_TIMD. Sorry, no clues.

This irq is used for the timer that generates the clock for the MFP
serial port.  It should really stay disabled.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Atari TT

[Alan Hourihane]

On 05/01/12 14:42, Geert Uytterhoeven wrote:
> On Thu, Jan 5, 2012 at 13:55, Alan Hourihane <alanh@fairlite.co.uk> wrote:
>> Linux version 3.1.0-atari-00246-gbff0dc7 (root@server) (gcc version
> bff0dc7 = m68k-v3.1. That kernel still has the SCC driver, but it depends on
> BROKEN, so you cannot select it.
> If you revert 173808aa9203cf752518acd80fde3c9c910ddd0f ("m68k/atari: SCC
> - Mark Atari serial driver BROKEN") you can select CONFIG_ATARI_SCC again,
> and get a real serial console.
>
> But first the interrupt storm must be fixed.
>
>> unexpected interrupt from 112
> That's the vector number, so the actual IRQ number is 112 / 4 = 28, which is
> IRQ_TT_MFP_TIMD. Sorry, no clues.

It's worth enhancing that message then as the NR_IRQs reported was 72.
And it really confused me that 112 appeared.

Maybe...

"unexpected interrupt from 28, vector 112" ?

> Can you please try a pristine v3.1? The only relevant differences are the
> conversion to the genirq framework and the Atari SCC driver.

Will do.

> If that works, I guess it's a regression introduced by the genirq conversion.
> Then you can bisect between v3.1 and m68k-v3.1.
>
> BTW, in between 9fa434585e5f6cfeae685505b4cd8465dbab1dff ("m68k/irq:
> Add genirq support") and 971ae31663e817a5e5b673d30c7652d9160145f0
> ("m68k/irq: Remove obsolete m68k irq framework"), genirq support is a config
> option that can be turned on or off.
>

O.k. thanks.

Alan.

Re: Atari TT

[Alan Hourihane]

On 05/01/12 14:42, Geert Uytterhoeven wrote:
> On Thu, Jan 5, 2012 at 13:55, Alan Hourihane <alanh@fairlite.co.uk> wrote:
>> Linux version 3.1.0-atari-00246-gbff0dc7 (root@server) (gcc version
> bff0dc7 = m68k-v3.1. That kernel still has the SCC driver, but it depends on
> BROKEN, so you cannot select it.
> If you revert 173808aa9203cf752518acd80fde3c9c910ddd0f ("m68k/atari: SCC
> - Mark Atari serial driver BROKEN") you can select CONFIG_ATARI_SCC again,
> and get a real serial console.
>
> But first the interrupt storm must be fixed.
>
>> unexpected interrupt from 112
> That's the vector number, so the actual IRQ number is 112 / 4 = 28, which is
> IRQ_TT_MFP_TIMD. Sorry, no clues.
>
> Can you please try a pristine v3.1? The only relevant differences are the
> conversion to the genirq framework and the Atari SCC driver.
>
> If that works, I guess it's a regression introduced by the genirq conversion.
> Then you can bisect between v3.1 and m68k-v3.1.
>
No it didn't work. Same problem.

Linux version 3.1.7-atari (root@server) (gcc version 4.5.3 (Gentoo
4.5.3-r1 p1.0, pie-0.4.5) ) #1 Thu Jan 5 18:57:55 GMT 2012
console [debug0] enabled
Atari hardware found: TT_SHIFTER ST_MFP TT_MFP TT_SCSI_DMA TT_SCSI
YM2149 PCM SCC_DMA SCC VME SCU MICROWIRE TT_CLK FDC_SPEED ACSI
Ignoring memory chunk at 0x0:0x400000 before the first chunk
Fix your bootloader or use a memfile to make use of this area!
On node 0 totalpages: 32768
free_area_init_node: node 0, pgdat 003159a8, node_mem_map 0034e000
  DMA zone: 288 pages used for memmap
  DMA zone: 0 pages reserved
  DMA zone: 32480 pages, LIFO batch:7
pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
pcpu-alloc: [0] 0
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 32480
Kernel command line: console=tty fb=false video=atafb:ttmid debug=ser2
BOOT_IMAGE=vmlinux.gz
PID hash table entries: 512 (order: -1, 2048 bytes)
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 125372k/125372k available (2476k kernel code, 3112k data, 112k init)
unexpected interrupt from 112
unexpected interrupt from 112
unexpected interrupt from 112
unexpected interrupt from 112
unexpected interrupt from 112
unexpected interrupt from 112
unexpected interrupt from 112
unexpected interrupt from 112
unexpected interrupt from 112
unexpected interrupt from 112
unexpected interrupt from 112
unexpected interrupt from 112
unexpected interrupt from 112
unexpected interrupt from 112
unexpected interrupt from 112
unexpected interrupt from 112
unexpected interrupt from 112
unexpected interrupt from 112
unexpected interrupt from 112
unexpected interrupt from 112
unexpected interrupt from 112
unexpected interrupt from 112
unexpected interrupt from 112
unexpected interrupt from 112

Alan.

Re: Atari TT

[Alan Hourihane]

On 05/01/12 15:49, Andreas Schwab wrote:
> Geert Uytterhoeven <geert@linux-m68k.org> writes:
>
>> On Thu, Jan 5, 2012 at 13:55, Alan Hourihane <alanh@fairlite.co.uk> wrote:
>>> Linux version 3.1.0-atari-00246-gbff0dc7 (root@server) (gcc version
>> bff0dc7 = m68k-v3.1. That kernel still has the SCC driver, but it depends on
>> BROKEN, so you cannot select it.
>> If you revert 173808aa9203cf752518acd80fde3c9c910ddd0f ("m68k/atari: SCC
>> - Mark Atari serial driver BROKEN") you can select CONFIG_ATARI_SCC again,
>> and get a real serial console.
>>
>> But first the interrupt storm must be fixed.
>>
>>> unexpected interrupt from 112
>> That's the vector number, so the actual IRQ number is 112 / 4 = 28, which is
>> IRQ_TT_MFP_TIMD. Sorry, no clues.
> This irq is used for the timer that generates the clock for the MFP
> serial port.  It should really stay disabled.
>

Could these spurious interrupts be generated by the debug path, because
I'm now using it to output debug data ?

Alan.

Re: Atari TT

[Geert Uytterhoeven]

On Thu, Jan 5, 2012 at 20:02, Alan Hourihane <alanh@fairlite.co.uk> wrote:
>>> unexpected interrupt from 112
>> That's the vector number, so the actual IRQ number is 112 / 4 = 28, which is
>> IRQ_TT_MFP_TIMD. Sorry, no clues.
>>
>> Can you please try a pristine v3.1? The only relevant differences are the
>> conversion to the genirq framework and the Atari SCC driver.
>>
>> If that works, I guess it's a regression introduced by the genirq conversion.
>> Then you can bisect between v3.1 and m68k-v3.1.
>>
> No it didn't work. Same problem.

That's bad. So most probably it's been broken on TT for a long time.
AFAIK Atari receives most testing on (emulated -- ARAnyM) Falcon.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.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

Re: Atari TT

[Andreas Schwab]

Alan Hourihane <alanh@fairlite.co.uk> writes:

> Could these spurious interrupts be generated by the debug path, because
> I'm now using it to output debug data ?

None of the debug devices are touching tt_mfp (ser2 uses the SCC, and
ser1 uses st_mfp).

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Atari TT

[Thorsten Glaser]

Geert Uytterhoeven dixit:

>On Thu, Jan 5, 2012 at 20:02, Alan Hourihane <alanh@fairlite.co.uk> wrote:
>>>> unexpected interrupt from 112
>>> That's the vector number, so the actual IRQ number is 112 / 4 = 28, which is
>>> IRQ_TT_MFP_TIMD. Sorry, no clues.

>That's bad. So most probably it's been broken on TT for a long time.
>AFAIK Atari receives most testing on (emulated -- ARAnyM) Falcon.

Ouch. Nothing on this? gemini8 (Bcc’d) reported the same in IRC
using vmlinuz-3.8.0-rc3+m68k-queue+atari-84299-g3f4758a which I
cross-built earlier.

Does anyone have an idea how to help debugging that? I’m sure
gemini8 and, probably, Alan wouldn’t mind booting test kernels.

00:32 < gemini8> Ok, guys. I'm trying to run mirabilos' vmlinuz-3.8.0-rc3+m68k-queue+atari-84299-g3f4758a on my
                 TT. Bootstrap unpacks the kernel, kernel says something about booting, I'm getting loads of
                 colourful pixels on my screen, and the floppy starts to blink.
00:32 < gemini8> That's it.
00:32 < gemini8> Anything I can specify in bootargs to maybe get another result?
00:33 < gemini8> It's the same with resolution I adjust in bootargs btw.
00:38 < ij> do you have serial/null modem cable? then try to add debug=ser to the kernel options
00:40 < gemini8> In theory yes.
00:40 < gemini8> Will have to find me a terminal though.
00:43 < ij> at least you can then see what's going wrong... I just did the same on my Amiga
00:58 < gemini8> https://dl.dropbox.com/u/32922157/linux-m68k/linux-m68k-on-tt030.txt

No idea whether adding (or not adding) -s makes a difference.
Another thing that could be tried (wrt. the video) is the
stram_reserve(IIRC?) option? Michael?

bye,
//mirabilos
-- 
„nein: BerliOS und Sourceforge sind Plattformen für Projekte, github ist
eine Plattform für Einzelkämpfer“
	-- dieses Zitat ist ein Beweis dafür, daß auch ein blindes Huhn
	   mal ein Korn findet, bzw. – in diesem Fall – Recht haben kann

Re: Atari TT

[Michael Schmitz]

Thorsten,

> >Does the other kernel show any boot progress on the screen at all, after the
> >bootstrap has finished loading and passed control to the kernel? 
> 
> Coloured pixels.

If the other kernel (nonet) shows a proper boot screen, that's a kernel size
issue. 

On the other hand: 

> 
> >Can you send me the contents of arch/m68k/atari/config.c and
> >arch/m68k/atari/atariints.c from the patched source tree you used for these
> >kernels? 
> 
> Sure:

That does not include my more recent patches to the interrupt code. I
suspect you may be using the atari_ethernec driver instead of the generic ne
one as well. I'll check your kernel image to see what it does use. 

The ne.c network driver does not appear to tolerate interrupts arriving before 
the device has been configured, at least in the early boot phases. I'm uncertain
whether it would work even with my latest patches applied - maybe I can find
some time on the weekend to test that. 

Geert: is there some way for kernel network drivers to figure out whether the
network subsystem has been initialized, and hold off interrupt processing
before that time? I'm using 'if (netif_running(dev))' in atari_ethernec but
that does not appear to prevent the lockup. 

Cheers,

	Michael
 

Re: Atari TT

[Geert Uytterhoeven]

On Thu, Jan 24, 2013 at 9:20 PM, Michael Schmitz
<schmitz@mail.biophys.uni-duesseldorf.de> wrote:
> The ne.c network driver does not appear to tolerate interrupts arriving before
> the device has been configured, at least in the early boot phases. I'm uncertain
> whether it would work even with my latest patches applied - maybe I can find
> some time on the weekend to test that.

Stupid ISA-only driver without IRQ sharing support...

The hydra and zorro8390 driver should handle that case fine, as interrupts are
shared on Amiga.

> Geert: is there some way for kernel network drivers to figure out whether the
> network subsystem has been initialized, and hold off interrupt processing
> before that time? I'm using 'if (netif_running(dev))' in atari_ethernec but
> that does not appear to prevent the lockup.

Doesn't the driver know when it's configured?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.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

Re: Atari TT

[Thorsten Glaser]

Michael Schmitz dixit:

>If the other kernel (nonet) shows a proper boot screen, that's a kernel size
>issue. 

They have very few difference, though.

>That does not include my more recent patches to the interrupt code. I
>suspect you may be using the atari_ethernec driver instead of the generic ne
>one as well. I'll check your kernel image to see what it does use. 

I’m using Geert’s m68k-queue branch plus Alan’s patch.
Is that not correct?

And yes, of course I selected the EtherNAT and EtherNEC drivers.

bye,
//mirabilos
-- 
„nein: BerliOS und Sourceforge sind Plattformen für Projekte, github ist
eine Plattform für Einzelkämpfer“
	-- dieses Zitat ist ein Beweis dafür, daß auch ein blindes Huhn
	   mal ein Korn findet, bzw. – in diesem Fall – Recht haben kann

Re: Atari TT

[Michael Schmitz]

Geert,

> > The ne.c network driver does not appear to tolerate interrupts arriving before
> > the device has been configured, at least in the early boot phases. I'm uncertain
> > whether it would work even with my latest patches applied - maybe I can find
> > some time on the weekend to test that.
> 
> Stupid ISA-only driver without IRQ sharing support...

Indeed - but that may be my old hacked driver which does have IRQ sharing. 

> The hydra and zorro8390 driver should handle that case fine, as interrupts are
> shared on Amiga.

But these will only generate interrupts if the card has something to send,
or receive has been enabled. The timer polling seems to be the problem here. 
 
> > Geert: is there some way for kernel network drivers to figure out whether the
> > network subsystem has been initialized, and hold off interrupt processing
> > before that time? I'm using 'if (netif_running(dev))' in atari_ethernec but
> > that does not appear to prevent the lockup.
> 
> Doesn't the driver know when it's configured?

It does - it will spit out 'interrupt from stopped card' in that case.
That's the last message I see from the kernel before it locks up (haven't
tried in a while, at least that's what happened a year or two ago). The same
still happens when loading the driver as a module - a single message of the
kind, nothing more (but the kernel keeps running).

I would have thought netif_running(dev) returns false before the device has
been started, but that's wrong, apparently. 

Cheers,

	Michael

Re: Atari TT

[Geert Uytterhoeven]

On Thu, Jan 24, 2013 at 10:48 PM, Michael Schmitz
<schmitz@mail.biophys.uni-duesseldorf.de> wrote:
>> > The ne.c network driver does not appear to tolerate interrupts arriving before
>> > the device has been configured, at least in the early boot phases. I'm uncertain
>> > whether it would work even with my latest patches applied - maybe I can find
>> > some time on the weekend to test that.
>>
>> Stupid ISA-only driver without IRQ sharing support...
>
> Indeed - but that may be my old hacked driver which does have IRQ sharing.
>
>> The hydra and zorro8390 driver should handle that case fine, as interrupts are
>> shared on Amiga.
>
> But these will only generate interrupts if the card has something to send,
> or receive has been enabled. The timer polling seems to be the problem here.

The point of IRQ sharing is that multiple devices use the same interrupt line.
So it's about _another_ device generating the interrupt.
Both zorro8390 and hydra use IRQ_AMIGA_PORTS. As does Gayle IDE.
Hence if the IDE hardware on A4000 triggers and interrupt, the
interrupt handler of
zorro8390 and hydra will be called as well. Since I'm not aware of any issues
with zorro8390 and hydra in A4000, I assume zorro8390 and hydra handle this,
while ne doesn't.

>> > Geert: is there some way for kernel network drivers to figure out whether the
>> > network subsystem has been initialized, and hold off interrupt processing
>> > before that time? I'm using 'if (netif_running(dev))' in atari_ethernec but
>> > that does not appear to prevent the lockup.
>>
>> Doesn't the driver know when it's configured?
>
> It does - it will spit out 'interrupt from stopped card' in that case.
> That's the last message I see from the kernel before it locks up (haven't
> tried in a while, at least that's what happened a year or two ago). The same
> still happens when loading the driver as a module - a single message of the
> kind, nothing more (but the kernel keeps running).
>
> I would have thought netif_running(dev) returns false before the device has
> been started, but that's wrong, apparently.

How does zorro8390 and hydra handle it? They use __ei_interrupt, while
ne uses eip_interrupt, but the latter just calls the former?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.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

Re: Atari TT

[Geert Uytterhoeven]

On Thu, Jan 24, 2013 at 9:50 PM, Thorsten Glaser <tg@mirbsd.de> wrote:
> I’m using Geert’s m68k-queue branch plus Alan’s patch.

JFYI that one is rebased on every rc. It's actual source tree is always
identical to master, but it has "clean" commits against Linus' tree, unlike
master.

If you don't want to run rc kernels, you want to use m68k-v3.x (with x = 7
currently) instead.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.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

Re: Atari TT

[Michael Schmitz]

Geert,

> >> The hydra and zorro8390 driver should handle that case fine, as interrupts are
> >> shared on Amiga.
> >
> > But these will only generate interrupts if the card has something to send,
> > or receive has been enabled. The timer polling seems to be the problem here.
> 
> The point of IRQ sharing is that multiple devices use the same interrupt line.
> So it's about _another_ device generating the interrupt.

You're right of course. 

> Both zorro8390 and hydra use IRQ_AMIGA_PORTS. As does Gayle IDE.
> Hence if the IDE hardware on A4000 triggers and interrupt, the
> interrupt handler of
> zorro8390 and hydra will be called as well. Since I'm not aware of any issues
> with zorro8390 and hydra in A4000, I assume zorro8390 and hydra handle this,
> while ne doesn't.

Turns out ne does - atari_ethernec did't. I could boot a kernel with ne
builtin, got the same message as always but this time it didn't hang:

NE*000 ethercard probe at 0x300:
ne ne (unregistered net_device): interrupt from stopped card
00:00:e8:5d:58:cd
eth0: RTL8019 found at 0x300, using IRQ 64.
 sda: AHDI sda1 sda2 sda3 XGM< sda4 sda5 >

That's good enough for me. 

> 
> >> > Geert: is there some way for kernel network drivers to figure out whether the
> >> > network subsystem has been initialized, and hold off interrupt processing
> >> > before that time? I'm using 'if (netif_running(dev))' in atari_ethernec but
> >> > that does not appear to prevent the lockup.
> >>
> >> Doesn't the driver know when it's configured?
> >
> > It does - it will spit out 'interrupt from stopped card' in that case.
> > That's the last message I see from the kernel before it locks up (haven't
> > tried in a while, at least that's what happened a year or two ago). The same
> > still happens when loading the driver as a module - a single message of the
> > kind, nothing more (but the kernel keeps running).
> >
> > I would have thought netif_running(dev) returns false before the device has
> > been started, but that's wrong, apparently.
> 
> How does zorro8390 and hydra handle it? They use __ei_interrupt, while
> ne uses eip_interrupt, but the latter just calls the former?

I'll have to check that - as I said, it seems to have gone away with the
current ne driver. 

Baffled,

	Michael