parport_pc: irq= parameter with limited usefulness, kernel hang on PPC/OldWorldMac

parport_pc: irq= parameter with limited usefulness, kernel hang on PPC/OldWorldMac

[Thomas Richter]

Hi folks, (please reply to thor@math.tu-berlin.de for additional 
questions or feedback),

this is a bug report concerning the parport_pc driver on a somewhat 
exotic hardware that seems to be related
to the unability to switch the module into polling mode:

The system is a beige G3 old-world PPC mac with PCI slots, one of the 
slots contains a NetMOS-based parallel port
card. The system worked happily in this configuration for kernel 2.6.28, 
but things broke on (at least) 2.6.31 and
are (at least) still broken on 2.6.32.21. Symptoms are that the system 
hangs completely as soon as data is
printed out over /dev/lp0. It does then not even react on the 
SysReq-keys (option of course compiled into the kernel),
though if you're lucky, you get a stack-dump. Unfortunately, there is no 
way to get it out of the system as you need
to shut down the power the tough way to get it back working, so I only 
took notes manually:

Exception: 501 at handle_IRQ_event+0x34/0x124
    LR=handle_edge_irq+0x138/0x180
Exception: 501 at __do_softirq+0x68/0x120
    LR=do_softirq+0x48/0x58
Exceptin: 901 at parport_ieee1284_write_compat+0x1a8/0x250
    LR=parport_ieee1284_write_compat+0x19c/0x250

There are several strange things with these:

*) Under at least 2.6.31 and up, the kernel assigns IRQ 25 to the card. 
Under 2.6.28 and below, the card
was run in polling mode (i.e. irq was -1, not 25).

*) Furthermore, the above report suggests that the system wants to 
handle an edge-triggered IRQ, though
according to /proc/interrupts, IRQ 25 is level-triggered.

I was then hoping to persuade the system back into a working stage by 
passing a module parameter to parport_pc:

irq=none dma=none

should, according to the documentation and the parport_pc.c source do 
that. For reasons beyond me, the kernel module wants
to be smarter than I and *still* enables the IRQ. I'm pretty sure that 
shouldn't happen, and a irq=none should be
definite, and not just a suggestion, but please correct me if I'm wrong.

I can get the system back to working with the following trick (urgh!, 
don't try this at home):

*) First, load parport_pc without any parameters. It will then detect an 
SPP port at 0x540 and will enable the irq 25 for
the card.

*) Unload parport_pc,

and reload it as follows:

*) modprobe parport_pc io=0x450 dma=none irq=none

It then "moans" a bit:

Caused by (from SRR1=49030): Transfer error ack signal
IN from bad port 852 at d1a4e898
Machine check in kernel mode.
Caused by (from SRR1=49030): Transfer error ack signal
IN from bad port 852 at d1a4e93c

however, the parport is then successfully in polling mode and works 
happily (well, maybe not happily, but it works at least).

Thus, for me, there seem to be at least two unrelated bugs:

*) parport_pc should take irq=none seriously and should not silently 
override it,
*) parport_pc should at least not crash the system completely in case 
the IRQ is enabled.

The latter *might* be an issue with the G3 powermac hardware, which is 
of course weird and has a couple of hardware
issues of its own.

Thanks,
    Thomas

Re: parport_pc: irq= parameter with limited usefulness, kernel hang on PPC/OldWorldMac

[Alan Cox]

> *) Under at least 2.6.31 and up, the kernel assigns IRQ 25 to the card. 
> Under 2.6.28 and below, the card
> was run in polling mode (i.e. irq was -1, not 25).
> 
> *) Furthermore, the above report suggests that the system wants to 
> handle an edge-triggered IRQ, though
> according to /proc/interrupts, IRQ 25 is level-triggered.

The parport_pc code just asks for the IRQ so any level/edge mismatch
would appear to be coming from the firmware or architecture code. The
older kernel didn't know to use the IRQ on PCI devices which stopped some
things working and hurt performance. That would also have masked the bug
you see - so the report makes total sense.

> should, according to the documentation and the parport_pc.c source do 
> that. For reasons beyond me, the kernel module wants
> to be smarter than I and *still* enables the IRQ. I'm pretty sure that 

The options only apply to legacy ports - it has always been that way.
It's not clear how you would specify which port to affect otherwise.

> *) parport_pc should take irq=none seriously and should not silently 
> override it,

parport_pc could do with a way to specify whether to use the IRQ or DMA
on PCI ports but really this shouldn't be needed if the rest of the
kernel logic is right.

> *) parport_pc should at least not crash the system completely in case 
> the IRQ is enabled.
> 
> The latter *might* be an issue with the G3 powermac hardware, which is 
> of course weird and has a couple of hardware

The latter looks like a bug in the PPC side support, perhaps misreporting
an IRQ, or mislabelling it in some way. I think the first step is to find
a PPC hacker who can figure out why the apparently sane IRQ request from
the parport layer is exploding.

Even if there is some technical reason the IRQ can't be used then the arch
code shouldn't be reporting an IRQ for it, and the parport_pc could ought
to just work.

Adding Ben to the Cc: so we it can get hunted down.

Alan

Re: parport_pc: irq= parameter with limited usefulness, kernel hang on PPC/OldWorldMac

[Thomas Richter]

Thanks Alan, hi Ben,

>> *) Under at least 2.6.31 and up, the kernel assigns IRQ 25 to the card. 
>> Under 2.6.28 and below, the card
>> was run in polling mode (i.e. irq was -1, not 25).
>>
>> *) Furthermore, the above report suggests that the system wants to 
>> handle an edge-triggered IRQ, though
>> according to /proc/interrupts, IRQ 25 is level-triggered.
>>     
>
> The parport_pc code just asks for the IRQ so any level/edge mismatch
> would appear to be coming from the firmware or architecture code. The
> older kernel didn't know to use the IRQ on PCI devices which stopped some
> things working and hurt performance. That would also have masked the bug
> you see - so the report makes total sense.
>   

I see, thanks.


>> *) parport_pc should take irq=none seriously and should not silently 
>> override it,
>>     
>
> parport_pc could do with a way to specify whether to use the IRQ or DMA
> on PCI ports but really this shouldn't be needed if the rest of the
> kernel logic is right.
>
>   
>> *) parport_pc should at least not crash the system completely in case 
>> the IRQ is enabled.
>>
>> The latter *might* be an issue with the G3 powermac hardware, which is 
>> of course weird and has a couple of hardware
>>     
>
> The latter looks like a bug in the PPC side support, perhaps misreporting
> an IRQ, or mislabelling it in some way. I think the first step is to find
> a PPC hacker who can figure out why the apparently sane IRQ request from
> the parport layer is exploding.
>
> Even if there is some technical reason the IRQ can't be used then the arch
> code shouldn't be reporting an IRQ for it, and the parport_pc could ought
> to just work.
>
> Adding Ben to the Cc: so we it can get hunted down.
Ben, anything I can do to find this bug? The current state is
"workaround that works ok for me", but that's not very satisfying.

Greetings,
    Thomas