Most recent kernel where this bug did not occur: no idea Distribution: FC6 Hardware Environment: Gigabyte GA-K8N-SLI mobo with nForce4 chipset. Software Environment: Problem Description: The parport_pc module uses the DMA on my chipset, disregarding its module params. And when it does so, the parport doesn't seem to work right. If I try to print something, the printer only prints a garbage and spoils the paper. While it is a bug that I can't disable the DMA with the modparams, the DMA itself should work too. Let me know if any additional info is needed. Steps to reproduce: Get the mobo mentioned above and try to print something on a parallel printer. You'll have the bad results.
Is this on 64-bit kernel? If yes, read http://bugzilla.kernel.org/show_bug.cgi?id=5832 Maybe it's close....
Anything new with this problem? still exists with new kernels? Thanks.
Sorry if I forget to answer this. Its still the same with 2.6.22.
Please provide the exact module args whcih you are using.
> Please provide the exact module args whcih you are using. None. They do not work anyway. The details about why they do not work and what have been done in an attempt to get them to work, see Bug #7491.
And if someone is wondering, here is the dmesg: http://bugzilla.kernel.org/attachment.cgi?id=12156&action=view
*what* "do not work anyway"? You've obviously attempted to use some module parameter to disable DMA and found that it failed to do so. OK, what was that module parameter? And sure, fixing the module-parameter handling won't fix the DMA problem, but one thing at a time..
> *what* "do not work anyway"? The modparams of parport_pc. irq= dma= whatever. > You've obviously attempted to use some module parameter to disable DMA > and found that it failed to do so. And so I created the Bug #7491. > OK, what was that module parameter? "dma=none" mainly, but please visit the appropriate report itself for more info. > And sure, fixing the module-parameter handling won't fix the DMA problem, > but one thing at a time.. Yes, so that's why I have two separate reports opened for that and trying to prevent people from mixing these problems together. :)
OK, as you are probably only reading the email notifications, it does not provide you with the direct link to "Bug #7491" (whereas the web interface does) so here it is: http://bugzilla.kernel.org/show_bug.cgi?id=7491
Reply-To: akpm@linux-foundation.org On Thu, 2 Aug 2007 13:42:59 -0700 (PDT) bugme-daemon@bugzilla.kernel.org wrote: > > And sure, fixing the module-parameter handling won't fix the DMA problem, > > but one thing at a time.. > Yes, so that's why I have two separate reports > opened for that and trying to prevent people > from mixing these problems together. :) doh. OK, thanks, that was the right thing to do ;) Now we just need to find someone to fix the dang bugs. We're working on it.
Stas, any luck with recent kernel? There were updates in this area since, can you re-test please.
Maybe there were some updates - last time I tried, the printer used to jam all the paper. Now it simply doesn't print at all, which is better from some point of view. pnpacpi=off still fixes it, so apparently the problem is still there. Could you please point to me to these updates and maybe it will give me some clue about the problem?
It was massive update from Bjorn on PNPACPI a couple days ago. You should probably try the latest git. Copying to Bjorn...
Ah, it will unlikely to help then. The pnpacpi is guilty here only by enabling the DMA for parport_pc. I suppose the DMA handling in parport_pc is broken. Just disabling DMA by _some_ means (very difficult with the nonfunctional module params) gets the printer back to work.
As per Bjorn's request. I tested this on 2.6.27. I also looked into Windows driver resource usage, and it claims to use DMA 3 and works fine in ECP mode. I think Bug #5832 should be reopened or marked as a duplicate of this one.
Thanks, Stas. Did you happen to collect the pnp.debug log? I doubt that you're seeing the same issue as Bug #5832, but it's certainly possible that another defect causes the same symptom.
Created attachment 19238 [details] dmesg Here's the dmesg with CONFIG_PNP_DEBUG. pnp.debug option seem to be ignored though.
This bug is against a obsolete kernel ,can you test with a stable kernel newer then 3.10. If it's fixed please close this bug , otherwise change to the kernel version tested. Thanks Nick
Of course I can't do that 6 years later. No such printer, no such motherboard. Bug #5832 (which is a duplicate of this one) have died for the same reason: nothing was fixed, but the reporter no longer have the needed hardware.
I think the reality is that par ports are now dying and this will never get fixed. So lets admit reality and close the bug