mac68k serial

mac68k serial

[flameman mayer]

hi,
I'm Carlo Pisani, alias "flameman", and i'm running this little
project: gentoo-m68k @ applem68k-LC475

( http://elinux.org/Mac68k-Flameman )


i'm working with kernel-2.6.27 and i have this issue

macserial kernel panic

unable to handle kernel NULL pointer de reference at virtual address
000004 modules linked in: m68k_handle_int+0x1c/0x36

call trace mac_scc_dispatch+0x3a/0x40 auto_irqhandler_fixup+0x4/0x6

kermel panic



also, i hacked the "emile-0.12" sources to build a monitor able to
serially talk: it works for both the 2 LC475 serial lines :P

is there anything about serial support for linux-m68k ?

regards

Re: mac68k serial

[Brad Boyer]

On Tue, Jan 13, 2009 at 09:49:59PM +0000, flameman mayer wrote:
> I'm Carlo Pisani, alias "flameman", and i'm running this little
> project: gentoo-m68k @ applem68k-LC475
> 
> ( http://elinux.org/Mac68k-Flameman )

That's a good summary of a lot of history, but most of us don't think
much about the 2.2 kernel anymore. It's nice to have all of that in
one place for browsing.

> i'm working with kernel-2.6.27 and i have this issue
> 
> macserial kernel panic
> 
> unable to handle kernel NULL pointer de reference at virtual address
> 000004 modules linked in: m68k_handle_int+0x1c/0x36
> 
> call trace mac_scc_dispatch+0x3a/0x40 auto_irqhandler_fixup+0x4/0x6
> 
> also, i hacked the "emile-0.12" sources to build a monitor able to
> serially talk: it works for both the 2 LC475 serial lines :P
> 
> is there anything about serial support for linux-m68k ?

The real driver for the serial ports on m68k Macintosh systems got
removed from the tree a long time ago and has not been replaced as
of this time. However, we still register mac_scc_dispatch as an
interrupt handler for the line that the SCC uses. This looks like
you got an interrupt for the serial chip and the interrupt code
got confused trying to dispatch to nothing. I've never seen it
happen, but it does look like that would be the expected behavior
of the current code.

It's on my list to fix, but I honestly haven't had much time to
work on it. My plan is to either share or copy pmac_zilog.c which
is the driver for the serial on PowerMacs rather than start from
the Atari driver as mentioned in the web page above. It's not only
the same chip but attached to the system in mostly the same way.

	Brad Boyer
	flar@allandria.com

Re: mac68k serial

[Finn Thain]

On Tue, 13 Jan 2009, Brad Boyer wrote:

> On Tue, Jan 13, 2009 at 09:49:59PM +0000, flameman mayer wrote:
>... 
> > i'm working with kernel-2.6.27 and i have this issue
> > 
> > macserial kernel panic
> > 
> > unable to handle kernel NULL pointer de reference at virtual address
> > 000004 modules linked in: m68k_handle_int+0x1c/0x36
> > 
> > call trace mac_scc_dispatch+0x3a/0x40 auto_irqhandler_fixup+0x4/0x6
> > 
> > also, i hacked the "emile-0.12" sources to build a monitor able to
> > serially talk: it works for both the 2 LC475 serial lines :P
> > 
> > is there anything about serial support for linux-m68k ?
> 
> The real driver for the serial ports on m68k Macintosh systems got 
> removed from the tree a long time ago and has not been replaced as of 
> this time. However, we still register mac_scc_dispatch as an interrupt 
> handler for the line that the SCC uses. This looks like you got an 
> interrupt for the serial chip and the interrupt code got confused trying 
> to dispatch to nothing. I've never seen it happen, but it does look like 
> that would be the expected behavior of the current code.

I've seen it happen. You should avoid sending anything to the mac serial 
port. But you can still capture kernel messages from the mac serial port 
without triggering the panic.

> 
> It's on my list to fix, but I honestly haven't had much time to work on 
> it. My plan is to either share or copy pmac_zilog.c which is the driver 
> for the serial on PowerMacs rather than start from the Atari driver as 
> mentioned in the web page above. It's not only the same chip but 
> attached to the system in mostly the same way.

It's on my list, too. But above it are frame buffer, Nubus, SCSI and PMU 
issues.

Finn

> 
> 	Brad Boyer
> 	flar@allandria.com
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: mac68k serial

[Michael Schmitz]

Hi,

> > > 000004 modules linked in: m68k_handle_int+0x1c/0x36
> > > 
> > > call trace mac_scc_dispatch+0x3a/0x40 auto_irqhandler_fixup+0x4/0x6
> > > 
> > > also, i hacked the "emile-0.12" sources to build a monitor able to
> > > serially talk: it works for both the 2 LC475 serial lines :P
> > > 
> > > is there anything about serial support for linux-m68k ?
> > 
> > The real driver for the serial ports on m68k Macintosh systems got 
> > removed from the tree a long time ago and has not been replaced as of 
> > this time. However, we still register mac_scc_dispatch as an interrupt 
> > handler for the line that the SCC uses. This looks like you got an 
> > interrupt for the serial chip and the interrupt code got confused trying 
> > to dispatch to nothing. I've never seen it happen, but it does look like 
> > that would be the expected behavior of the current code.
> 
> I've seen it happen. You should avoid sending anything to the mac serial 
> port. But you can still capture kernel messages from the mac serial port 
> without triggering the panic.

Can't you add an empty SCC dispatch that just returns, or will that cause an 
interrupt storm? 

> > It's on my list to fix, but I honestly haven't had much time to work on 
> > it. My plan is to either share or copy pmac_zilog.c which is the driver 
> > for the serial on PowerMacs rather than start from the Atari driver as 
> > mentioned in the web page above. It's not only the same chip but 
> > attached to the system in mostly the same way.
> 
> It's on my list, too. But above it are frame buffer, Nubus, SCSI and PMU 
> issues.

I'll get to working on simplifying the Atari SCC driver eventually, but that's 
not top of my list either. I could give mac_scc a shot after that (starting 
from pmac_zilog). 

	Michael

Falcon IDE breakage

[Michael Schmitz]

Bartlomiej,

your commit 5b31f855f10d0053e738baa6d91fb6a3fad35119 (introduction of IDE lock 
helpers) breaks Atari Falcon IDE on the first request going out to the drive, if 
I remove the request_irq() call from ide-probe.c (as it should be).

ide_get_lock has the important side effect of registering the IDE interrupt as 
the current valid interrupt handler for the 'shared' ST-DMA  interrupt dispatch. 
The lock must be held for all operations on the host that expect an interrupt to 
be taken.

In the current form, the lock helpers only register the interrupt if the 
IDE_HFLAG_SERIALIZE host flag is set. This does not appear to be the case for 
the Falcon IDE host. 

Consequently, the lock does not seem to be taken at all times when IDE should be 
passed the interrupt. If I remove the extra request_irq() in ide-probe.c, the 
first request reading from the drive times out with hda: lost interrupt.

Even if request_irq() is called in ide-probe.c for Falcon, the current code 
would open races with other users of the ST-DMA lock (in a worse way than the 
previous code did, i.e. by registering the IDE interrupt handler in addition to 
the ST-DMA dispatch for the IDE/SCSI/DMA/Floppy interrupt). I am currently 
working to eliminate such races in the interaction of IDE and SCSI drivers, and 
the duplicated interrupt has been shown up as a suspect there (incidentially, 
that's why the problem never showed in Geert's ARAnyM tests).

Can you make sure the IDE_HFLAG_SERIALIZE is set for Falcon IDE, or the 
problematic test is removed in that case?

Thanks,

	Michael

Re: Falcon IDE breakage

[Geert Uytterhoeven]

On Sat, 17 Jan 2009, Michael Schmitz wrote:
> your commit 5b31f855f10d0053e738baa6d91fb6a3fad35119 (introduction of IDE lock 
> helpers) breaks Atari Falcon IDE on the first request going out to the drive, if 
> I remove the request_irq() call from ide-probe.c (as it should be).

I assume this is on real hardware, as I didn't notice on ARAnyM?

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: Falcon IDE breakage

[Michael Schmitz]

> On Sat, 17 Jan 2009, Michael Schmitz wrote:
> > your commit 5b31f855f10d0053e738baa6d91fb6a3fad35119 (introduction of IDE lock 
> > helpers) breaks Atari Falcon IDE on the first request going out to the drive, if 
> > I remove the request_irq() call from ide-probe.c (as it should be).
> 
> I assume this is on real hardware, as I didn't notice on ARAnyM?

No, this was on ARAnyM (my git tree had the IDE irq request #ifdef'ed out for a 
while now). I'm sure it would work the same on hardware. 

Did you still get the IDE driver to work after taking out request_irq in 
ide-probe?

diff --git a/drivers/ide/ide-probe.c b/drivers/ide/ide-probe.c
index 0ccbb44..1571ab7 100644
--- a/drivers/ide/ide-probe.c
+++ b/drivers/ide/ide-probe.c
@@ -968,8 +968,10 @@ static int init_irq (ide_hwif_t *hwif)
        if (io_ports->ctl_addr)
                hwif->tp_ops->set_irq(hwif, 1);
 
+#if !defined(CONFIG_BLK_DEV_FALCON_IDE) && !defined(CONFIG_BLK_DEV_FALCON_IDE_M
        if (request_irq(hwif->irq, &ide_intr, sa, hwif->name, hwif))
                goto out_up;
+#endif
 
        if (!hwif->rqsize) {
                if ((hwif->host_flags & IDE_HFLAG_NO_LBA48) ||

If so, do you perchance have two IDE drivers defined in the ARAnyM config file?

	Michael

Re: Falcon IDE breakage [patch]

[Michael Schmitz]

Hi,

> > your commit 5b31f855f10d0053e738baa6d91fb6a3fad35119 (introduction of IDE lock 
> > helpers) breaks Atari Falcon IDE on the first request going out to the drive, if 
> > I remove the request_irq() call from ide-probe.c (as it should be).
> 
> I assume this is on real hardware, as I didn't notice on ARAnyM?

Followup: never mind, I found out that this patch fixes the problem for me:
(NB: still on ARAnyM, having two IDE drivers didn't matter, and I still have to 
test the interaction of new IDE locking with SCSI)

Any other side effects of IDE_HFLAG_SERIALIZE ??

(Actually I realize I could have stuck the flag in 
falconide_port_info.host_flags instead - works just as well. Pick whatever suits 
the IDE guys best)

	Michael

[m68k] Falcon IDE: always serialize, in order to force execution of 
       ide_get_lock() and friends.

Signed-off-By: Michael Schmitz <schmitz@debian.org>
---
diff --git a/drivers/ide/falconide.c b/drivers/ide/falconide.c
index a5ba820..7223dc3 100644
--- a/drivers/ide/falconide.c
+++ b/drivers/ide/falconide.c
@@ -132,6 +132,8 @@ static int __init falconide_init(void)
                goto err;
        }
 
+       host->host_flags |= IDE_HFLAG_SERIALIZE;
+
        ide_get_lock(NULL, NULL);
        rc = ide_host_register(host, &falconide_port_info, hws);
        ide_release_lock();

Re: Falcon IDE breakage [patch]

[Bartlomiej Zolnierkiewicz]

On Sunday 18 January 2009, Michael Schmitz wrote:
> Hi,
> 
> > > your commit 5b31f855f10d0053e738baa6d91fb6a3fad35119 (introduction of IDE lock 
> > > helpers) breaks Atari Falcon IDE on the first request going out to the drive, if 
> > > I remove the request_irq() call from ide-probe.c (as it should be).
> > 
> > I assume this is on real hardware, as I didn't notice on ARAnyM?
> 
> Followup: never mind, I found out that this patch fixes the problem for me:
> (NB: still on ARAnyM, having two IDE drivers didn't matter, and I still have to 
> test the interaction of new IDE locking with SCSI)

I applied your patch, thanks.

> Any other side effects of IDE_HFLAG_SERIALIZE ??

Nope.

> (Actually I realize I could have stuck the flag in 
> falconide_port_info.host_flags instead - works just as well. Pick whatever suits 
> the IDE guys best)

OK, I made this fixup while merging the patch:

From: Michael Schmitz <schmitz@biophys.uni-duesseldorf.de>
Subject: ide: fix Falcon IDE breakage

[m68k] Falcon IDE: always serialize, in order to force execution of
       ide_get_lock() and friends.

Signed-off-By: Michael Schmitz <schmitz@debian.org>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
[bart: set flag in falconide_port_info instead of falconide_init()]
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
 drivers/ide/falconide.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: b/drivers/ide/falconide.c
===================================================================
--- a/drivers/ide/falconide.c
+++ b/drivers/ide/falconide.c
@@ -82,7 +82,7 @@ static const struct ide_tp_ops falconide
 
 static const struct ide_port_info falconide_port_info = {
 	.tp_ops			= &falconide_tp_ops,
-	.host_flags		= IDE_HFLAG_NO_DMA,
+	.host_flags		= IDE_HFLAG_NO_DMA | IDE_HFLAG_SERIALIZE,
 };
 
 static void __init falconide_setup_ports(hw_regs_t *hw)
\0

[PATCH 1/3] m68k: section mismatch fixes: EtherNAT

[Michael Schmitz]

Hi Geert,

a couple of section mismatch fixes that piled up in my tree:

drivers/net/atari_91C111.c (this mail)
sound/oss/dmasound/dmasound_atari.c 
drivers/scsi/atari_NCR5380.c
drivers/scsi/atari_scsi.c

Before they get lost in the mists of git history ...

commit 9418e1ee384d69065c5251d310be97f431668ddb
Author: Michael Schmitz <schmitz@xplor.waratah.dyndns.org>
Date:   Fri Jan 2 08:04:23 2009 +0100

    [m68k] section mismatch fixes: add __init annotation
    
    Signed-off-by: Michael Schmitz <schmitz@debian.org>
---
diff --git a/drivers/net/atari_91C111.c b/drivers/net/atari_91C111.c
index c441779..4d4bf61 100644
--- a/drivers/net/atari_91C111.c
+++ b/drivers/net/atari_91C111.c
@@ -2161,7 +2161,7 @@ static void smc_release_datacs(struct platform_device *pdev, struct net_device *
  *	0 --> there is a device
  *	anything else, error
  */
-static int smc_drv_probe(struct platform_device *pdev)
+static int __init smc_drv_probe(struct platform_device *pdev)
 {
 	struct smc91x_platdata *pd = pdev->dev.platform_data;
 	struct smc_local *lp;

[PATCH 2/3] m68k: section mismatch fixes: DMAsound

[Michael Schmitz]

Part 2: DMAsound driver

commit 277d9bd7a6198e50fdaa841d3383a46a5cf2d185
Author: Michael Schmitz <schmitz@xplor.waratah.dyndns.org>
Date:   Fri Jan 2 08:06:17 2009 +0100

    [m68k] section mismatch fixes: add __initdata to driver presets struct
    
    Signed-off-By: Michael Schmitz <schmitz@debian.org>
---
diff --git a/sound/oss/dmasound/dmasound_atari.c b/sound/oss/dmasound/dmasound_atari.c
index 4d45bd6..43b10b1 100644
--- a/sound/oss/dmasound/dmasound_atari.c
+++ b/sound/oss/dmasound/dmasound_atari.c
@@ -1523,7 +1523,7 @@ static SETTINGS def_soft = {
 	.speed	= 8000
 } ;
 
-static MACHINE machTT = {
+static __initdata MACHINE machTT = {
 	.name		= "Atari",
 	.name2		= "TT",
 	.owner		= THIS_MODULE,
@@ -1552,7 +1552,7 @@ static MACHINE machTT = {
 	.capabilities	=  DSP_CAP_BATCH	/* As per SNDCTL_DSP_GETCAPS */
 };
 
-static MACHINE machFalcon = {
+static __initdata MACHINE machFalcon = {
 	.name		= "Atari",
 	.name2		= "FALCON",
 	.dma_alloc	= AtaAlloc,

Re: [PATCH 2/3] m68k: section mismatch fixes: DMAsound

[Geert Uytterhoeven]

On Sun, 18 Jan 2009, Michael Schmitz wrote:
> commit 277d9bd7a6198e50fdaa841d3383a46a5cf2d185
> Author: Michael Schmitz <schmitz@xplor.waratah.dyndns.org>
> Date:   Fri Jan 2 08:06:17 2009 +0100
> 
>     [m68k] section mismatch fixes: add __initdata to driver presets struct

I don't get section mismatch warnings for dmasound_atari?

>     Signed-off-By: Michael Schmitz <schmitz@debian.org>
> ---
> diff --git a/sound/oss/dmasound/dmasound_atari.c b/sound/oss/dmasound/dmasound_atari.c
> index 4d45bd6..43b10b1 100644
> --- a/sound/oss/dmasound/dmasound_atari.c
> +++ b/sound/oss/dmasound/dmasound_atari.c
> @@ -1523,7 +1523,7 @@ static SETTINGS def_soft = {
>  	.speed	= 8000
>  } ;
>  
> -static MACHINE machTT = {
> +static __initdata MACHINE machTT = {
>  	.name		= "Atari",
>  	.name2		= "TT",
>  	.owner		= THIS_MODULE,
> @@ -1552,7 +1552,7 @@ static MACHINE machTT = {
>  	.capabilities	=  DSP_CAP_BATCH	/* As per SNDCTL_DSP_GETCAPS */
>  };
>  
> -static MACHINE machFalcon = {
> +static __initdata MACHINE machFalcon = {
>  	.name		= "Atari",
>  	.name2		= "FALCON",
>  	.dma_alloc	= AtaAlloc,

But these are OK, as mach{TT,Falcon} are copied in dmasound_atari_init().

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

[PATCH 3/3] m68k: section mismatch fixes: Atari SCSI

[Michael Schmitz]

Part 3: Atari SCSI

There's one remaining section mismatch that I cannot fix:

WARNING: vmlinux.o(.text+0x69fc): Section mismatch in reference from the 
function atari_stram_alloc() to the function .init.text:__alloc_bootmem_low()
The function atari_stram_alloc() references
the function __init __alloc_bootmem_low().
This is often because atari_stram_alloc lacks a __init 
annotation or the annotation of __alloc_bootmem_low is wrong.

atari_stram_alloc() is needed after kernel init, and __alloc_bootmem_low is 
never called after MMU init, so that seems harmless.

commit 0937bf535329004b055dacdaf4d06fa424f716a2
Author: Michael Schmitz <schmitz@xplor.waratah.dyndns.org>
Date:   Fri Jan 2 23:44:01 2009 +0100

    [m68k] Atari SCSI: add __init annotations to probe routines
    
    Signed-off-by: Michael Schmitz <schmitz@debian.org>

diff --git a/drivers/scsi/atari_NCR5380.c b/drivers/scsi/atari_NCR5380.c
index 00f944d..a3d5371 100644
--- a/drivers/scsi/atari_NCR5380.c
+++ b/drivers/scsi/atari_NCR5380.c
@@ -844,7 +844,7 @@ static char *lprint_Scsi_Cmnd(Scsi_Cmnd *cmd, char *pos, char *buffer, int lengt
  *
  */
 
-static int NCR5380_init(struct Scsi_Host *instance, int flags)
+static int __init NCR5380_init(struct Scsi_Host *instance, int flags)
 {
 	int i;
 	SETUP_HOSTDATA(instance);
diff --git a/drivers/scsi/atari_scsi.c b/drivers/scsi/atari_scsi.c
index d97ab66..03541e3 100644
--- a/drivers/scsi/atari_scsi.c
+++ b/drivers/scsi/atari_scsi.c
@@ -619,7 +619,7 @@ int atari_queue_command(Scsi_Cmnd *cmd, void (*done)(Scsi_Cmnd *))
 #endif
 
 
-int atari_scsi_detect(struct scsi_host_template *host)
+int __init atari_scsi_detect(struct scsi_host_template *host)
 {
 	static int called = 0;
 	struct Scsi_Host *instance;

Re: [PATCH 3/3] m68k: section mismatch fixes: Atari SCSI

[Geert Uytterhoeven]

On Sun, 18 Jan 2009, Michael Schmitz wrote:
> There's one remaining section mismatch that I cannot fix:
> 
> WARNING: vmlinux.o(.text+0x69fc): Section mismatch in reference from the 
> function atari_stram_alloc() to the function .init.text:__alloc_bootmem_low()
> The function atari_stram_alloc() references
> the function __init __alloc_bootmem_low().
> This is often because atari_stram_alloc lacks a __init 
> annotation or the annotation of __alloc_bootmem_low is wrong.
> 
> atari_stram_alloc() is needed after kernel init, and __alloc_bootmem_low is 
> never called after MMU init, so that seems harmless.

Yep, I went through the same logic before...

> commit 0937bf535329004b055dacdaf4d06fa424f716a2
> Author: Michael Schmitz <schmitz@xplor.waratah.dyndns.org>
> Date:   Fri Jan 2 23:44:01 2009 +0100
> 
>     [m68k] Atari SCSI: add __init annotations to probe routines

OK, thx.

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: [PATCH 1/3] m68k: section mismatch fixes: EtherNAT

[Geert Uytterhoeven]

On Sun, 18 Jan 2009, Michael Schmitz wrote:
> commit 9418e1ee384d69065c5251d310be97f431668ddb
> Author: Michael Schmitz <schmitz@xplor.waratah.dyndns.org>
> Date:   Fri Jan 2 08:04:23 2009 +0100
> 
>     [m68k] section mismatch fixes: add __init annotation
>     
>     Signed-off-by: Michael Schmitz <schmitz@debian.org>
> ---
> diff --git a/drivers/net/atari_91C111.c b/drivers/net/atari_91C111.c
> index c441779..4d4bf61 100644
> --- a/drivers/net/atari_91C111.c
> +++ b/drivers/net/atari_91C111.c
> @@ -2161,7 +2161,7 @@ static void smc_release_datacs(struct platform_device *pdev, struct net_device *
>   *	0 --> there is a device
>   *	anything else, error
>   */
> -static int smc_drv_probe(struct platform_device *pdev)
> +static int __init smc_drv_probe(struct platform_device *pdev)
              ^^^^^^
>  {
>  	struct smc91x_platdata *pd = pdev->dev.platform_data;
>  	struct smc_local *lp;

smc_drv_probe() should be marked __devinit, not __init.
And smc_drv_remove() should be marked __devexit.

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: [PATCH 1/3] m68k: section mismatch fixes: EtherNAT

[Michael Schmitz]

Hi Geert,

> > -static int smc_drv_probe(struct platform_device *pdev)
> > +static int __init smc_drv_probe(struct platform_device *pdev)
>               ^^^^^^
> >  {
> >  	struct smc91x_platdata *pd = pdev->dev.platform_data;
> >  	struct smc_local *lp;
> 
> smc_drv_probe() should be marked __devinit, not __init.
> And smc_drv_remove() should be marked __devexit.

Yep, only saw that after sending the patch. Do you want to fix that, or shall I 
send a new patch? (My git tree is in a rough state after I've started to play 
with switching Atari SCSI to NCR5380.c, or at least a fresh clone of that!)

The DMA sound section mismatch I'll double check.

Cheers,

	Michael

Re: [PATCH 1/3] m68k: section mismatch fixes: EtherNAT

[Geert Uytterhoeven]

On Sun, 1 Feb 2009, Michael Schmitz wrote:
> > > -static int smc_drv_probe(struct platform_device *pdev)
> > > +static int __init smc_drv_probe(struct platform_device *pdev)
> >               ^^^^^^
> > >  {
> > >  	struct smc91x_platdata *pd = pdev->dev.platform_data;
> > >  	struct smc_local *lp;
> > 
> > smc_drv_probe() should be marked __devinit, not __init.
> > And smc_drv_remove() should be marked __devexit.
> 
> Yep, only saw that after sending the patch. Do you want to fix that, or shall I 
> send a new patch? (My git tree is in a rough state after I've started to play 
> with switching Atari SCSI to NCR5380.c, or at least a fresh clone of that!)

I'll fix it up.

> The DMA sound section mismatch I'll double check.

Perhaps it happens with some versions of gcc only?

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: [PATCH 1/3] m68k: section mismatch fixes: EtherNAT

[Geert Uytterhoeven]

On Sun, 1 Feb 2009, Geert Uytterhoeven wrote:

> On Sun, 1 Feb 2009, Michael Schmitz wrote:
> > > > -static int smc_drv_probe(struct platform_device *pdev)
> > > > +static int __init smc_drv_probe(struct platform_device *pdev)
> > >               ^^^^^^
> > > >  {
> > > >  	struct smc91x_platdata *pd = pdev->dev.platform_data;
> > > >  	struct smc_local *lp;
> > > 
> > > smc_drv_probe() should be marked __devinit, not __init.
> > > And smc_drv_remove() should be marked __devexit.
> > 
> > Yep, only saw that after sending the patch. Do you want to fix that, or shall I 
> > send a new patch? (My git tree is in a rough state after I've started to play 
> > with switching Atari SCSI to NCR5380.c, or at least a fresh clone of that!)
> 
> I'll fix it up.

Fixing it up triggered a few more __init/__devinit issues. Combined result
below...

commit d11918a83d4dc3d43e3f4d1d5905291bdfd0a507
Author: Michael Schmitz <schmitz@biophys.uni-duesseldorf.de>
Date:   Sun Jan 18 03:10:55 2009 +0100

    m68k: section mismatch fixes: EtherNAT
    
    add __init annotation
    [geert] Use __dev{in,ex}it
    
    Signed-off-by: Michael Schmitz <schmitz@debian.org>
    Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>

diff --git a/drivers/net/atari_91C111.c b/drivers/net/atari_91C111.c
index c441779..af2d255 100644
--- a/drivers/net/atari_91C111.c
+++ b/drivers/net/atari_91C111.c
@@ -1724,7 +1724,7 @@ static const struct ethtool_ops smc_ethtool_ops = {
  * I just deleted auto_irq.c, since it was never built...
  *   --jgarzik
  */
-static int __init smc_findirq(struct smc_local *lp)
+static int __devinit smc_findirq(struct smc_local *lp)
 {
 	void __iomem *ioaddr = lp->base;
 	int timeout = 20;
@@ -1798,8 +1798,8 @@ static int __init smc_findirq(struct smc_local *lp)
  * o  actually GRAB the irq.
  * o  GRAB the region
  */
-static int __init smc_probe(struct net_device *dev, void __iomem *ioaddr,
-			    unsigned long irq_flags)
+static int __devinit smc_probe(struct net_device *dev, void __iomem *ioaddr,
+			       unsigned long irq_flags)
 {
 	struct smc_local *lp = netdev_priv(dev);
 	static int version_printed = 0;
@@ -2161,7 +2161,7 @@ static void smc_release_datacs(struct platform_device *pdev, struct net_device *
  *	0 --> there is a device
  *	anything else, error
  */
-static int smc_drv_probe(struct platform_device *pdev)
+static int __devinit smc_drv_probe(struct platform_device *pdev)
 {
 	struct smc91x_platdata *pd = pdev->dev.platform_data;
 	struct smc_local *lp;
@@ -2324,7 +2324,7 @@ static int smc_drv_probe(struct platform_device *pdev)
 	return ret;
 }
 
-static int smc_drv_remove(struct platform_device *pdev)
+static int __devexit smc_drv_remove(struct platform_device *pdev)
 {
 	struct net_device *ndev = platform_get_drvdata(pdev);
 	struct smc_local *lp = netdev_priv(ndev);
@@ -2389,7 +2389,7 @@ static int smc_drv_resume(struct platform_device *dev)
 
 static struct platform_driver smc_driver = {
 	.probe		= smc_drv_probe,
-	.remove		= smc_drv_remove,
+	.remove		= __devexit_p(smc_drv_remove),
 	.suspend	= smc_drv_suspend,
 	.resume		= smc_drv_resume,
 	.driver		= {

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: [PATCH 1/3] m68k: section mismatch fixes: EtherNAT

[David D. Kilzer]

Michael Schmitz <schmitz@biophys.uni-duesseldorf.de> wrote:


> (My git tree is in a rough state after I've started to play 
> with switching Atari SCSI to NCR5380.c, or at least a fresh
> clone of that!)


Have you tried "git stash" yet?

Dave

Re: [PATCH 1/3] m68k: section mismatch fixes: EtherNAT

[Michael Schmitz]

Hi Dave,

> > (My git tree is in a rough state after I've started to play 
> > with switching Atari SCSI to NCR5380.c, or at least a fresh
> > clone of that!)
> 
> Have you tried "git stash" yet?

Obviously not :-) Might be just what I need, thanks. So far I've been working on 
a local branch while pulling from Geert's master branch but that may be getting 
a bit tricky.

Cheers,

	Michael

Re: [PATCH 1/3] m68k: section mismatch fixes: EtherNAT

[Geert Uytterhoeven]

	Hi Michael,

On Mon, 2 Feb 2009, Michael Schmitz wrote:
> > > (My git tree is in a rough state after I've started to play 
> > > with switching Atari SCSI to NCR5380.c, or at least a fresh
> > > clone of that!)
> > 
> > Have you tried "git stash" yet?
> 
> Obviously not :-) Might be just what I need, thanks. So far I've been working on 
> a local branch while pulling from Geert's master branch but that may be getting 
> a bit tricky.

If you use `git pull --rebase' it will rebase your changes against my tree,
and all patches you sent and I integrated will automatically be detected.

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: mac68k serial

[Finn Thain]

On Sat, 17 Jan 2009, Michael Schmitz wrote:

> Hi,
> 
> > > > 000004 modules linked in: m68k_handle_int+0x1c/0x36
> > > > 
> > > > call trace mac_scc_dispatch+0x3a/0x40 
> > > > auto_irqhandler_fixup+0x4/0x6
> > > > 
> > > > also, i hacked the "emile-0.12" sources to build a monitor able to 
> > > > serially talk: it works for both the 2 LC475 serial lines :P
> > > > 
> > > > is there anything about serial support for linux-m68k ?
> > > 
> > > The real driver for the serial ports on m68k Macintosh systems got 
> > > removed from the tree a long time ago and has not been replaced as 
> > > of this time. However, we still register mac_scc_dispatch as an 
> > > interrupt handler for the line that the SCC uses. This looks like 
> > > you got an interrupt for the serial chip and the interrupt code got 
> > > confused trying to dispatch to nothing. I've never seen it happen, 
> > > but it does look like that would be the expected behavior of the 
> > > current code.
> > 
> > I've seen it happen. You should avoid sending anything to the mac 
> > serial port. But you can still capture kernel messages from the mac 
> > serial port without triggering the panic.
> 
> Can't you add an empty SCC dispatch that just returns, or will that 
> cause an interrupt storm?

The VIA would be OK with that. Whether it would work or not would depend 
on the SCC. That is, I don't know.

You could also ifdef 0 the relevant code in via.c --

311                 request_irq(IRQ_AUTO_4, mac_scc_dispatch, IRQ_FLG_LOCK,
312                                 "scc", mac_scc_dispatch);

I don't really care enough to send a temporary patch upstream since the 
serial port is presently only useful to those hacking on the kernel 
anyway.

Finn

Re: mac68k serial

[Brad Boyer]

On Sat, Jan 17, 2009 at 05:59:51PM +1100, Finn Thain wrote:
> On Sat, 17 Jan 2009, Michael Schmitz wrote:
> > Can't you add an empty SCC dispatch that just returns, or will that 
> > cause an interrupt storm?
> 
> The VIA would be OK with that. Whether it would work or not would depend 
> on the SCC. That is, I don't know.

The SCC IRQ isn't a VIA interrupt as far as I can tell. It looks like
only models with OSS (the IIfx) or PSC (Q660AV + Q840AV) have a way
to block the SCC IRQ. The comments in mac_scc_dispatch specifically
say that the SCC causes interrupt storms if we ignore it.

We really ought to redesign the interrupt handling for macs so it's
obvious how the interrupts wander through all the layers. There is
all that logic in the common m68k interrupt handling to register
different interrupt controllers and the mac code just registers one
giant synthetic interrupt source rather than having each driver
register directly with the core for VIA, OSS, PSC, etc.

> You could also ifdef 0 the relevant code in via.c --
> 
> 311                 request_irq(IRQ_AUTO_4, mac_scc_dispatch, IRQ_FLG_LOCK,
> 312                                 "scc", mac_scc_dispatch);
> 
> I don't really care enough to send a temporary patch upstream since the 
> serial port is presently only useful to those hacking on the kernel 
> anyway.

I don't think that will really fix anything, since IRQ_AUTO_* interrupts
aren't really blocked or ignored if you don't register them. They go
directly into the CPU which doesn't have a true IRQ mask.

	Brad Boyer
	flar@allandria.com

Re: mac68k serial

[Michael Schmitz]

> > On Sat, 17 Jan 2009, Michael Schmitz wrote:
> > > Can't you add an empty SCC dispatch that just returns, or will that 
> > > cause an interrupt storm?
> > 
> > The VIA would be OK with that. Whether it would work or not would depend 
> > on the SCC. That is, I don't know.
> 
> The SCC IRQ isn't a VIA interrupt as far as I can tell. It looks like

If it's not on the same level as one of the VIAs the SCC definitely would be 
handling the exception protocol itself. But then, it should have been possible 
to specify an interrupt vector for each side - ISTR someone telling me that's 
not possible because of how it is hooked up. 

> only models with OSS (the IIfx) or PSC (Q660AV + Q840AV) have a way
> to block the SCC IRQ. The comments in mac_scc_dispatch specifically
> say that the SCC causes interrupt storms if we ignore it.

It should still be possible to shut down the SCC - after all, we have the base 
address in the bootinfo? Best do that in the early arch init code before 
interrupts are turned on. 

> We really ought to redesign the interrupt handling for macs so it's
> obvious how the interrupts wander through all the layers. There is
> all that logic in the common m68k interrupt handling to register
> different interrupt controllers and the mac code just registers one
> giant synthetic interrupt source rather than having each driver
> register directly with the core for VIA, OSS, PSC, etc.
> 
> > You could also ifdef 0 the relevant code in via.c --
> > 
> > 311                 request_irq(IRQ_AUTO_4, mac_scc_dispatch, IRQ_FLG_LOCK,
> > 312                                 "scc", mac_scc_dispatch);
> > 
> > I don't really care enough to send a temporary patch upstream since the 
> > serial port is presently only useful to those hacking on the kernel 
> > anyway.
> 
> I don't think that will really fix anything, since IRQ_AUTO_* interrupts
> aren't really blocked or ignored if you don't register them. They go
> directly into the CPU which doesn't have a true IRQ mask.

Right - not registering will only invoke the spurious interrupt handler. The 
interrupt has to be disabled in the SCC to prevent the interrupt storm. 

Can we just use boilerplate SCC init code on all Mac models for this, or does 
OSS/PSC/IOP make life more interesting there? 

	Michael

Re: mac68k serial

[Brad Boyer]

On Sun, Jan 18, 2009 at 01:43:07AM +0100, Michael Schmitz wrote:
> > The SCC IRQ isn't a VIA interrupt as far as I can tell. It looks like
> 
> If it's not on the same level as one of the VIAs the SCC definitely would be 
> handling the exception protocol itself. But then, it should have been
> possible to specify an interrupt vector for each side - ISTR someone telling
> me that's not possible because of how it is hooked up. 

The standard way it is connected is as follows:

VIA1 IRQ -> bus logic -> CPU IRQ 1
VIA2 IRQ -> bus logic -> CPU IRQ 2
SCC [all IRQ outputs together] -> bus logic -> CPU IRQ 4

Apple was really sloppy with their IRQ usage back in the old days,
especially on the early Macs that we don't support. On the original
Macintosh model (and up to the SE), it was like this:

VIA IRQ output -> /IPL0 line on CPU
SCC IRQ output -> /IPL1 line on CPU
"Interrupt Switch" -> /IPL2 line on CPU

This means that they don't even decode properly such that if you
have both chips assert an interrupt at the same time, you end up
with the addition of them. There was a PAL that would force /IPL0
high when /IPL1 went low, but there was enough time for the CPU
to see both and trigger the wrong interrupt. The Mac II added the
GLUE chip that handled the IRQ interface among other things. The
IIfx is the odd one in that it is the only 68k Mac that really
has a single top-level interrupt controller that mediates all
IRQ lines. The GLUE chip is not programmable in any way, which
means that an SCC interrupt will always get to the CPU on anything
but the IIfx and AV Macs (or the Q900/950 if the IOP chip is running).

Apple was famous for these kinds of hacks to reduce the chip count
of the Macintosh (the PWM sound was another one).

> It should still be possible to shut down the SCC - after all, we have the
> base address in the bootinfo? Best do that in the early arch init code before 
> interrupts are turned on. 

Yes, we do have the SCC base in the bootinfo. However, shutting off the
chip would break the serial debug output. I know I've used that from
time to time and would miss it.

> Can we just use boilerplate SCC init code on all Mac models for this, or does 
> OSS/PSC/IOP make life more interesting there? 

The IOP is the only thing that makes any difference here, although the
only model with OSS is also one of the models with IOPs (Mac IIfx). We
already have the code in iop.c to put the SCC IOP into bypass mode. The
OSS and PSC just change how it shows up in the IRQ range. For OSS,
we make it show up as IRQ 4 but it can be masked in the OSS. With PSC, the
SCC interrupts show up through the PSC. In fact, there are apparently
two different SCC interrupt lines in this case. The code found in
m68k/mac/macints.c specifically lists two bits for SCC interrupts
with one labelled as channel A and one for channel B on PSC systems.
These two interrupts on the PSC are the same numbers that the
mac_scc_dispatch code generates per channel so that the actual
SCC driver could register these two numbers and have it work everywhere.

	Brad Boyer
	flar@allandria.com

Re: mac68k serial

[Kolbjørn Barmen]

On Tue, 13 Jan 2009, flameman mayer wrote:

> hi,
> I'm Carlo Pisani, alias "flameman", and i'm running this little
> project: gentoo-m68k @ applem68k-LC475
> 
> ( http://elinux.org/Mac68k-Flameman )

"the Debian and the gentoo m68k port seems to be pretty dead these days"

Hey, I build new gentoo packages and upload to tinderbox all the time :)

Cool to see someone make use of it though, I admit I mostly do this for my
own needs (or.. fetish, I bet some would say). The gentoo developers were
kind to let me upload my packages to their site, you will also really soon
see an m68k repo in layman, for those m68k-specific ebuilds I have.

Cheers! :)

-- kolla