Bug 7491 - parport_pc ignores the irq and dma params
Summary: parport_pc ignores the irq and dma params
Status: RESOLVED OBSOLETE
Alias: None
Product: Drivers
Classification: Unclassified
Component: Parallel (show other bugs)
Hardware: i386 Linux
: P2 normal
Assignee: drivers_parallel
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-11-11 00:36 UTC by Stas Sergeev
Modified: 2012-10-30 14:31 UTC (History)
7 users (show)

See Also:
Kernel Version: 2.6.27
Tree: Mainline
Regression: No


Attachments
attempt to fix the probe function (2.33 KB, patch)
2007-01-10 11:22 UTC, Stas Sergeev
Details | Diff
experimental PNPACPI patch (543 bytes, patch)
2007-07-25 22:17 UTC, Bjorn Helgaas
Details | Diff
dmesg for Bjorn Helgaas (22.92 KB, text/plain)
2007-07-26 05:41 UTC, Stas Sergeev
Details
dmesg from unpatched kernel (21.41 KB, text/plain)
2007-07-26 06:09 UTC, Stas Sergeev
Details
test patch for ACPI CA problem (1.12 KB, patch)
2008-05-22 09:05 UTC, Bjorn Helgaas
Details | Diff

Description Stas Sergeev 2006-11-11 00:36:57 UTC
Most recent kernel where this bug did not occur:
no idea

Distribution:
FC6

Hardware Environment:
x86_64 PC

Software Environment:
Problem Description:
parport_pc module uses irq=7 and dma=3 for me regardless of its
parameters, and so I can't use the parallel printer.
Even "dma=none" doesn't make a difference. That's because the
parport_pc_pnp_probe() ignores the irqval and dmaval variables
which store the modparameters. Maybe also the other probe functions
do ignore these parameters either. Also, if the parameter is not specified,
the parport_parse_param() doesn't alter "*val". It looks like
the parse_parport_params() gets the "val" uninitialized in this
case.

Steps to reproduce:
modprobe parport_pc dma=none
dmesg |grep parport
The dma is still being used.
Comment 1 Randy Dunlap 2006-11-15 22:40:59 UTC
I don't think that Linux supports overriding the PNP BIOS resource
assignments.  Does it, Adam?

You could either build a kernel without enabling CONFIG_PNP,
or you could boot your kernel with the "noisapnp" boot option
to see if that helps with using the IRQ and DMA options of
parport_pc.
Comment 2 Stas Sergeev 2006-11-23 08:21:18 UTC
> or you could boot your kernel with the "noisapnp" boot option
> to see if that helps with using the IRQ and DMA options of
> parport_pc.
Sorry if I forgot to answer this.
No, the noisapnp makes no difference.

$ dmesg |grep "Command line"
Command line: ro root=LABEL=/ noisapnp

$ dmesg |grep parport
parport: PnPBIOS parport detected.
parport0: PC-style at 0x378 (0x778), irq 7, dma 3 [PCSPP,TRISTATE,COMPAT,ECP,DMA]
parport0: Legacy device

The PnPBIOS line is still here, so apparently the same path
is entered. Is it another bug that "noisapnp" doesnt make a
difference? "dma=none" still makes no difference too.
It won't be too difficult to take the modparams into account,
or will it?
Comment 3 mjacek 2007-01-09 09:45:04 UTC
IMHO on x86_64 kernel there is no isapnp, there is acpipnp (not sure about the
spelling ;-). Definitely read bug #5832. 

I am also seeking some way out - I NEED 64-bit kernel AND printing too.
Comment 4 Stas Sergeev 2007-01-09 10:07:00 UTC
I think you are right - the bugs #7492 and #5832 have
probably the same roots. But I have tracked it to the
DMA usage - ACPI/pnp/whatever is guilty in my case only
by unconditionally enabling DMA, so perhaps my report
is more accurate. :) The parport probe function is broken,
at least.

