Bug 7491

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.

> 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?

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.

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 :)

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?

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.

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.

Any updates with this? It looks like the patch needs testing/review.
Thanks.

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.

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.

> 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.

Created attachment 12155 [details]
dmesg for Bjorn Helgaas

Your patch gives no relief.

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...

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.

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".

> 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.

*** This bug has been marked as a duplicate of bug 6761 ***

Nope I didnt do this!! :O How did that happen...

Any updates on this problem please. Is the new kernel working for you Stas?

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.

> 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.

Closing out stale bugs

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. :)