ppc32 PIO recovery mecanism

ppc32 PIO recovery mecanism

[Benjamin Herrenschmidt]

On 32 bits powerpc, we currently have a mechanism where we try to
recover from machine checks happening on PIO operations (inb/outb/....).
This mecanisms has proven of dubious reliability in the past and it's my
understanding that we've pretty fixed all relevant legacy drivers that
distro typically load so that they don't muck around when they
shouldn't.

I'm currently merging 32 and 64 bits io.h and I would really like to
just get rid of that stuff, but I'd like your distro point of view
first. Is this mechanism still useful at all or not ?

Cheers,
Ben.

Re: ppc32 PIO recovery mecanism

[David Woodhouse]

On Mon, 2006-11-06 at 11:41 +1100, Benjamin Herrenschmidt wrote:
> On 32 bits powerpc, we currently have a mechanism where we try to
> recover from machine checks happening on PIO operations (inb/outb/....).
> This mecanisms has proven of dubious reliability in the past and it's my
> understanding that we've pretty fixed all relevant legacy drivers that
> distro typically load so that they don't muck around when they
> shouldn't.
> 
> I'm currently merging 32 and 64 bits io.h and I would really like to
> just get rid of that stuff, but I'd like your distro point of view
> first. Is this mechanism still useful at all or not ?

Yes, I think it's still useful because there are some drivers which
aren't update to use check_legacy_ioport() (or whatever other system)
yet.

Not many, mind you -- but I'd like to be 100% sure before we drop it.
Let's start by making it print with KERN_CRIT instead of KERN_DEBUG?

-- 
dwmw2

Re: ppc32 PIO recovery mecanism

[Benjamin Herrenschmidt]

On Mon, 2006-11-06 at 09:18 +0800, David Woodhouse wrote:
> On Mon, 2006-11-06 at 11:41 +1100, Benjamin Herrenschmidt wrote:
> > On 32 bits powerpc, we currently have a mechanism where we try to
> > recover from machine checks happening on PIO operations (inb/outb/....).
> > This mecanisms has proven of dubious reliability in the past and it's my
> > understanding that we've pretty fixed all relevant legacy drivers that
> > distro typically load so that they don't muck around when they
> > shouldn't.
> > 
> > I'm currently merging 32 and 64 bits io.h and I would really like to
> > just get rid of that stuff, but I'd like your distro point of view
> > first. Is this mechanism still useful at all or not ?
> 
> Yes, I think it's still useful because there are some drivers which
> aren't update to use check_legacy_ioport() (or whatever other system)
> yet.
> 
> Not many, mind you -- but I'd like to be 100% sure before we drop it.
> Let's start by making it print with KERN_CRIT instead of KERN_DEBUG?

We should rate limit if we do that tho... Some drivers will just totally
flood you.

I'll keep it around for now.

Ben.

Re: ppc32 PIO recovery mecanism

[Olaf Hering]

On Mon, Nov 06, David Woodhouse wrote:

> Yes, I think it's still useful because there are some drivers which
> aren't update to use check_legacy_ioport() (or whatever other system)
> yet.

What remaining drivers do you have in mind here?

Re: ppc32 PIO recovery mecanism

[David Woodhouse]

On Mon, 2006-11-06 at 07:11 +0100, Olaf Hering wrote:
> On Mon, Nov 06, David Woodhouse wrote:
> 
> > Yes, I think it's still useful because there are some drivers which
> > aren't update to use check_legacy_ioport() (or whatever other system)
> > yet.
> 
> What remaining drivers do you have in mind here? 

Did ISAPnP get fixed?

-- 
dwmw2

Re: ppc32 PIO recovery mecanism

[Olaf Hering]

On Mon, Nov 06, David Woodhouse wrote:

> On Mon, 2006-11-06 at 07:11 +0100, Olaf Hering wrote:
> > On Mon, Nov 06, David Woodhouse wrote:
> > 
> > > Yes, I think it's still useful because there are some drivers which
> > > aren't update to use check_legacy_ioport() (or whatever other system)
> > > yet.
> > 
> > What remaining drivers do you have in mind here? 
> 
> Did ISAPnP get fixed?

I have to check, only PReP systems have ISA slots.

Re: ppc32 PIO recovery mecanism

[Olaf Hering]

On Mon, Nov 06, Olaf Hering wrote:

> On Mon, Nov 06, David Woodhouse wrote:
> 
> > Did ISAPnP get fixed?
> 
> I have to check, only PReP systems have ISA slots.

isapnp_init() has your change. I loaded all the ISA network drivers,
none of them crashed the pismo.

Also, I do not plan to reenable CONFIG_ISA. And there is no autoprobing
for ISA hardware, so I dont think it will cause any trouble if distros
ship stuff like aha1542.ko for 32bit kernels.