Most recent kernel where this bug did not occur:
Gigabyte GA-K8N-SLI mobo with nForce4 chipset.
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
Maybe it's close....
Anything new with this problem? still exists with new kernels?
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.
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:
*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:
On Thu, 2 Aug 2007 13:42:59 -0700 (PDT)
> > 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
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]
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
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