Bug 105051

Summary: parport_pc module fails to use ECP/DMA
Product: [Retired] Red Hat Raw Hide Reporter: Ralf Ertzinger <redhat-bugzilla>
Component: kernelAssignee: Dave Jones <davej>
Status: CLOSED WONTFIX QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 1.0CC: mitr, pfrields, twaugh
Target Milestone: ---   
Target Release: ---   
Hardware: athlon   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-10-30 03:53:12 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Ralf Ertzinger 2003-09-24 23:20:53 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703

Description of problem:
When using the parallel port module parport_pc, the kernel fails to detect and
use the ECP/DMA capabilities of the on-board parallel port.
Due to this, printing takes a lot of system resources.
The very same hardware configuration works fine with an installed RH 7.2 using a
homegrown 2.4.21-ck1 kernel, detecting and using DMA.

Relevant contents of /etc/modules.conf in 7.2 and RawHide:

alias parport_lowlevel parport_pc
options parport_pc io=0x378 irq=7 dma=3



Kernel messages booting 7.2 w/ 2.4.21-ck1:

nausicaa kernel: parport 0x378 (WARNING): CTR: wrote 0x0c, read 0x0f
nausicaa kernel: parport0: PC-style at 0x378 (0x778), irq 7, dma 3
[PCSPP,TRISTATE,COMPAT,ECP,DMA]
nausicaa kernel: lp0: using parport0 (interrupt-driven).



Kernel messages booting RawHide w/ 2.4.22-1.2061.nptl:

nausicaa kernel: parport 0x378 (WARNING): CTR: wrote 0x0c, read 0x0f
nausicaa kernel: parport0: PC-style at 0x378 (0x778), irq 7 [PCSPP,TRISTATE]
nausicaa kernel: lp0: using parport0 (interrupt-driven).



The parallel port is contained in a VIA686A Southbridge.
lspci output:
00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev 02)
00:01.0 PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 AGP]
00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 22)
00:07.1 IDE interface: VIA Technologies, Inc.
VT82C586A/B/VT82C686/A/B/VT8233/A/C/VT8235 PIPC Bus Master IDE (rev 10)
00:07.2 USB Controller: VIA Technologies, Inc. USB (rev 10)
00:07.3 USB Controller: VIA Technologies, Inc. USB (rev 10)
00:07.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 30)
00:09.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone] (rev 30)
00:0d.0 Multimedia audio controller: Ensoniq 5880 AudioPCI (rev 02)
00:0f.0 SCSI storage controller: Adaptec AHA-2940U/UW/D / AIC-7881U
01:00.0 VGA compatible controller: nVidia Corporation NV11 [GeForce2 MX/MX 400]
(rev a1)

/proc/dma on 2.4.22-1.2061.nptl shows DMA3 as not in use. IRQ7 is not shared
with any other devices. This happens with and without (default) ACPI.

Version-Release number of selected component (if applicable):
kernel-2.4.22-1.2061.nptl

How reproducible:
Always

Steps to Reproduce:
1. Add "dma=3" to the parport_pc options in modules.conf
2. Unload/load the parport_pc module
3. Look at the syslog messages
    

Actual Results:  syslog and /proc/dma show that the parport_pc module does not
use DMA, and that ECP is not detected.

Expected Results:  DMA and ECP ought to be used, booting a self-compiled kernel
with RH 7.2 shows that it can be used and works fine.

Additional info:

Comment 1 Tim Waugh 2003-12-23 13:02:06 UTC
Works fine for you -- but there are still lots of reports floating
about of it being unreliable.

Comment 2 Ralf Ertzinger 2003-12-23 13:11:59 UTC
So, I'd understand why the driver does not use ECP/DMA by default. But
since I know it works for me, I'd like to force it (by giving the
appropriate irq and dma parameters in /etc/mod{ules,probe}.conf.
It is a little sad to see a 1.2 GHz machine waste 40% of it's cycles
for pushing bytes to the parallel port, after all.