lkml.org 
[lkml]   [2010]   [Sep]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
Subjectparport_pc: irq= parameter with limited usefulness, kernel hang on PPC/OldWorldMac
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




\
 
 \ /
  Last update: 2010-09-14 16:41    [W:0.038 / U:0.424 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site