Re: PROMBLEM: CD burning at 16x uses excessive CPU, although DMA is enabled

Re: PROMBLEM: CD burning at 16x uses excessive CPU, although DMA is enabled

[Roger Larsson]

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

Re: PROMBLEM: CD burning at 16x uses excessive CPU, although DMA is enabled

[Andre Hedrick]

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

Re: PROMBLEM: CD burning at 16x uses excessive CPU, although DMA is enabled

[Matthias Andree]

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

Re: PROMBLEM: CD burning at 16x uses excessive CPU, although DMA is enabled

[Anssi Saari]

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?

Re: PROBLEM: CD burning at 12x uses excessive CPU, although DMA is enabled

[Sergio Bruder]

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 (root@mapi2.distro.conectiva) (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 <sergio@bruder.net>
     Key fingerprint = 983F DBDF FB53 FE55 87DF  71CA 6B01 5E44 0C7D 9F49
sub  1024g/138DF93D 2000-05-26

Re: PROBLEM: CD burning at 12x uses excessive CPU, although DMA is enabled

[Sergio Bruder]

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 (root@mapi2.distro.conectiva) (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 <ehabkost@conectiva.com.br>

+ 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 <sergio@bruder.net>
     Key fingerprint = 983F DBDF FB53 FE55 87DF  71CA 6B01 5E44 0C7D 9F49
sub  1024g/138DF93D 2000-05-26

Re: PROBLEM: CD burning at 12x uses excessive CPU, although DMA is enabled

[Markus Plail]

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

Re: PROBLEM: CD burning at 12x uses excessive CPU, although DMA is enabled

[Andre Hedrick]

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-

Re: PROBLEM: CD burning at 12x uses excessive CPU, although DMA is enabled

[Anssi Saari]

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.

Re: PROBLEM: CD burning at 12x uses excessive CPU, although DMA is enabled

[Markus Plail]

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

Re: PROBLEM: CD burning at 12x uses excessive CPU, although DMA is enabled

[Henrique de Moraes Holschuh]

[-- Attachment #1: Type: text/plain, Size: 1605 bytes --]

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

[-- Attachment #2: foo --]
[-- Type: text/plain, Size: 7176 bytes --]

00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev 02)
	Subsystem: Asustek Computer, Inc. A7V Mainboard
	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 e6000000 (32-bit, prefetchable) [size=32M]
	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
	Memory behind bridge: d6000000-d7dfffff
	Prefetchable memory behind bridge: d7f00000-e5ffffff
	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:04.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 22)
	Subsystem: Asustek Computer, Inc. A7V Mainboard
	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

00:04.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 10) (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: 96
	Region 4: I/O ports at d800 [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:04.2 USB Controller: VIA Technologies, Inc. USB (rev 10) (prog-if 00 [UHCI])
	Subsystem: VIA Technologies, Inc. (Wrong ID) USB Controller
	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 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:04.3 USB Controller: VIA Technologies, Inc. USB (rev 10) (prog-if 00 [UHCI])
	Subsystem: VIA Technologies, Inc. (Wrong ID) USB Controller
	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 d000 [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:04.4 Bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 30)
	Subsystem: Asustek Computer, Inc. A7V Mainboard
	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:09.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C (rev 10)
	Subsystem: Realtek Semiconductor Co., Ltd. RT8139
	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 (8000ns min, 16000ns max)
	Interrupt: pin A routed to IRQ 5
	Region 0: I/O ports at a400 [size=256]
	Region 1: Memory at d5800000 (32-bit, non-prefetchable) [size=256]
	Capabilities: [50] Power Management version 2
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0-,D1+,D2+,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:0a.0 Multimedia audio controller: Cirrus Logic CS 4614/22/24 [CrystalClear SoundFusion Audio Accelerator] (rev 01)
	Subsystem: KYE Systems Corporation: Unknown device 7003
	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 (1000ns min, 6000ns max)
	Interrupt: pin A routed to IRQ 5
	Region 0: Memory at d5000000 (32-bit, non-prefetchable) [size=4K]
	Region 1: Memory at d4800000 (32-bit, non-prefetchable) [size=1M]
	Capabilities: [40] 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:11.0 Unknown mass storage controller: Promise Technology, Inc. 20265 (rev 02)
	Subsystem: Promise Technology, Inc. Ultra100
	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: 96
	Interrupt: pin A routed to IRQ 10
	Region 0: I/O ports at a000 [size=8]
	Region 1: I/O ports at 9800 [size=4]
	Region 2: I/O ports at 9400 [size=8]
	Region 3: I/O ports at 9000 [size=4]
	Region 4: I/O ports at 8800 [size=64]
	Region 5: Memory at d4000000 (32-bit, non-prefetchable) [size=128K]
	Expansion ROM at <unassigned> [disabled] [size=128K]
	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 b2) (prog-if 00 [VGA])
	Subsystem: Asustek Computer, Inc. V7100 Pro with TV output
	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 11
	Region 0: Memory at d6000000 (32-bit, non-prefetchable) [size=16M]
	Region 1: Memory at d8000000 (32-bit, prefetchable) [size=128M]
	Expansion ROM at d7ff0000 [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=0 SBA- AGP- 64bit- FW- Rate=<none>

Re: PROBLEM: CD burning at 12x uses excessive CPU, although DMA is enabled

[Anssi Saari]

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.

Re: PROBLEM: CD burning at 12x uses excessive CPU, although DMA is enabled

[Markus Plail]

Hi Anssi!

* Anssi Saari writes:
>On Fri, Aug 30, 2002 at 09:27:04AM +0200, Markus Plail wrote:
>>* Anssi Saari writes:
>>>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.

Yes, sorry, it was Sergio.

>>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.

It's not only the content that matters, but the way the content is
written to CD. If you write your stuff in TAO or SAO (which can be DAO,
DAO alone isn't valid) it's no problem. Examples are:
- cdrecord -dao ...
- cdrdao --driver generic-mmc

If you write CDs in RAW modes, then there's the problem with the high
loads. Examples:
- cdrecord -raw96r/p (2448 bytes/sector)
- cdrecord -raw16    (2368 bytes/sector)
- cdrdao --driver generic-mmc-raw (2368 bytes/sector)

So for Sergio: Try using the generic-mmc without raw driver in cdrdao.

And audio CDs or (S)VCDs are written in mode2 (2352 bytes/sector) and
also cause the high loads, this time independent from the writing mode.
AFAIK this behaviour should be the same on any Linux system.

regards
Markus

Re: PROBLEM: CD burning at 12x uses excessive CPU, although DMA is enabled

[Sergio Bruder]

On Fri, Aug 30, 2002 at 06:58:09PM +0200, Markus Plail wrote:
> Hi Anssi!
> 
> * Anssi Saari writes:
> >On Fri, Aug 30, 2002 at 09:27:04AM +0200, Markus Plail wrote:
> >>* Anssi Saari writes:
> >>>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.
> 
> Yes, sorry, it was Sergio.
> 
> (...)
>
> If you write CDs in RAW modes, then there's the problem with the high
> loads. Examples:
> - cdrecord -raw96r/p (2448 bytes/sector)
> - cdrecord -raw16    (2368 bytes/sector)
> - cdrdao --driver generic-mmc-raw (2368 bytes/sector)
> 
> So for Sergio: Try using the generic-mmc without raw driver in cdrdao.
>

I was using exactly generic-mmc, never tried the raw version.

I only said that with ISO images the problem dont show up, as Anssi.

> 
> And audio CDs or (S)VCDs are written in mode2 (2352 bytes/sector) and
> also cause the high loads, this time independent from the writing mode.
> AFAIK this behaviour should be the same on any Linux system.


Sergio Bruder
--
http://pontobr.org
pub  1024D/0C7D9F49 2000-05-26 Sergio Devojno Bruder <sergio@bruder.net>
     Key fingerprint = 983F DBDF FB53 FE55 87DF  71CA 6B01 5E44 0C7D 9F49
sub  1024g/138DF93D 2000-05-26

Re: PROBLEM: CD burning at 12x uses excessive CPU, although DMA is enabled

[Anssi Saari]

On Fri, Aug 30, 2002 at 06:58:09PM +0200, Markus Plail wrote:
 
> If you write CDs in RAW modes, then there's the problem with the high
> loads. Examples:
> - cdrecord -raw96r/p (2448 bytes/sector)
> - cdrecord -raw16    (2368 bytes/sector)
> - cdrdao --driver generic-mmc-raw (2368 bytes/sector)
 
Yes, this is confirmed. I tried writing a data track with cdrecord
-raw96r mode and got the slowdown. So yes, it seems that "big" blocks,
2352 bytes and greater cause this problem while "small" blocks of 2048
bytes don't.