> I am also seeking some way out - I NEED 64-bit kernel AND printing too.
I've got it working with a few simple hacks - honouring
the modparams in a probe function is not a rocket science.
And if you want, just hack it to always disable the DMA,
and then you can print. (unless you happen to have RH/FC
distro, where the printing basically seem to be a myth :)
Comment 5 Stas Sergeev 2007-01-10 11:19:45 UTC
Thanks - "pnpacpi=off" indeed does the trick and helps to bypass
the buggy code.

In any case, after all the workarounds are known, someone have to
start fixing bugs.
I am uploading my pass on a probe function - can someone please
take a look?
Comment 6 Stas Sergeev 2007-01-10 11:22:33 UTC
Created attachment 10051 [details]
attempt to fix the probe function

My try on fixing the probe function.
Note: this patch does NOT affect the bug #7492.
Comment 7 Stas Sergeev 2007-01-10 21:15:41 UTC
How to get the 0-based parport index in a pnp probe
function, does anyone know? My patch currently uses
0 which is not very good for more than one port.
Comment 8 Natalie Protasevich 2007-07-05 01:11:54 UTC
Any updates with this? It looks like the patch needs testing/review.
Thanks.
Comment 9 Bjorn Helgaas 2007-07-25 22:14:42 UTC
Stas, can you post the broken and working (with your patch) dmesg logs?

If you explicitly specify parport parameters, I think those should override
anything from PNP or ACPI.  I think that's the bug your patch fixes.  Mike
will probably take a look at your patch, and I will try to also.

But you shouldn't have to specify the parport parameters explicitly.  The
fact that we don't auto-configure the port is a second bug.  This one could
be either in the BIOS or in Linux.  Without knowing more about your situation,
I can't make a very good guess.  But someone else recently reported a printer
problem that could be similar:
  http://www.mail-archive.com/linux-acpi%40vger.kernel.org/msg07453.html
and I asked him to try a small PNPACPI patch.

I haven't heard any results yet, but I'll attach my experimental patch here,
in case you can give it a try.  The point of this patch would be to make the
printer work with no arguments at all.
Comment 10 Bjorn Helgaas 2007-07-25 22:17:02 UTC
Created attachment 12147 [details]
experimental PNPACPI patch

Try this without any parport arguments.  I'd like to see the complete
dmesg log and /proc/interrupts contents whether it works or not.
Comment 11 Stas Sergeev 2007-07-26 05:40:43 UTC
> Stas, can you post the broken and working (with your patch) dmesg logs?
The dmesg logs are identical. But with my patch
you can use "dma=none" parameter, in which case
the only difference in the dmesg will be:
- parport0: PC-style at 0x378 (0x778), irq 7, dma 3
+ parport0: PC-style at 0x378 (0x778), irq 7

> But you shouldn't have to specify the parport parameters explicitly.  The
> fact that we don't auto-configure the port is a second bug.
Exactly: bug #7492.

> I can't make a very good guess.  But someone else recently reported a printer
> problem that could be similar:
>   http://www.mail-archive.com/linux-acpi%40vger.kernel.org/msg07453.html
I don't think this is similar. Even though I listed
2.6.18-mm2 here, the problem started to appear way
much earlier. I don't know when. When I bought this
new x86_64 pc, the problem was already there, and
that was over a year and half ago.

> Try this without any parport arguments.  I'd like to see the complete
> dmesg log and /proc/interrupts contents whether it works or not.
The patch doesn't change anything and I'll attach
dmesg (will suit also for the dmesgs you asked above).
However this bug entry is only about the module
ignoring its own arguments. For fixing the printing
problem itself, you can visit bug #7492.
Comment 12 Stas Sergeev 2007-07-26 05:41:59 UTC
Created attachment 12155 [details]
dmesg for Bjorn Helgaas

