Bug 7492
| Summary: | parport doesn't work if DMA is used | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | Stas Sergeev (stsp2) |
| Component: | Parallel | Assignee: | drivers_parallel |
| Status: | RESOLVED OBSOLETE | ||
| Severity: | normal | CC: | akpm, alan, bjorn.helgaas, mike, protasnb, rdunlap, xerofoify |
| Priority: | P2 | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Kernel Version: | 2.6.27 | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
| Attachments: | dmesg | ||
|
Description
Stas Sergeev
2006-11-11 00:45:47 UTC
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 |