[1.] One line summary of the problem:
CD burning at 16x uses excessive CPU, although DMA is enabled
[2.] Full description of the problem/report:
My system seems to use a lot of CPU time when writing CDs at 16x. The
system is unable to feed the burning software's buffer fast enough when
burning software (cdrecord 1.11a20, cdrdao 1.1.5) is run as normal user.
If run as root, system is almost unresponsive during the burn.
This concerns only audio and raw data burns, burning of ISO images goes
fine with very little load. 12x and 8x burns are also fine, although
using serial ports is error prone while even a 8x burn is going on.
CD Writer is LG GCE-8160B, secondary master, alone in the cable. CD
writer and HD has DMA enabled, by default writer uses mdma2. Other modes
have been tried, but no change. Disabling DMA does not help.
This problem does not happen in FreeBSD 4.5-STABLE with cdrecord 1.11a20.
[3.] Keywords (i.e., modules, networking, kernel):
CD writing, ATAPI, SG
[4.] Kernel version (from /proc/version):
2.4.18, 2.4.16, 2.2.19, 2.4.19pre6
[7.] Environment
[7.1.] Software (add the output of the ver_linux script here)
Linux dorkstar 2.4.18 #2 Wed Apr 3 22:03:26 EEST 2002 i686 unknown
Gnu C 2.95.4
Gnu make 3.79.1
util-linux 2.11n
mount 2.11n
modutils 2.4.13
e2fsprogs 1.26
Linux C Library 2.2.5
Dynamic linker (ldd) 2.2.5
Procps 2.0.7
Net-tools 1.60
Kbd command
Sh-utils 2.0.11
Modules Loaded sg cmpci soundcore ncr53c8xx isofs via686a i2c-proc i2c-isa i2c-core autofs4 lirc_serial ip_conntrack_ftp ipt_REJECT ipt_limit ipt_LOG ipt_state ip_conntrack iptable_filter ip_tables 3c59x ide-scsi sr_mod cdrom rtc nls_iso8859-1 nls_cp437 vfat fat
[7.2.] Processor information (from /proc/cpuinfo):
processor : 0
vendor_id : AuthenticAMD
cpu family : 6
model : 3
model name : AMD Duron(tm) processor
stepping : 1
cpu MHz : 799.649
cache size : 64 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr syscall mmxext 3dnowext 3dnow
bogomips : 1595.80
[7.3.] Module information (from /proc/modules):
sg 25124 0 (autoclean)
cmpci 25380 0 (autoclean)
soundcore 3652 2 (autoclean) [cmpci]
ncr53c8xx 53184 0
isofs 18016 0 (autoclean)
via686a 8036 0 (unused)
i2c-proc 6144 0 [via686a]
i2c-isa 1188 0 (unused)
i2c-core 13128 0 [via686a i2c-proc i2c-isa]
autofs4 8644 2 (autoclean)
lirc_serial 7520 0
ip_conntrack_ftp 3424 0 (unused)
ipt_REJECT 2976 1 (autoclean)
ipt_limit 928 3 (autoclean)
ipt_LOG 3200 13 (autoclean)
ipt_state 576 2 (autoclean)
ip_conntrack 13548 2 (autoclean) [ip_conntrack_ftp ipt_state]
iptable_filter 1760 1 (autoclean)
ip_tables 10944 5 [ipt_REJECT ipt_limit ipt_LOG ipt_state iptable_filter]
3c59x 25608 1 (autoclean)
ide-scsi 7712 0 (autoclean)
sr_mod 13624 0 (autoclean)
cdrom 28512 0 (autoclean) [sr_mod]
rtc 5656 0 (autoclean)
nls_iso8859-1 2848 2 (autoclean)
nls_cp437 4384 2 (autoclean)
vfat 9916 2 (autoclean)
fat 31576 0 (autoclean) [vfat]
[7.4.] Loaded driver and hardware information (/proc/ioports, /proc/iomem)
/proc/ioports :
0000-001f : dma1
0020-003f : pic1
0040-005f : timer
0060-006f : keyboard
0070-007f : rtc
0080-008f : dma page reg
00a0-00bf : pic2
00c0-00df : dma2
00f0-00ff : fpu
0170-0177 : ide1
01f0-01f7 : ide0
0376-0376 : ide1
03c0-03df : vga+
03f6-03f6 : ide0
03f8-03ff : lirc_serial
0cf8-0cff : PCI conf1
5000-500f : VIA Technologies, Inc. VT82C686 [Apollo Super ACPI]
6000-607f : VIA Technologies, Inc. VT82C686 [Apollo Super ACPI]
6000-607f : via686a-sensors
c000-c00f : VIA Technologies, Inc. Bus Master IDE
c000-c007 : ide0
c008-c00f : ide1
c400-c41f : VIA Technologies, Inc. UHCI USB
c800-c81f : VIA Technologies, Inc. UHCI USB (#2)
cc00-ccff : ATI Technologies Inc 3D Rage Pro 215GP
d000-d07f : 3Com Corporation 3c905C-TX [Fast Etherlink]
d000-d07f : 00:09.0
d400-d4ff : LSI Logic / Symbios Logic (formerly NCR) 53c810
d400-d47f : ncr53c8xx
d800-d8ff : C-Media Electronics Inc CM8738
d800-d8ff : cmpci
dc00-dc07 : Promise Technology, Inc. 20265
dc00-dc07 : ide2
e000-e003 : Promise Technology, Inc. 20265
e002-e002 : ide2
e400-e407 : Promise Technology, Inc. 20265
e800-e803 : Promise Technology, Inc. 20265
ec00-ec3f : Promise Technology, Inc. 20265
ec00-ec07 : ide2
ec08-ec0f : ide3
ec10-ec3f : PDC20265
/proc/iomem:
00000000-0009fbff : System RAM
0009fc00-0009ffff : reserved
000a0000-000bffff : Video RAM area
000c0000-000c7fff : Video ROM
000f0000-000fffff : System ROM
00100000-0ffeffff : System RAM
00100000-001fe615 : Kernel code
001fe616-0024a0b7 : Kernel data
0fff0000-0fff2fff : ACPI Non-volatile Storage
0fff3000-0fffffff : ACPI Tables
d0000000-d7ffffff : PCI Bus #01
d0000000-d7ffffff : nVidia Corporation NV11 (GeForce2 MX)
d8000000-dbffffff : VIA Technologies, Inc. VT8363/8365 [KT133/KM133]
dc000000-ddffffff : PCI Bus #01
dc000000-dcffffff : nVidia Corporation NV11 (GeForce2 MX)
de000000-deffffff : ATI Technologies Inc 3D Rage Pro 215GP
e0000000-e001ffff : Promise Technology, Inc. 20265
e0020000-e002007f : 3Com Corporation 3c905C-TX [Fast Etherlink]
e0021000-e00210ff : LSI Logic / Symbios Logic (formerly NCR) 53c810
e0022000-e0022fff : ATI Technologies Inc 3D Rage Pro 215GP
ffff0000-ffffffff : reserved
[7.5.] PCI information ('lspci -vvv' as root)
00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev 03)
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ >SERR- <PERR+
Latency: 0
Region 0: Memory at d8000000 (32-bit, prefetchable) [size=64M]
Capabilities: [a0] AGP version 2.0
Status: RQ=31 SBA+ 64bit- FW- Rate=x1,x2
Command: RQ=0 SBA- AGP- 64bit- FW- Rate=<none>
Capabilities: [c0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:01.0 PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 AGP] (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ >SERR- <PERR-
Latency: 0
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
I/O behind bridge: 0000f000-00000fff
Memory behind bridge: dc000000-ddffffff
Prefetchable memory behind bridge: d0000000-d7ffffff
BridgeCtl: Parity- SERR- NoISA+ VGA+ MAbort- >Reset- FastB2B-
Capabilities: [80] Power Management version 2
Flags: PMEClk- DSI- D1+ D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 40)
Subsystem: VIA Technologies, Inc. VT82C686/A PCI to ISA Bridge
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Capabilities: [c0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:07.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 06) (prog-if 8a [Master SecP PriP])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 32
Region 4: I/O ports at c000 [size=16]
Capabilities: [c0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:07.2 USB Controller: VIA Technologies, Inc. UHCI USB (rev 16) (prog-if 00 [UHCI])
Subsystem: Unknown device 0925:1234
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 32, cache line size 08
Interrupt: pin D routed to IRQ 5
Region 4: I/O ports at c400 [size=32]
Capabilities: [80] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:07.3 USB Controller: VIA Technologies, Inc. UHCI USB (rev 16) (prog-if 00 [UHCI])
Subsystem: Unknown device 0925:1234
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 32, cache line size 08
Interrupt: pin D routed to IRQ 5
Region 4: I/O ports at c800 [size=32]
Capabilities: [80] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:07.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 40)
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Interrupt: pin ? routed to IRQ 9
Capabilities: [68] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:08.0 VGA compatible controller: ATI Technologies Inc 3D Rage Pro 215GP (rev 5c) (prog-if 00 [VGA])
Subsystem: ATI Technologies Inc: Unknown device 0000
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Region 0: Memory at de000000 (32-bit, prefetchable) [disabled] [size=16M]
Region 1: I/O ports at cc00 [disabled] [size=256]
Region 2: Memory at e0022000 (32-bit, non-prefetchable) [disabled] [size=4K]
Expansion ROM at <unassigned> [disabled] [size=128K]
00:09.0 Ethernet controller: 3Com Corporation 3c905C-TX [Fast Etherlink] (rev 74)
Subsystem: 3Com Corporation 3C905C-TX Fast Etherlink for PC Management NIC
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 32 (2500ns min, 2500ns max), cache line size 08
Interrupt: pin A routed to IRQ 10
Region 0: I/O ports at d000 [size=128]
Region 1: Memory at e0020000 (32-bit, non-prefetchable) [size=128]
Expansion ROM at <unassigned> [disabled] [size=128K]
Capabilities: [dc] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=2 PME-
00:0a.0 SCSI storage controller: LSI Logic / Symbios Logic (formerly NCR) 53c810 (rev 02)
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 32
Interrupt: pin A routed to IRQ 11
Region 0: I/O ports at d400 [size=256]
Region 1: Memory at e0021000 (32-bit, non-prefetchable) [size=256]
00:0d.0 Multimedia audio controller: C-Media Electronics Inc CM8738 (rev 10)
Subsystem: C-Media Electronics Inc CMI8738/C3DX PCI Audio Device
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 32 (500ns min, 6000ns max)
Interrupt: pin A routed to IRQ 10
Region 0: I/O ports at d800 [size=256]
Capabilities: [c0] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:0f.0 RAID bus controller: Promise Technology, Inc. 20265 (rev 02)
Subsystem: Promise Technology, Inc.: Unknown device 4d33
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 32
Interrupt: pin A routed to IRQ 10
Region 0: I/O ports at dc00 [size=8]
Region 1: I/O ports at e000 [size=4]
Region 2: I/O ports at e400 [size=8]
Region 3: I/O ports at e800 [size=4]
Region 4: I/O ports at ec00 [size=64]
Region 5: Memory at e0000000 (32-bit, non-prefetchable) [size=128K]
Expansion ROM at <unassigned> [disabled] [size=64K]
Capabilities: [58] Power Management version 1
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
01:00.0 VGA compatible controller: nVidia Corporation NV11 (GeForce2 MX) (rev a1) (prog-if 00 [VGA])
Subsystem: Elsa AG: Unknown device 0c60
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 32 (1250ns min, 250ns max)
Interrupt: pin A routed to IRQ 5
Region 0: Memory at dc000000 (32-bit, non-prefetchable) [size=16M]
Region 1: Memory at d0000000 (32-bit, prefetchable) [size=128M]
Expansion ROM at <unassigned> [disabled] [size=64K]
Capabilities: [60] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [44] AGP version 2.0
Status: RQ=31 SBA- 64bit- FW+ Rate=x1,x2
Command: RQ=0 SBA- AGP- 64bit- FW- Rate=<none>
[7.6.] SCSI information (from /proc/scsi/scsi)
Attached devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00
Vendor: HL-DT-ST Model: CD-RW GCE-8160B Rev: 2.01
Type: CD-ROM ANSI SCSI revision: 02
Host: scsi1 Channel: 00 Id: 00 Lun: 00
Vendor: NEC Model: CD-ROM DRIVE:462 Rev: 1.16
Type: CD-ROM ANSI SCSI revision: 02
Host: scsi1 Channel: 00 Id: 02 Lun: 00
Vendor: RICOH Model: CD-R/RW MP7060S Rev: 1.70
Type: CD-ROM ANSI SCSI revision: 02
On Mon, 8 Apr 2002, Anssi Saari wrote:
> [1.] One line summary of the problem:
> CD burning at 16x uses excessive CPU, although DMA is enabled
That's a hint things are not working as you expect...
> [2.] Full description of the problem/report:
> My system seems to use a lot of CPU time when writing CDs at 16x. The
> system is unable to feed the burning software's buffer fast enough when
> burning software (cdrecord 1.11a20, cdrdao 1.1.5) is run as normal user.
> If run as root, system is almost unresponsive during the burn.
With all the information you provided, you have totally not quatified
how much CPU you find "excessive." I would not be surprised to see 10-15%
of the CPU, virtually all in system time, as a normal burn of an ISO
image. If the time is in user mode with other image types, it may well be
that you are doing something which actually requires a lot of CPU (byte
swapping or some such).
Going from a disk to a CD using DMA on both should not take much
*system* CPU, even if these are ATAPI (assuming they are not on the same
cable).
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
I'm not completely sure about burning audio, but linux doesn't read
audio cds using DMA. It just wont on ide devices. You can use a patch
that allows this from andrew morton. I dont write many audio cds so
I've never tested it's effect on writing a cd, only reading. I imagine
it's not safe to use dma on raw/audio cds. but go check it out
anyways.
On Mon, 2002-04-08 at 10:54, Bill Davidsen wrote:
> On Mon, 8 Apr 2002, Anssi Saari wrote:
>
> > [1.] One line summary of the problem:
> > CD burning at 16x uses excessive CPU, although DMA is enabled
>
> That's a hint things are not working as you expect...
>
> > [2.] Full description of the problem/report:
> > My system seems to use a lot of CPU time when writing CDs at 16x. The
> > system is unable to feed the burning software's buffer fast enough when
> > burning software (cdrecord 1.11a20, cdrdao 1.1.5) is run as normal user.
> > If run as root, system is almost unresponsive during the burn.
>
> With all the information you provided, you have totally not quatified
> how much CPU you find "excessive." I would not be surprised to see 10-15%
> of the CPU, virtually all in system time, as a normal burn of an ISO
> image. If the time is in user mode with other image types, it may well be
> that you are doing something which actually requires a lot of CPU (byte
> swapping or some such).
>
> Going from a disk to a CD using DMA on both should not take much
> *system* CPU, even if these are ATAPI (assuming they are not on the same
> cable).
>
> --
> bill davidsen <[email protected]>
> CTO, TMR Associates, Inc
> Doing interesting things with little computers since 1979.
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
On Mon, Apr 08, 2002 at 10:54:29AM -0400, Bill Davidsen wrote:
> On Mon, 8 Apr 2002, Anssi Saari wrote:
>
> > [1.] One line summary of the problem:
> > CD burning at 16x uses excessive CPU, although DMA is enabled
>
> That's a hint things are not working as you expect...
>
> > [2.] Full description of the problem/report:
> > My system seems to use a lot of CPU time when writing CDs at 16x. The
> > system is unable to feed the burning software's buffer fast enough when
> > burning software (cdrecord 1.11a20, cdrdao 1.1.5) is run as normal user.
> > If run as root, system is almost unresponsive during the burn.
>
> With all the information you provided, you have totally not quatified
> how much CPU you find "excessive."
I didn't really know how to put it. Maybe system load would be better. But
the actual problem is, I effectively can't burn audio and other types
at 16x in Linux, while there is no problem in some other operating systems
with the same hardware and applications.
Here're some time figures from cdrdao:
cdrdao simulate -n --speed 8 foo.cue 2.62s user 3.37s system 1% cpu 6:41.86 total
cdrdao simulate -n --speed 12 foo.cue 2.78s user 29.91s system 12% cpu 4:31.71 total
cdrdao simulate -n --speed 16 foo.cue 2.67s user 128.77s system 52% cpu 4:10.68 total
So yes, system time goes up quite steeply.
But even though 50% is quite high, CPU load is not the problem as such,
the problem is getting data to the writer fast enough. And it's not
happening. Even a single audio track that is completely cached so that
there is no HD access has problems. It's like somehow accessing the CD
writer hogs the system for such long periods that there is insufficient
time to fill the writing program's buffer.
One thing I noticed just now. If I turn off unmaskirq for the CD writer
with hdparm -u 0 /dev/hdc, it helps a little, but not enough. Time
reports now:
cdrdao simulate -n --speed 16 foo.cue 2.75s user 75.18s system 58% cpu
2:13.22 total
On 8 Apr 2002, Ed Sweetman wrote:
> I'm not completely sure about burning audio, but linux doesn't read
> audio cds using DMA. It just wont on ide devices. You can use a patch
> that allows this from andrew morton. I dont write many audio cds so
> I've never tested it's effect on writing a cd, only reading. I imagine
> it's not safe to use dma on raw/audio cds. but go check it out
> anyways.
I've seen the patch, but the OP was posting about burning CDs. My
recollection is that even audio CDs don't use much CPU with DMA, but there
might be lots of options and stuff involved. I've asked for a breakdown of
CPU use so we can see if it's user or system, how much, etc.
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
On Mon, Apr 08, 2002 at 11:06:28AM -0400, Ed Sweetman wrote:
> I'm not completely sure about burning audio, but linux doesn't read
> audio cds using DMA.
I didn't think this is relevant, except if I were trying to copy a CD on
the fly, but that's not the case. But I have now tried it, no change. In
fact, what I tried was this linux-2.4.19-pre5-jam2 patch collection
which includes that and low latency and O(1) scheduler patches, among
other things. Didn't seem to help, however.
On Mon, 8 Apr 2002, Anssi Saari wrote:
> On Mon, Apr 08, 2002 at 10:54:29AM -0400, Bill Davidsen wrote:
> > On Mon, 8 Apr 2002, Anssi Saari wrote:
> >
> > > [1.] One line summary of the problem:
> > > CD burning at 16x uses excessive CPU, although DMA is enabled
> >
> > That's a hint things are not working as you expect...
> >
> > > [2.] Full description of the problem/report:
> > > My system seems to use a lot of CPU time when writing CDs at 16x. The
> > > system is unable to feed the burning software's buffer fast enough when
> > > burning software (cdrecord 1.11a20, cdrdao 1.1.5) is run as normal user.
> > > If run as root, system is almost unresponsive during the burn.
> >
> > With all the information you provided, you have totally not quatified
> > how much CPU you find "excessive."
>
> I didn't really know how to put it. Maybe system load would be better. But
> the actual problem is, I effectively can't burn audio and other types
> at 16x in Linux, while there is no problem in some other operating systems
> with the same hardware and applications.
>
> Here're some time figures from cdrdao:
>
> cdrdao simulate -n --speed 8 foo.cue 2.62s user 3.37s system 1% cpu 6:41.86 total
> cdrdao simulate -n --speed 12 foo.cue 2.78s user 29.91s system 12% cpu 4:31.71 total
> cdrdao simulate -n --speed 16 foo.cue 2.67s user 128.77s system 52% cpu 4:10.68 total
>
> So yes, system time goes up quite steeply.
Okay, this is good information. At the risk of asking a dumb question,
are you sure that both the burner and the source drive ar using DMA? And
that they are on separate cables (controllers)? Usually the high system
time indicated either PIO in use or some path looping in the kernel.
> cdrdao simulate -n --speed 16 foo.cue 2.75s user 75.18s system 58% cpu
> 2:13.22 total
That's still high. My only fast burners are in the office, if I get back
during the week I'll run a test at 16 and 24x and see what I find.
This would be a good question for the CD writing list,
[email protected].
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
On Mon, Apr 08, 2002 at 01:35:35PM -0400, Bill Davidsen wrote:
> Okay, this is good information. At the risk of asking a dumb question,
> are you sure that both the burner and the source drive ar using DMA?
I'm fairly certain. I can read that test image at ~37MB/s and 35% CPU,
which can't be PIO. The CD writer reads at ~3.7MB/s and 3% CPU usage.
> that they are on separate cables (controllers)?
Yes. Two HDs, one writer, all on different channels. The other HD is on
the motherboards Promise 20265 "raid" controller.
> This would be a good question for the CD writing list,
> [email protected].
I tried that some time ago. So far, this is a sort of repetition of
that. Joerg Schilling suggested that maybe I don't have DMA on or the
reader and writer are on the same cable. Other discussion was off topic...
In fact, I've also had this conversation from the other point of view
with someone else, who was asking about this same problem in the finnish
Linux group, sfnet.atk.linux. Now I have the same LG CD writer, the same
VIA KT133A chipset, the same problem and the same discussion... I'd be
amused if the problem weren't still unresolved.
I decided to post here after I tried FreeBSD, didn't have a problem
and thus it seemed likely that this is a Linux specific problem.
I think I'll try to put together another system and see what happens
there. I wonder if SGI's kernprof thing would be useful with this.
I'll try that too, when I have the time.
Hi,
I tested with my computer - the CD-R:s that I had
limited the testing to 10x. But when testing
that it indicated 33% CPU in system, but not accouted
to any process by top.
I have done some profiling with my kernel
2.4.17-rmap12f
I think this indicates that the time spent for this kernel is
IRQ happening during idle time - correct?
I am not sure that this is the same situation that Anssi has
but 33% are quite a lot (more than he got, DMAs are enabled).
But at least it is another comparative datapoint...
/RogerL
--- output from readprofile (>=3) ------------------
3 __aux_write_ack 0.0938
3 kmalloc 0.0115
3 pipe_poll 0.0300
3 sys_select 0.0026
4 add_wait_queue 0.1000
4 link_path_walk 0.0021
4 rest_init 0.1000
4 rmqueue 0.0059
4 tasklet_action 0.0303
4 timer_bh 0.0066
5 __free_pages_ok 0.0068
5 sock_poll 0.1250
6 __rdtsc_delay 0.2143
6 __switch_to 0.0326
6 __wake_up 0.0375
6 kfree 0.0405
7 fget 0.1750
7 poll_freewait 0.1029
7 sys_write 0.0357
8 unix_poll 0.0541
9 schedule 0.0110
11 do_softirq 0.0671
12 do_anonymous_page 0.0517
12 do_select 0.0252
23 handle_IRQ_event 0.2614
24 file_read_actor 0.1765
5960 ide_intr 17.7381
36056 default_idle 901.4000
42283 total 0.0418
On m?ndagen den 8 april 2002 21.06, Anssi Saari wrote:
> On Mon, Apr 08, 2002 at 01:35:35PM -0400, Bill Davidsen wrote:
> > Okay, this is good information. At the risk of asking a dumb question,
> > are you sure that both the burner and the source drive ar using DMA?
>
> I'm fairly certain. I can read that test image at ~37MB/s and 35% CPU,
> which can't be PIO. The CD writer reads at ~3.7MB/s and 3% CPU usage.
>
> > that they are on separate cables (controllers)?
>
> Yes. Two HDs, one writer, all on different channels. The other HD is on
> the motherboards Promise 20265 "raid" controller.
>
> > This would be a good question for the CD writing list,
> > [email protected].
>
> I tried that some time ago. So far, this is a sort of repetition of
> that. Joerg Schilling suggested that maybe I don't have DMA on or the
> reader and writer are on the same cable. Other discussion was off topic...
>
> In fact, I've also had this conversation from the other point of view
> with someone else, who was asking about this same problem in the finnish
> Linux group, sfnet.atk.linux. Now I have the same LG CD writer, the same
> VIA KT133A chipset, the same problem and the same discussion... I'd be
> amused if the problem weren't still unresolved.
>
> I decided to post here after I tried FreeBSD, didn't have a problem
> and thus it seemed likely that this is a Linux specific problem.
>
> I think I'll try to put together another system and see what happens
> there. I wonder if SGI's kernprof thing would be useful with this.
> I'll try that too, when I have the time.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Roger Larsson
Skellefte?
Sweden
I think the fact that it works with FreeBSD should have been enough
to show that 'excessive' doesn't need to be qualified.
The question is, how is CD burning of raw data different from
CD burning of ISO images, in respect to Linux drivers for the
hardware, and why does FreeBSD not suffer from this ailment?
mark
On Mon, Apr 08, 2002 at 10:54:29AM -0400, Bill Davidsen wrote:
> On Mon, 8 Apr 2002, Anssi Saari wrote:
>
> > [1.] One line summary of the problem:
> > CD burning at 16x uses excessive CPU, although DMA is enabled
>
> That's a hint things are not working as you expect...
>
> > [2.] Full description of the problem/report:
> > My system seems to use a lot of CPU time when writing CDs at 16x. The
> > system is unable to feed the burning software's buffer fast enough when
> > burning software (cdrecord 1.11a20, cdrdao 1.1.5) is run as normal user.
> > If run as root, system is almost unresponsive during the burn.
>
> With all the information you provided, you have totally not quatified
> how much CPU you find "excessive." I would not be surprised to see 10-15%
> of the CPU, virtually all in system time, as a normal burn of an ISO
> image. If the time is in user mode with other image types, it may well be
> that you are doing something which actually requires a lot of CPU (byte
> swapping or some such).
>
> Going from a disk to a CD using DMA on both should not take much
> *system* CPU, even if these are ATAPI (assuming they are not on the same
> cable).
--
[email protected]/[email protected]/[email protected] __________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder
|\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ |
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada
One ring to rule them all, one ring to find them, one ring to bring them all
and in the darkness bind them...
http://mark.mielke.cc/
On Mon, 8 Apr 2002, Mark Mielke wrote:
> I think the fact that it works with FreeBSD should have been enough
> to show that 'excessive' doesn't need to be qualified.
>
> The question is, how is CD burning of raw data different from
> CD burning of ISO images, in respect to Linux drivers for the
> hardware, and why does FreeBSD not suffer from this ailment?
Let's say it didn't give me a clue how much time was being used and
where. There are various options like bytes swap which could drive up user
time, and other things like PIO which drive up system.
I find I give a better quality of help if I understand the problem...
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
On Mon, Apr 08, 2002 at 05:45:29PM -0400, Mark Mielke wrote:
> The question is, how is CD burning of raw data different from
> CD burning of ISO images, in respect to Linux drivers for the
> hardware
As far as I know, when burning an ISO image, the image has 2048 byte
sectors to which the CD writer adds error correction data so that the
individual sector becomes 2352 bytes. A raw data image includes 2352 byte
sectors. The obvious difference would be a higher data rate (2352/2048
or 1.15x more) from computer to writer.
On 8 April 2002 13:47, Anssi Saari wrote:
> I didn't really know how to put it. Maybe system load would be better. But
> the actual problem is, I effectively can't burn audio and other types
> at 16x in Linux, while there is no problem in some other operating systems
> with the same hardware and applications.
>
> Here're some time figures from cdrdao:
>
> cdrdao simulate -n --speed 8 foo.cue 2.62s user 3.37s system 1% cpu
> 6:41.86 total cdrdao simulate -n --speed 12 foo.cue 2.78s user 29.91s
> system 12% cpu 4:31.71 total cdrdao simulate -n --speed 16 foo.cue 2.67s
> user 128.77s system 52% cpu 4:10.68 total
>
> So yes, system time goes up quite steeply.
>
> But even though 50% is quite high, CPU load is not the problem as such,
> the problem is getting data to the writer fast enough. And it's not
> happening. Even a single audio track that is completely cached so that
> there is no HD access has problems. It's like somehow accessing the CD
> writer hogs the system for such long periods that there is insufficient
> time to fill the writing program's buffer.
You may try profiling kernel to see where it exactly spending that time.
It has an added benefit: you will learn how to profile kernels (if you
don't know how to do it already).
I am waiting for similar problem to bite me to learn that, too. :-)
> One thing I noticed just now. If I turn off unmaskirq for the CD writer
> with hdparm -u 0 /dev/hdc, it helps a little, but not enough. Time
> reports now:
>
> cdrdao simulate -n --speed 16 foo.cue 2.75s user 75.18s system 58% cpu
> 2:13.22 total
--
vda
On Tue, 9 Apr 2002, Anssi Saari wrote:
> Date: Tue, 9 Apr 2002 11:32:43 +0300
> From: Anssi Saari <[email protected]>
> To: Mark Mielke <[email protected]>
> Cc: [email protected]
> Subject: Re: PROMBLEM: CD burning at 16x uses excessive CPU,
> although DMA is enabled
>
> On Mon, Apr 08, 2002 at 05:45:29PM -0400, Mark Mielke wrote:
>
> > The question is, how is CD burning of raw data different from
> > CD burning of ISO images, in respect to Linux drivers for the
> > hardware
>
> As far as I know, when burning an ISO image, the image has 2048 byte
> sectors to which the CD writer adds error correction data so that the
> individual sector becomes 2352 bytes. A raw data image includes 2352 byte
> sectors. The obvious difference would be a higher data rate (2352/2048
> or 1.15x more) from computer to writer.
>
I have seen something similar when reading CD-Rs (with ISO image burnt);
After I burn a CD I run readcd -c2scan to see if I get any C2 errors;
I am using ASUS 50x CD drive, usually setting the speed to 45x before the
operation (my TEAC CD-RW drive always run at 4x when doing readcd
-c2scan, which is too slow for my patience).
The interesting thing is that while reading ISO image with dd the system
works fine, readcd -c2scan makes it often very unresponsible (just
switching between virtual desktops in KDE may take up to several seconds).
The system is Pentium III running at 720 MHz, ABIT RAID-133 motherboard,
hard disk connected to HPT-370A, CD and CD-RW drived on separate channels,
kernel 2.2.19 + IDE patches, 768 MB RAM.
I am wondering if you could possibly compare the system behaviour with
Linux and FreeBSD when using readcd -c2scan (assuming readcd -c2scan
works with your drives at some reasonable speeds).
Best regards,
Wojtek
On 9 April 2002 06:32, Anssi Saari wrote:
> On Mon, Apr 08, 2002 at 05:45:29PM -0400, Mark Mielke wrote:
> > The question is, how is CD burning of raw data different from
> > CD burning of ISO images, in respect to Linux drivers for the
> > hardware
>
> As far as I know, when burning an ISO image, the image has 2048 byte
> sectors to which the CD writer adds error correction data so that the
> individual sector becomes 2352 bytes. A raw data image includes 2352 byte
> sectors. The obvious difference would be a higher data rate (2352/2048
> or 1.15x more) from computer to writer.
It means different write command, additional (possibly less carefully
written/tested) driver code etc. You may need to track your problem
up to that driver code.
--
vda
On Mon, Apr 08, 2002 at 06:02:55PM -0400, Mark Hahn wrote:
> I think someone else already pointed out that doing
> a kernel profile would be good. strace would also
> be quite useful, even just the -c form.
Here it is:
With unmaskirq=1 first:
3 block_read_full_page 0.0059
3 fget 0.0625
3 get_unused_buffer_head 0.0234
3 kmalloc 0.0134
3 kmem_cache_free 0.0187
4 __free_pages_ok 0.0081
4 ext3_get_branch 0.0147
4 get_hash_table 0.0278
4 journal_try_to_free_buffers 0.0278
4 rmqueue 0.0093
4 scsi_old_done 0.0027
5 generic_make_request 0.0164
5 try_to_free_buffers 0.0223
6 ext3_releasepage 0.1250
6 sys_read 0.0268
6 system_call 0.1071
7 __rdtsc_delay 0.2188
7 apm_bios_call 0.0547
7 scsi_request_fn 0.0093
8 __make_request 0.0050
8 ide_wait_stat 0.0294
8 schedule 0.0091
9 ide_dmaproc 0.0161
9 start_request 0.0148
13 do_generic_file_read 0.0123
14 ide_end_request 0.0972
22 do_rw_disk 0.0229
49 handle_IRQ_event 0.5104
239 file_read_actor 2.4896
3324 default_idle 69.2500
20097 ide_output_data 104.6719
23952 total 0.0236
Number of interrupts on ide1 during burn: 17531
And then, unmaskirq=0:
3 __free_pages 0.0938
3 ext3_get_branch 0.0110
3 fget 0.0625
3 kmem_cache_reap 0.0069
3 page_cache_read 0.0156
3 scsi_block_when_processing_errors 0.0144
3 shrink_cache 0.0042
4 __make_request 0.0025
4 __rdtsc_delay 0.1250
4 __switch_to 0.0208
4 ext3_get_block_handle 0.0058
4 fput 0.0179
4 get_unused_buffer_head 0.0312
4 ide_dma_intr 0.0208
4 ide_dmaproc 0.0071
4 ide_output_data 0.0208
4 kfree 0.0250
4 kmem_cache_free 0.0250
4 rmqueue 0.0093
4 sys_read 0.0179
4 try_to_free_buffers 0.0179
6 ext3_releasepage 0.1250
6 generic_file_readahead 0.0179
6 timer_bh 0.0099
7 scsi_old_done 0.0048
8 start_request 0.0132
8 system_call 0.1429
9 ide_wait_stat 0.0331
10 do_generic_file_read 0.0095
10 ide_end_request 0.0694
10 schedule 0.0114
11 do_rw_disk 0.0115
15 apm_bios_call 0.1172
168 do_softirq 0.9545
234 file_read_actor 2.4375
1942 handle_IRQ_event 20.2292
2949 default_idle 61.4375
6808 ide_intr 18.5000
12333 total 0.0122
Number of interrupts on ide1 during burn: 17532
Strace -c with unmaskirq=1:
execve("/usr/local/bin/cdrdao", ["cdrdao", "simulate", "-n", "--speed", "16", "f
oo.cue"], [/* 34 vars */]) = 0
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
95.66 2.141856 244 8767 ioctl
2.16 0.048346 3 17516 gettimeofday
1.08 0.024089 45 534 write
0.51 0.011371 2 5826 rt_sigprocmask
0.43 0.009593 564 17 5 open
0.10 0.002251 225 10 1 read
0.03 0.000694 174 4 munmap
0.01 0.000314 1 314 nanosleep
0.01 0.000122 7 18 old_mmap
0.00 0.000055 5 12 close
0.00 0.000053 5 10 brk
0.00 0.000041 21 2 2 rt_sigsuspend
0.00 0.000033 2 16 rt_sigaction
0.00 0.000029 29 1 pipe
0.00 0.000028 3 11 fstat64
0.00 0.000024 5 5 mprotect
0.00 0.000021 21 1 clone
0.00 0.000010 10 1 wait4
0.00 0.000010 5 2 2 sigreturn
0.00 0.000008 4 2 uname
0.00 0.000008 8 1 _sysctl
0.00 0.000008 3 3 fcntl64
0.00 0.000003 3 1 1 munlockall
0.00 0.000003 2 2 geteuid32
0.00 0.000002 2 1 getpid
0.00 0.000002 2 1 setrlimit
0.00 0.000002 2 1 getrlimit
------ ----------- ----------- --------- --------- ----------------
100.00 2.238976 33079 11 total
and with unmaskirq=0:
execve("/usr/local/bin/cdrdao", ["cdrdao", "simulate", "-n", "--speed", "16", "f
oo.cue"], [/* 34 vars */]) = 0
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
99.75 35.801229 4084 8767 ioctl
0.14 0.051375 3 17516 gettimeofday
0.07 0.024269 45 534 write
0.03 0.011883 2 5826 rt_sigprocmask
0.00 0.000709 177 4 munmap
0.00 0.000267 18 15 3 open
0.00 0.000263 1 263 nanosleep
0.00 0.000117 7 18 old_mmap
0.00 0.000083 8 10 1 read
0.00 0.000057 29 2 2 rt_sigsuspend
0.00 0.000056 5 12 close
0.00 0.000048 5 10 brk
0.00 0.000036 2 16 rt_sigaction
0.00 0.000029 29 1 pipe
0.00 0.000028 3 11 fstat64
0.00 0.000026 5 5 mprotect
0.00 0.000020 20 1 clone
0.00 0.000010 5 2 2 sigreturn
0.00 0.000009 9 1 wait4
0.00 0.000008 4 2 uname
0.00 0.000008 8 1 _sysctl
0.00 0.000007 2 3 fcntl64
0.00 0.000003 3 1 setrlimit
0.00 0.000003 3 1 1 munlockall
0.00 0.000003 3 1 getrlimit
0.00 0.000003 2 2 geteuid32
0.00 0.000002 2 1 getpid
------ ----------- ----------- --------- --------- ----------------
100.00 35.890551 33026 9 total
> > But even though 50% is quite high, CPU load is not the problem as such,
>
> 50% of what CPU?
AMD Duron 800MHz. Of course it's a problem but not the main problem here.
> it would also be interesting to look at memory behavior.
How would I get that?
On tisdagen den 9 april 2002 12.01, Anssi Saari wrote:
> On Mon, Apr 08, 2002 at 06:02:55PM -0400, Mark Hahn wrote:
> > I think someone else already pointed out that doing
> > a kernel profile would be good. strace would also
> > be quite useful, even just the -c form.
>
> Here it is:
>
> With unmaskirq=1 first:
>
>
> 49 handle_IRQ_event 0.5104
> 239 file_read_actor 2.4896
> 3324 default_idle 69.2500
> 20097 ide_output_data 104.6719
Hey, what is this?
Comment of the function is:
"This is used for most PIO data transfers *to* the IDE interface"
(see /drivers/ide/ide.c:426)
Has it reverted to PIO mode?
Some information might be found with
# more /proc/ide/hd*/settings
This is how mine look like
cat /proc/ide/hdc/settings
name value min max mode
---- ----- --- --- ----
bios_cyl 0 0 1023 rw
bios_head 0 0 255 rw
bios_sect 0 0 63 rw
current_speed 66 0 69 rw
ide_scsi 0 0 1 rw
init_speed 66 0 69 rw
io_32bit 0 0 3 rw
keepsettings 0 0 1 rw
log 0 0 1 rw
nice1 1 0 1 rw
number 2 0 3 rw
pio_mode write-only 0 255 w
slow 0 0 1 rw
transform 1 0 3 rw
unmaskirq 1 0 1 rw
using_dma 1 0 1 rw
> 23952 total 0.0236
> Number of interrupts on ide1 during burn: 17531
>
> And then, unmaskirq=0:
>
> - - -
> 168 do_softirq 0.9545
> 234 file_read_actor 2.4375
> 1942 handle_IRQ_event 20.2292
> 2949 default_idle 61.4375
> 6808 ide_intr 18.5000
> 12333 total 0.0122
> Number of interrupts on ide1 during burn: 17532
This looks like mine results. Quite some time spent in interrupt
routines. (weighted 38%)
Using or not using unmaskirq does not matter for me:
It stays below 40%, but I do only run at 10x (40% is quite much
for any disk bound operation...)
I will attempt a profiling while unmasked too.
I assume you also use ide_scsi, right?
/RogerL
--
Roger Larsson
Skellefte?
Sweden
On Tue, 9 Apr 2002, Roger Larsson wrote:
> On tisdagen den 9 april 2002 12.01, Anssi Saari wrote:
> > On Mon, Apr 08, 2002 at 06:02:55PM -0400, Mark Hahn wrote:
> > > I think someone else already pointed out that doing
> > > a kernel profile would be good. strace would also
> > > be quite useful, even just the -c form.
> >
> > Here it is:
> >
> > With unmaskirq=1 first:
> >
> >
> > 49 handle_IRQ_event 0.5104
> > 239 file_read_actor 2.4896
> > 3324 default_idle 69.2500
> > 20097 ide_output_data 104.6719
>
> Hey, what is this?
>
> Comment of the function is:
> "This is used for most PIO data transfers *to* the IDE interface"
> (see /drivers/ide/ide.c:426)
> Has it reverted to PIO mode?
This is because there are not a proper and correct state diagram data
handler set for ATAPI, period. Initially the driver evolved out of PIO
calls to the PACKET_COMMAND opcode for the ATA command set. Since there
has been zero updates/attempts to create a proper ATAPI/ASPI by anyone,
you can expect PIO transactions.
Who knows once I finally have taskfile completed and the kernel fixed to
not violate the basics of hardware atomic for storage devices, I may fix
all of the atapi/aspi transport. It is a real mess to grunt through all
the docs. However, I suspect I could get some help (co-author a
standard's proposal) with the original author to outline and create a 500+
page techincal referrence guide. So if there are any companies want to
fund such an adventure, please let me know off-line.
Understand that only in PIO can you be sure of how much data you could get
from a device, argh it still s a pig in a poke.
Cheers,
Andre Hedrick
LAD Storage Consulting Group
On Tue, 09 Apr 2002, Andre Hedrick wrote:
> This is because there are not a proper and correct state diagram data
> handler set for ATAPI, period. Initially the driver evolved out of PIO
> calls to the PACKET_COMMAND opcode for the ATA command set. Since there
> has been zero updates/attempts to create a proper ATAPI/ASPI by anyone,
> you can expect PIO transactions.
>
> Who knows once I finally have taskfile completed and the kernel fixed to
> not violate the basics of hardware atomic for storage devices, I may fix
> all of the atapi/aspi transport. It is a real mess to grunt through all
> the docs. However, I suspect I could get some help (co-author a
> standard's proposal) with the original author to outline and create a 500+
> page techincal referrence guide. So if there are any companies want to
> fund such an adventure, please let me know off-line.
>
> Understand that only in PIO can you be sure of how much data you could get
> from a device, argh it still s a pig in a poke.
How about Andrew Morton's akpm-ide patch?
http://www.zipworld.com.au/~akpm/linux/patches/2.4/2.4.18-pre9/ide-akpm.patch
--
Matthias Andree
On Tue, Apr 09, 2002 at 01:27:48PM -0700, Andre Hedrick wrote:
> On Tue, 9 Apr 2002, Roger Larsson wrote:
>
> > On tisdagen den 9 april 2002 12.01, Anssi Saari wrote:
> > > On Mon, Apr 08, 2002 at 06:02:55PM -0400, Mark Hahn wrote:
> > > > I think someone else already pointed out that doing
> > > > a kernel profile would be good. strace would also
> > > > be quite useful, even just the -c form.
> > >
> > > Here it is:
> > >
> > > With unmaskirq=1 first:
> > >
> > >
> > > 49 handle_IRQ_event 0.5104
> > > 239 file_read_actor 2.4896
> > > 3324 default_idle 69.2500
> > > 20097 ide_output_data 104.6719
> >
> > Hey, what is this?
> >
> > Comment of the function is:
> > "This is used for most PIO data transfers *to* the IDE interface"
> > (see /drivers/ide/ide.c:426)
> > Has it reverted to PIO mode?
>
> This is because there are not a proper and correct state diagram data
> handler set for ATAPI, period. Initially the driver evolved out of PIO
> calls to the PACKET_COMMAND opcode for the ATA command set. Since there
> has been zero updates/attempts to create a proper ATAPI/ASPI by anyone,
> you can expect PIO transactions.
I have now tried the writer on an old Pentium motherboard with Intel
430HX chipset and PIIX3. The performance problems didn't happen there,
so I would guess this is more a problem with how Linux handles the VIA
686b southbridge.
But what can I do to help fix this problem?
On Sun, Apr 14, 2002 at 03:39:35PM +0300, Anssi Saari wrote:
> (...)
>
> I have now tried the writer on an old Pentium motherboard with Intel
> 430HX chipset and PIIX3. The performance problems didn't happen there,
> so I would guess this is more a problem with how Linux handles the VIA
> 686b southbridge.
>
> But what can I do to help fix this problem?
We are now in 2.4.20-preBLAH time and appears that VIA 686b
southbridge still has the same problem (and appears to be that dont
surface with anothers controllers)
Ive just burned a image (.cue/.bin) with cdrdao and my load went
nuts, up to 5. Same motherboard chipset, same general conditions.
KT133a, VIA 686b southbridge, in that case with a LG combo drive
(HL-DT-ST RW/DVD GCC-4120B), hard-disk as /dev/hda (with ReiserFS),
combo drive as /dev/hdc.
What is strange is that problem dont appears with ISO images
(cdrecord-burned). There is any already-know solution for that
problem with VIA686b IDE?
Some info about the box in question:
cat /proc/version
Linux version 2.4.18-8cl ([email protected]) (gcc version 2.95.4 20010319 (prerelease)) #1 Mon Aug 12 20:27:14 BRT 2002
processor: AMD Duron 750MHz
lsmod | awk '{ print $1 }' | xargs
Module ide-scsi ide-cd cdrom scsi_mod agpgart NVdriver printer via686a i2c-proc
i2c-isa i2c-viapro i2c-core ppp_synctty ppp_async ppp_generic slhc ne2k-pci
8390 nls_iso8859-1 nls_cp437 vfat fat via82cxxx_audio uart401 ac97_codec sound
soundcore uhci usbcore reiserfs
(yeah, a 'tainted' kernel, 'sue me'(tm). I can repeat without
NVdriver loaded if anybody wants that)
cat /proc/ide/via
----------VIA BusMastering IDE Configuration----------------
Driver Version: 3.34
South Bridge: VIA vt82c686b
Revision: ISA 0x40 IDE 0x6
Highest DMA rate: UDMA100
BM-DMA base: 0xd000
PCI clock: 33.3MHz
Master Read Cycle IRDY: 0ws
Master Write Cycle IRDY: 0ws
BM IDE Status Register Read Retry: yes
Max DRDY Pulse Width: No limit
-----------------------Primary IDE-------Secondary IDE------
Read DMA FIFO flush: yes yes
End Sector FIFO flush: no no
Prefetch Buffer: no no
Post Write Buffer: no no
Enabled: yes yes
Simplex only: no no
Cable Type: 80w 40w
-------------------drive0----drive1----drive2----drive3-----
Transfer Mode: UDMA PIO DMA PIO
Address Setup: 30ns 90ns 30ns 120ns
Cmd Active: 330ns 330ns 90ns 90ns
Cmd Recovery: 270ns 270ns 30ns 30ns
Data Active: 90ns 300ns 90ns 330ns
Data Recovery: 30ns 300ns 30ns 270ns
Cycle Time: 30ns 600ns 120ns 600ns
Transfer Rate: 66.6MB/s 3.3MB/s 16.6MB/s 3.3MB/s
lspci -vvv
00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev 03)
Subsystem: Elitegroup Computer Systems: Unknown device 0987
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ >SERR- <PERR-
Latency: 8
Region 0: Memory at d8000000 (32-bit, prefetchable) [size=64M]
Capabilities: [a0] AGP version 2.0
Status: RQ=31 SBA+ 64bit- FW- Rate=x1,x2,x4
Command: RQ=0 SBA- AGP+ 64bit- FW- Rate=x4
Capabilities: [c0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:01.0 PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 AGP] (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ >SERR- <PERR+
Latency: 0
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
I/O behind bridge: 0000f000-00000fff
Memory behind bridge: dc000000-ddffffff
Prefetchable memory behind bridge: d0000000-d7ffffff
BridgeCtl: Parity- SERR- NoISA+ VGA+ MAbort- >Reset- FastB2B-
Capabilities: [80] Power Management version 2
Flags: PMEClk- DSI- D1+ D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 40)
Subsystem: VIA Technologies, Inc. VT82C686/A PCI to ISA Bridge
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Capabilities: [c0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:07.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 06) (prog-if 8a [Master SecP PriP])
Subsystem: VIA Technologies, Inc. Bus Master IDE
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 32
Region 4: I/O ports at d000 [size=16]
Capabilities: [c0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:07.2 USB Controller: VIA Technologies, Inc. USB (rev 16) (prog-if 00 [UHCI])
Subsystem: VIA Technologies, Inc. (Wrong ID): Unknown device 1234
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 32, cache line size 08
Interrupt: pin D routed to IRQ 3
Region 4: I/O ports at d400 [size=32]
Capabilities: [80] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:07.3 USB Controller: VIA Technologies, Inc. USB (rev 16) (prog-if 00 [UHCI])
Subsystem: VIA Technologies, Inc. (Wrong ID): Unknown device 1234
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 32, cache line size 08
Interrupt: pin D routed to IRQ 3
Region 4: I/O ports at d800 [size=32]
Capabilities: [80] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:07.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 40)
Subsystem: Elitegroup Computer Systems: Unknown device 0987
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Interrupt: pin ? routed to IRQ 9
Capabilities: [68] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:07.5 Multimedia audio controller: VIA Technologies, Inc. VT82C686 AC97 Audio Controller (rev 50)
Subsystem: Elitegroup Computer Systems: Unknown device 0987
Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Interrupt: pin C routed to IRQ 5
Region 0: I/O ports at dc00 [size=256]
Region 1: I/O ports at e000 [size=4]
Region 2: I/O ports at e400 [size=4]
Capabilities: [c0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:0a.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8029(AS)
Subsystem: Realtek Semiconductor Co., Ltd. RT8029(AS)
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Interrupt: pin A routed to IRQ 11
Region 0: I/O ports at ec00 [size=32]
01:00.0 VGA compatible controller: nVidia Corporation NV11 [GeForce2 MX DDR] (rev b2) (prog-if 00 [VGA])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 248 (1250ns min, 250ns max)
Interrupt: pin A routed to IRQ 10
Region 0: Memory at dc000000 (32-bit, non-prefetchable) [size=16M]
Region 1: Memory at d0000000 (32-bit, prefetchable) [size=128M]
Expansion ROM at <unassigned> [disabled] [size=64K]
Capabilities: [60] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [44] AGP version 2.0
Status: RQ=31 SBA- 64bit- FW+ Rate=x1,x2,x4
Command: RQ=31 SBA- AGP+ 64bit- FW- Rate=x4
Sergio Bruder
--
http://pontobr.org
pub 1024D/0C7D9F49 2000-05-26 Sergio Devojno Bruder <[email protected]>
Key fingerprint = 983F DBDF FB53 FE55 87DF 71CA 6B01 5E44 0C7D 9F49
sub 1024g/138DF93D 2000-05-26
On Fri, Aug 30, 2002 at 01:33:46AM -0300, Sergio Bruder wrote:
> (...)
> Some info about the box in question:
>
> cat /proc/version
> Linux version 2.4.18-8cl ([email protected]) (gcc version 2.95.4 20010319 (prerelease)) #1 Mon Aug 12 20:27:14 BRT 2002
>
> (...)
Sorry about replying to myself, but that 2.4.18-8cl is really a
2.4.19-rc2. From the rpm -q kernel-2.4.18-8cl --changelog:
* Qui Ago 08 2002 Eduardo Pereira Habkost <[email protected]>
+ kernel-2.4.18-8cl
- Updated to 2.4.19-rc2
- Removed patches (already on -rc2): sis_main
(...) and so on.
Sergio Bruder
--
http://pontobr.org
pub 1024D/0C7D9F49 2000-05-26 Sergio Devojno Bruder <[email protected]>
Key fingerprint = 983F DBDF FB53 FE55 87DF 71CA 6B01 5E44 0C7D 9F49
sub 1024g/138DF93D 2000-05-26
Hi Sergio!
* Sergio Bruder writes:
>On Sun, Apr 14, 2002 at 03:39:35PM +0300, Anssi Saari wrote:
>>(...)
>>
>>I have now tried the writer on an old Pentium motherboard with Intel
>>430HX chipset and PIIX3. The performance problems didn't happen there,
>>so I would guess this is more a problem with how Linux handles the VIA
>>686b southbridge.
>>
>>But what can I do to help fix this problem?
>We are now in 2.4.20-preBLAH time and appears that VIA 686b southbridge
>still has the same problem (and appears to be that dont surface with
>anothers controllers)
>Ive just burned a image (.cue/.bin) with cdrdao and my load went nuts,
>up to 5. Same motherboard chipset, same general conditions. KT133a,
>VIA 686b southbridge, in that case with a LG combo drive (HL-DT-ST
>RW/DVD GCC-4120B), hard-disk as /dev/hda (with ReiserFS), combo drive
>as /dev/hdc.
>What is strange is that problem dont appears with ISO images
>(cdrecord-burned). There is any already-know solution for that problem
>with VIA686b IDE?
The problem isn't really the southbridge, the problem is, that the
kernel doesn't seem to use (I still didn't get a definitive answer)
DMA when doing things with bigger blocksizes (grabbing audio CDs,
writing DAO CDs). That's why you don't have a problem burning 'normal'
TAO CDs. It seems that older chipsets just deal way better with PIO
modes (the PIIX3 doesn't have DMA, does it?).
For me it helped at least a bit to do the following:
- Disable interrupt sharing for IDE devices
- hdparm -d1 -c3 -u0 -X34/66 /dev/burner
With this settings I have 30% processor usage when writing at speed 20,
as opposed to at least 60% I had before.
regards
Markus
Sergio,
Okay the newest code attempt to tune the system before subdrivers are
loaded. This ensures that DMA is valid.
See latency comments below.
Andre Hedrick
LAD Storage Consulting Group
On Fri, 30 Aug 2002, Sergio Bruder wrote:
> lspci -vvv
> 00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev 03)
> Subsystem: Elitegroup Computer Systems: Unknown device 0987
> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
> Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ >SERR- <PERR-
> Latency: 8
^^^^^^^^^^^^^^^^^^
This tends to really roto-til things.
This needs to be "0" in may tests systems observed.
> Region 0: Memory at d8000000 (32-bit, prefetchable) [size=64M]
> Capabilities: [a0] AGP version 2.0
> Status: RQ=31 SBA+ 64bit- FW- Rate=x1,x2,x4
> Command: RQ=0 SBA- AGP+ 64bit- FW- Rate=x4
> Capabilities: [c0] Power Management version 2
> Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
> Status: D0 PME-Enable- DSel=0 DScale=0 PME-
>
> 00:01.0 PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 AGP] (prog-if 00 [Normal decode])
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
> Status: Cap+ 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ >SERR- <PERR+
> Latency: 0
^^^^^^^^^^^^^^^^^^
Bet you have nice video performance
> Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
> I/O behind bridge: 0000f000-00000fff
> Memory behind bridge: dc000000-ddffffff
> Prefetchable memory behind bridge: d0000000-d7ffffff
> BridgeCtl: Parity- SERR- NoISA+ VGA+ MAbort- >Reset- FastB2B-
> Capabilities: [80] Power Management version 2
> Flags: PMEClk- DSI- D1+ D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
> Status: D0 PME-Enable- DSel=0 DScale=0 PME-
>
> 00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 40)
> Subsystem: VIA Technologies, Inc. VT82C686/A PCI to ISA Bridge
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B-
> Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
> Latency: 0
> Capabilities: [c0] Power Management version 2
> Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
> Status: D0 PME-Enable- DSel=0 DScale=0 PME-
>
> 00:07.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 06) (prog-if 8a [Master SecP PriP])
> Subsystem: VIA Technologies, Inc. Bus Master IDE
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
> Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
> Latency: 32
> Region 4: I/O ports at d000 [size=16]
> Capabilities: [c0] Power Management version 2
> Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
> Status: D0 PME-Enable- DSel=0 DScale=0 PME-
On Fri, Aug 30, 2002 at 08:14:53AM +0200, Markus Plail wrote:
> >What is strange is that problem dont appears with ISO images
> >(cdrecord-burned). There is any already-know solution for that problem
> >with VIA686b IDE?
> The problem isn't really the southbridge, the problem is, that the
> kernel doesn't seem to use (I still didn't get a definitive answer)
> DMA when doing things with bigger blocksizes (grabbing audio CDs,
> writing DAO CDs).
I doubt that's the problem. As I've said before, I don't have this huge
slowdown problem if I plug the writer to a Promise pdc20265 or CMD649,
neither of which supports DMA for ATAPI devices. These controllers
however abort CD writing randomly so they are not a workaround... I
also don't have your DAO vs. TAO problem.
> It seems that older chipsets just deal way better with PIO
> modes (the PIIX3 doesn't have DMA, does it?).
Yes it does.
> For me it helped at least a bit to do the following:
> - Disable interrupt sharing for IDE devices
> - hdparm -d1 -c3 -u0 -X34/66 /dev/burner
I've tried disabling interrupt sharing for IDE that but it didn't
change anything. hdparm -c3 I haven't tried yet, I'll have to see if
it would help.
Hi Anssi!
* Anssi Saari writes:
>I doubt that's the problem. As I've said before, I don't have this huge
>slowdown problem if I plug the writer to a Promise pdc20265 or CMD649,
>neither of which supports DMA for ATAPI devices. These controllers
>however abort CD writing randomly so they are not a workaround...
Well, they may very well just deal better with PIO modes.
>I also don't have your DAO vs. TAO problem.
Hmm.. you wrote that cdrdao gives the problem, but cdrecord
doesn't. And in a previous mail you wrote that you also have the
problems when writing audio CDs. Are you sure that you really used DAO
when using cdrecord? All other symptoms look very much like the big
blocksize problem.
regards
Markus
On Thu, 29 Aug 2002, Andre Hedrick wrote:
> > lspci -vvv
> > 00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev 03)
> > Subsystem: Elitegroup Computer Systems: Unknown device 0987
> > Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
> > Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ >SERR- <PERR-
> > Latency: 8
> ^^^^^^^^^^^^^^^^^^
> This tends to really roto-til things.
>
> This needs to be "0" in may tests systems observed.
96 has worked well here, no weird crap happening to the burner in TAO or DAO
mode using cdrecord, and DAO recording of music CDs using cdrdao. lspci
-v -v attached, just in case it is useful for something.
The default was 32, which definately caused trouble with VIA's utter shitty
PCI implementation.
Kernel is still 2.4.18, though.
> > 00:01.0 PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 AGP] (prog-if 00 [Normal decode])
> > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
> > Status: Cap+ 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ >SERR- <PERR+
> > Latency: 0
> ^^^^^^^^^^^^^^^^^^
>
> Bet you have nice video performance
Screwed up, ain't it? The nvidia drivers do that too in my machine, and I
just gave up setpci'ng it back to a proper number.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
On Fri, Aug 30, 2002 at 09:27:04AM +0200, Markus Plail wrote:
> * Anssi Saari writes:
> >I doubt that's the problem. As I've said before, I don't have this huge
> >slowdown problem if I plug the writer to a Promise pdc20265 or CMD649,
> >neither of which supports DMA for ATAPI devices. These controllers
> >however abort CD writing randomly so they are not a workaround...
>
> Well, they may very well just deal better with PIO modes.
>
> >I also don't have your DAO vs. TAO problem.
>
> Hmm.. you wrote that cdrdao gives the problem, but cdrecord
> doesn't.
I doubt that. Even if I did, it's wrong.
> And in a previous mail you wrote that you also have the
> problems when writing audio CDs.
Yes. Audio CDs and VCDs, to be exact. Probably anything other than
vanilla ISO9660.
> Are you sure that you really used DAO when using cdrecord?
Yes, I do that quite a lot since DAO is a requirement for overburning,
on my writers anyway. For both data and audio CDs. I just tried it
again. It makes no noticeable difference, -dao or not. Data write good,
audio write bad.