Problem serial.c on module

Problem serial.c on module

[KOBAYASHI R. Taizo]

[-- Attachment #1: Type: Text/Plain, Size: 564 bytes --]

Hi

Since /drivers/char/serial.c was updated to "5.05c","2001-07-08",
system clash when pcmcia modem cards ejects.

I examined this problem and had a question.
Dose it need following branch?
================L5375==
#ifdef CONFIG_ALL_PPC
        /* early PowerMacs would machine check */
        if (_machine == _MACH_Pmac) {
                printk(KERN_INFO "serial.c: nothing to do on PowerMacs.\n");
                return 0;
        }
#endif
=======================

Anyway, pcmcia modem card on my TiBook seems work fine with following patch.

Thanks.

Taizo


[-- Attachment #2: 2.4.10-ppc-serial.diff --]
[-- Type: Text/Plain, Size: 2006 bytes --]

--- linux/drivers/char/serial.c.orig	Fri Sep 28 13:57:02 2001
+++ linux/drivers/char/serial.c	Fri Sep 28 13:46:41 2001
@@ -4015,7 +4015,10 @@
  * seems to be mainly needed on card using the PLX which also use I/O
  * mapped memory.
  */
-static int __devinit
+static int
+#ifndef MODULE
+__devinit
+#endif
 pci_plx9050_fn(struct pci_dev *dev, struct pci_board *board, int enable)
 {
 	u8 data, *p, irq_config;
@@ -4079,7 +4082,10 @@
 #define PCI_DEVICE_ID_SIIG_1S_10x (PCI_DEVICE_ID_SIIG_1S_10x_550 & 0xfffc)
 #define PCI_DEVICE_ID_SIIG_2S_10x (PCI_DEVICE_ID_SIIG_2S_10x_550 & 0xfff8)

-static int __devinit
+static int
+#ifndef MODULE
+__devinit
+#endif
 pci_siig10x_fn(struct pci_dev *dev, struct pci_board *board, int enable)
 {
        u16 data, *p;
@@ -4108,7 +4114,10 @@
 #define PCI_DEVICE_ID_SIIG_2S_20x (PCI_DEVICE_ID_SIIG_2S_20x_550 & 0xfffc)
 #define PCI_DEVICE_ID_SIIG_2S1P_20x (PCI_DEVICE_ID_SIIG_2S1P_20x_550 & 0xfffc)

-static int __devinit
+static int
+#ifndef MODULE
+__devinit
+#endif
 pci_siig20x_fn(struct pci_dev *dev, struct pci_board *board, int enable)
 {
        u8 data;
@@ -4129,7 +4138,10 @@
 }

 /* Added for EKF Intel i960 serial boards */
-static int __devinit
+static int
+#ifndef MODULE
+__devinit
+#endif
 pci_inteli960ni_fn(struct pci_dev *dev,
 		   struct pci_board *board,
 		   int enable)
@@ -4187,7 +4199,10 @@
 	{ 0, 0 }
 };

-static int __devinit
+static int
+#ifndef MODULE
+__devinit
+#endif
 pci_timedia_fn(struct pci_dev *dev, struct pci_board *board, int enable)
 {
 	int	i, j;
@@ -4208,7 +4223,10 @@
 	return 0;
 }

-static int __devinit
+static int
+#ifndef MODULE
+__devinit
+#endif
 pci_xircom_fn(struct pci_dev *dev, struct pci_board *board, int enable)
 {
 	__set_current_state(TASK_UNINTERRUPTIBLE);
@@ -5372,7 +5390,8 @@
 #endif
 	show_serial_version();

-#ifdef CONFIG_ALL_PPC
+#if 0
+//#ifdef CONFIG_ALL_PPC
 	/* early PowerMacs would machine check */
 	if (_machine == _MACH_Pmac) {
 		printk(KERN_INFO "serial.c: nothing to do on PowerMacs.\n");

Re: Problem serial.c on module

[Tom Rini]

On Fri, Sep 28, 2001 at 02:33:01PM +0900, KOBAYASHI R. Taizo wrote:

> I examined this problem and had a question.
> Dose it need following branch?
> ================L5375==
> #ifdef CONFIG_ALL_PPC
>         /* early PowerMacs would machine check */
>         if (_machine == _MACH_Pmac) {
>                 printk(KERN_INFO "serial.c: nothing to do on PowerMacs.\n");
>                 return 0;
>         }
> #endif
> =======================

Some older machines apparently do.  The current 'workaround' in 2_4 is
#if defined(CONFIG_ALL_PPC) && !defined(MODULE).

> Anyway, pcmcia modem card on my TiBook seems work fine with following patch.
> --- linux/drivers/char/serial.c.orig	Fri Sep 28 13:57:02 2001
> +++ linux/drivers/char/serial.c	Fri Sep 28 13:46:41 2001
> @@ -4015,7 +4015,10 @@
>   * seems to be mainly needed on card using the PLX which also use I/O
>   * mapped memory.
>   */
> -static int __devinit
> +static int
> +#ifndef MODULE
> +__devinit
> +#endif
>  pci_plx9050_fn(struct pci_dev *dev, struct pci_board *board, int enable)
>  {
>  	u8 data, *p, irq_config;

Are these actually needed?  They really shouldn't be...

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Problem serial.c on module

[David A. Gatwood]

On Friday, September 28, 2001, at 08:15 AM, Tom Rini wrote:

> On Fri, Sep 28, 2001 at 02:33:01PM +0900, KOBAYASHI R. Taizo wrote:
>
>> I examined this problem and had a question.
>> Dose it need following branch?
>> ================L5375==
>> #ifdef CONFIG_ALL_PPC
>>         /* early PowerMacs would machine check */
>>         if (_machine == _MACH_Pmac) {
>>                 printk(KERN_INFO "serial.c: nothing to do on
>> PowerMacs.\n");
>>                 return 0;
>>         }
>> #endif
>> =======================
>
> Some older machines apparently do.  The current 'workaround' in 2_4 is
> #if defined(CONFIG_ALL_PPC) && !defined(MODULE).

That's disgusting.  This should be doing the Linux equivalent of setjmp
and trapping the machine check and returning 0.  Hardware probes
shouldn't need hacks like this.  Just my $0.02.


David


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Problem serial.c on module

[Tom Rini]

On Fri, Sep 28, 2001 at 10:41:23AM -0700, David A. Gatwood wrote:
> On Friday, September 28, 2001, at 08:15 AM, Tom Rini wrote:
>
> >On Fri, Sep 28, 2001 at 02:33:01PM +0900, KOBAYASHI R. Taizo wrote:
> >
> >>I examined this problem and had a question.
> >>Dose it need following branch?
> >>================L5375==
> >>#ifdef CONFIG_ALL_PPC
> >>        /* early PowerMacs would machine check */
> >>        if (_machine == _MACH_Pmac) {
> >>                printk(KERN_INFO "serial.c: nothing to do on
> >>PowerMacs.\n");
> >>                return 0;
> >>        }
> >>#endif
> >>=======================
> >
> >Some older machines apparently do.  The current 'workaround' in 2_4 is
> >#if defined(CONFIG_ALL_PPC) && !defined(MODULE).
>
> That's disgusting.  This should be doing the Linux equivalent of setjmp
> and trapping the machine check and returning 0.  Hardware probes
> shouldn't need hacks like this.  Just my $0.02.

Thats what should be happening.  But apparently it still doesn't on a few
older machines.   Or it didn't the last time I got an answer out of Olaf@SuSE.

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Problem serial.c on module

[David A. Gatwood]

On Friday, September 28, 2001, at 11:05 AM, Tom Rini wrote:

> On Fri, Sep 28, 2001 at 10:41:23AM -0700, David A. Gatwood wrote:
>> On Friday, September 28, 2001, at 08:15 AM, Tom Rini wrote:
>>
>>> On Fri, Sep 28, 2001 at 02:33:01PM +0900, KOBAYASHI R. Taizo wrote:
>>>
>>>> I examined this problem and had a question.
>>>> Dose it need following branch?
>>>> ================L5375==
>>>> #ifdef CONFIG_ALL_PPC
>>>>        /* early PowerMacs would machine check */
>>>>        if (_machine == _MACH_Pmac) {
>>>>                printk(KERN_INFO "serial.c: nothing to do on
>>>> PowerMacs.\n");
>>>>                return 0;
>>>>        }
>>>> #endif
>>>> =======================
>>>
>>> Some older machines apparently do.  The current 'workaround' in 2_4 is
>>> #if defined(CONFIG_ALL_PPC) && !defined(MODULE).
>>
>> That's disgusting.  This should be doing the Linux equivalent of setjmp
>> and trapping the machine check and returning 0.  Hardware probes
>> shouldn't need hacks like this.  Just my $0.02.
>
> Thats what should be happening.  But apparently it still doesn't on a
> few
> older machines.   Or it didn't the last time I got an answer out of
> Olaf@SuSE.

Sounds like a lowmem_vectors problem or similar.  What machine and
processor?


David


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Problem serial.c on module

[Tom Rini]

On Fri, Sep 28, 2001 at 11:26:20AM -0700, David A. Gatwood wrote:
> On Friday, September 28, 2001, at 11:05 AM, Tom Rini wrote:
>
> >On Fri, Sep 28, 2001 at 10:41:23AM -0700, David A. Gatwood wrote:
> >>On Friday, September 28, 2001, at 08:15 AM, Tom Rini wrote:
> >>
> >>>On Fri, Sep 28, 2001 at 02:33:01PM +0900, KOBAYASHI R. Taizo wrote:
> >>>
> >>>>I examined this problem and had a question.
> >>>>Dose it need following branch?
> >>>>================L5375==
> >>>>#ifdef CONFIG_ALL_PPC
> >>>>       /* early PowerMacs would machine check */
> >>>>       if (_machine == _MACH_Pmac) {
> >>>>               printk(KERN_INFO "serial.c: nothing to do on
> >>>>PowerMacs.\n");
> >>>>               return 0;
> >>>>       }
> >>>>#endif
> >>>>=======================
> >>>
> >>>Some older machines apparently do.  The current 'workaround' in 2_4 is
> >>>#if defined(CONFIG_ALL_PPC) && !defined(MODULE).
> >>
> >>That's disgusting.  This should be doing the Linux equivalent of setjmp
> >>and trapping the machine check and returning 0.  Hardware probes
> >>shouldn't need hacks like this.  Just my $0.02.
> >
> >Thats what should be happening.  But apparently it still doesn't on a
> >few
> >older machines.   Or it didn't the last time I got an answer out of
> >Olaf@SuSE.
>
> Sounds like a lowmem_vectors problem or similar.  What machine and
> processor?

I think it was a 7x00 with a 601.  But I'm not sure.  Olaf?  Is this a problem
still even?

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Problem serial.c on module

[Olaf Hering]

On Fri, Sep 28, Tom Rini wrote:

> On Fri, Sep 28, 2001 at 11:26:20AM -0700, David A. Gatwood wrote:
> > On Friday, September 28, 2001, at 11:05 AM, Tom Rini wrote:
> >
> > >On Fri, Sep 28, 2001 at 10:41:23AM -0700, David A. Gatwood wrote:
> > >>On Friday, September 28, 2001, at 08:15 AM, Tom Rini wrote:
> > >>
> > >>>On Fri, Sep 28, 2001 at 02:33:01PM +0900, KOBAYASHI R. Taizo wrote:
> > >>>
> > >>>>I examined this problem and had a question.
> > >>>>Dose it need following branch?
> > >>>>================L5375==
> > >>>>#ifdef CONFIG_ALL_PPC
> > >>>>       /* early PowerMacs would machine check */
> > >>>>       if (_machine == _MACH_Pmac) {
> > >>>>               printk(KERN_INFO "serial.c: nothing to do on
> > >>>>PowerMacs.\n");
> > >>>>               return 0;
> > >>>>       }
> > >>>>#endif
> > >>>>=======================
> > >>>
> > >>>Some older machines apparently do.  The current 'workaround' in 2_4 is
> > >>>#if defined(CONFIG_ALL_PPC) && !defined(MODULE).
> > >>
> > >>That's disgusting.  This should be doing the Linux equivalent of setjmp
> > >>and trapping the machine check and returning 0.  Hardware probes
> > >>shouldn't need hacks like this.  Just my $0.02.
> > >
> > >Thats what should be happening.  But apparently it still doesn't on a
> > >few
> > >older machines.   Or it didn't the last time I got an answer out of
> > >Olaf@SuSE.
> >
> > Sounds like a lowmem_vectors problem or similar.  What machine and
> > processor?
>
> I think it was a 7x00 with a 601.  But I'm not sure.  Olaf?  Is this a problem
> still even?

I will try it again, later.
That hunk wasnt supposed to go into Bens tree.


Gruss Olaf

--
 $ man clone

BUGS
       Main feature not yet implemented...

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Problem serial.c on module

[Benjamin Herrenschmidt]

>That's disgusting.  This should be doing the Linux equivalent of setjmp
>and trapping the machine check and returning 0.  Hardware probes
>shouldn't need hacks like this.  Just my $0.02.

I definitely don't like it neither.

Currently, we have a "feature" if inb/outb (IO macros), Machine Checks
caused by these are caught, and inb returns 0xff when the IO fails.

However, we don't do that for MMIO (readb/writeb & friends, in_le32/be32,
..).

For one thing, I beleive we could add explicit "probe" verions of these
functions that return an error code and can be used in the "probe" part
of those drivers.

But that wouldn't help in all cases. Things like legacy drivers (serial.c
is one) will try to tweak "legacy" x86 IO ports. The above workaround will
help not crashing immediately. But you are not protected against having
a real PCI device mapping IOs in this location. In this case, you'll end
up writing to this card's IOs, possibily causing all sorts of bad things.

One workaround here would be to hack in the pmac PCI code to mark the
first 64k of IO space reserved and remap any PCI device that was mapped
in this location by OF.

Another one (I'd prefer) would be for such drivers to be dynamically
configured by the arch code instead of relying on a compile-time table
of known IO ports. There is a facility to hack into the compile-time
table from arch in serial.c, but I'm not sure it completely match
our needs. Other legacy drivers (like floppy.c) would need the same
tweak.

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Problem serial.c on module

[Paul Mackerras]

KOBAYASHI R. Taizo writes:

> I examined this problem and had a question.
> Dose it need following branch?
> ================L5375==
> #ifdef CONFIG_ALL_PPC
>         /* early PowerMacs would machine check */
>         if (_machine == _MACH_Pmac) {
>                 printk(KERN_INFO "serial.c: nothing to do on PowerMacs.\n");
>                 return 0;
>         }
> #endif
> =======================

That code has been on my hit-list for quite a while now.  It's been
one of those situations where someone thinks that someone else had a
problem that was fixed by that code.  Unless someone can email me
specifically with a situation where that code fixes a real problem,
that code will get deleted shortly.  And if there is a real problem I
will try to find a better way to solve it that that code.

The only valid concern I have heard so far is Ben's comment that OF
might have put some other PCI device at the I/O port addresses that
are probed by the serial driver.  If this has actually been a problem
for anyone I would like to hear the details.

Ultimately we should move to a scheme where each platform registers
its serial ports early on in the initialization.

> -static int __devinit
> +static int
> +#ifndef MODULE
> +__devinit
> +#endif
>  pci_plx9050_fn(struct pci_dev *dev, struct pci_board *board, int enable)

This change is ugly and should be unnecessary.  What was this trying
to achieve?

Paul.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/