Your patch gives no relief.
Comment 13 Stas Sergeev 2007-07-26 05:44:36 UTC
Oh my.
In that new dmesg I can see
---
parport_pc 00:0a: reported by Plug and Play ACPI
parport0: PC-style at 0x378 (0x778), irq 3, dma 1 [PCSPP,TRISTATE,COMPAT,ECP,DMA]
---
which is totally different from what it was
before (irq 7, dma 3).
Whether it is your patch or just a newer kernel
that makes a difference, is what I'll find out
within a few minutes...
Comment 14 Stas Sergeev 2007-07-26 06:09:24 UTC
Created attachment 12156 [details]
dmesg from unpatched kernel

Yes, its your patch that makes
such a difference. It also makes
a lot of any other differences in
the log, including the warning and
a stack trace.
So here is the dmesg from a prestine
kernel.
Comment 15 Bjorn Helgaas 2007-07-27 15:19:42 UTC
Re: your patch: http://bugzilla.kernel.org/attachment.cgi?id=10051.

Procedural nit: it's handier to apply patches made from the top-level
directory.  Documentation/SubmittingPatches has details.

Your patch changes parport_pc_pnp_probe() so that if the "irq" and "dma"
module parameters are specified, they override the values from PNP.  I
think if the user specifies any module parameters, we should just skip the
PNP probe altogether.  PNP already has a generic mechanism to change the
resources used by a device, i.e.,
  # echo "set ..." > /sys/bus/pnp/devices/00:00/resources

It would be useful to have a "parport=nopnp" flag to turn off the PNP probe
and use only the legacy and PCI probes.  That would be a slightly smaller
hammer than using "pnpacpi=off".
Comment 16 Stas Sergeev 2007-07-28 06:04:05 UTC
> Procedural nit: it's handier to apply patches made from the top-level
> directory.
I did it the other way around to make it
clear that the patch is for review only,
not for applying.
I was using irqval[0]/dmaval[0], but instead
of 0 there should be a port index, which I
didn't know how to get.

> I
> think if the user specifies any module parameters, we should just skip the
> PNP probe altogether.
I tried that but failed. The PCI probe function
of parport is not being called at all unless 
pnpacpi=off is specified (even if I disable the
PNP driver registration in parport_pc), and I
don't know how to change that.
Comment 17 Natalie Protasevich 2007-07-29 02:58:38 UTC

*** This bug has been marked as a duplicate of bug 6761 ***
Comment 18 Natalie Protasevich 2007-07-29 02:59:42 UTC
Nope I didnt do this!! :O How did that happen...
Comment 19 Natalie Protasevich 2008-04-04 09:38:05 UTC
Any updates on this problem please. Is the new kernel working for you Stas?
Comment 20 Bjorn Helgaas 2008-05-22 09:05:25 UTC
Created attachment 16247 [details]
test patch for ACPI CA problem

Stas, since you mention in comment #5 that "pnpacpi=off" makes things better, I think this problem is likely a symptom of an ACPI CA bug that I outlined here: http://marc.info/?l=linux-acpi&m=121141248600755&w=2

The patch I'm attaching here is definitely not the final fix, but it would be very helpful to know whether this patch fixes the problem you're seeing.
Comment 21 Stas Sergeev 2008-05-22 10:34:27 UTC
> Stas, since you mention in comment #5 that "pnpacpi=off" makes things better
It does, but only for a single reason: it allows
me to use "dma=none" parameter, which is otherwise
ignored. That's exactly what this bug is all about -
the module parameters do not work. There is nothing
else supposed to be fixed in this bug report. Only
modparams.
That, and because I won't be able to try your patch
before week-end anyway, please let me know if you
still think that I should try that patch.
Comment 22 Alan 2008-12-04 06:36:28 UTC
Closing out stale bugs
Comment 23 Stas Sergeev 2008-12-04 08:03:37 UTC
But this bug is still pretty darn valid,
and Bjorn said also in private that he'll
take a look (apparently he did not though:)
He also said that I don't need to try the
patch he asked to try here, so it is was not
stalled on my side at least. :)
So lets just promote it to the newer kernel
and see if that helps. The bug that breaks
printing cannot be rejected so easily. :)

Note You need to log in before you can comment on or make changes to this bug.