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