* Re: PROMBLEM: CD burning at 16x uses excessive CPU, although DMA is enabled @ 2002-04-09 20:06 Roger Larsson 2002-04-09 20:27 ` Andre Hedrick 0 siblings, 1 reply; 15+ messages in thread From: Roger Larsson @ 2002-04-09 20:06 UTC (permalink / raw) To: Anssi Saari; +Cc: linux-kernel, Mark Mielke 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: PROMBLEM: CD burning at 16x uses excessive CPU, although DMA is enabled 2002-04-09 20:06 PROMBLEM: CD burning at 16x uses excessive CPU, although DMA is enabled Roger Larsson @ 2002-04-09 20:27 ` Andre Hedrick 2002-04-10 9:10 ` Matthias Andree 2002-04-14 12:39 ` Anssi Saari 0 siblings, 2 replies; 15+ messages in thread From: Andre Hedrick @ 2002-04-09 20:27 UTC (permalink / raw) To: Roger Larsson; +Cc: Anssi Saari, linux-kernel, Mark Mielke 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: PROMBLEM: CD burning at 16x uses excessive CPU, although DMA is enabled 2002-04-09 20:27 ` Andre Hedrick @ 2002-04-10 9:10 ` Matthias Andree 2002-04-14 12:39 ` Anssi Saari 1 sibling, 0 replies; 15+ messages in thread From: Matthias Andree @ 2002-04-10 9:10 UTC (permalink / raw) To: linux-kernel 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: PROMBLEM: CD burning at 16x uses excessive CPU, although DMA is enabled 2002-04-09 20:27 ` Andre Hedrick 2002-04-10 9:10 ` Matthias Andree @ 2002-04-14 12:39 ` Anssi Saari 2002-08-30 4:33 ` PROBLEM: CD burning at 12x " Sergio Bruder 1 sibling, 1 reply; 15+ messages in thread From: Anssi Saari @ 2002-04-14 12:39 UTC (permalink / raw) To: Andre Hedrick; +Cc: vojtech, linux-kernel 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? ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: PROBLEM: CD burning at 12x uses excessive CPU, although DMA is enabled 2002-04-14 12:39 ` Anssi Saari @ 2002-08-30 4:33 ` Sergio Bruder 2002-08-30 4:48 ` Sergio Bruder ` (2 more replies) 0 siblings, 3 replies; 15+ messages in thread From: Sergio Bruder @ 2002-08-30 4:33 UTC (permalink / raw) To: Anssi Saari; +Cc: Andre Hedrick, vojtech, linux-kernel 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: PROBLEM: CD burning at 12x uses excessive CPU, although DMA is enabled 2002-08-30 4:33 ` PROBLEM: CD burning at 12x " Sergio Bruder @ 2002-08-30 4:48 ` Sergio Bruder 2002-08-30 6:14 ` Markus Plail 2002-08-30 6:41 ` Andre Hedrick 2 siblings, 0 replies; 15+ messages in thread From: Sergio Bruder @ 2002-08-30 4:48 UTC (permalink / raw) To: Anssi Saari, Andre Hedrick, vojtech, linux-kernel 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: PROBLEM: CD burning at 12x uses excessive CPU, although DMA is enabled 2002-08-30 4:33 ` PROBLEM: CD burning at 12x " Sergio Bruder 2002-08-30 4:48 ` Sergio Bruder @ 2002-08-30 6:14 ` Markus Plail 2002-08-30 6:51 ` Anssi Saari 2002-08-30 6:41 ` Andre Hedrick 2 siblings, 1 reply; 15+ messages in thread From: Markus Plail @ 2002-08-30 6:14 UTC (permalink / raw) To: Sergio Bruder; +Cc: Anssi Saari, Andre Hedrick, vojtech, linux-kernel 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: PROBLEM: CD burning at 12x uses excessive CPU, although DMA is enabled 2002-08-30 6:14 ` Markus Plail @ 2002-08-30 6:51 ` Anssi Saari 2002-08-30 7:27 ` Markus Plail 0 siblings, 1 reply; 15+ messages in thread From: Anssi Saari @ 2002-08-30 6:51 UTC (permalink / raw) To: Markus Plail; +Cc: Sergio Bruder, Andre Hedrick, vojtech, linux-kernel 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. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: PROBLEM: CD burning at 12x uses excessive CPU, although DMA is enabled 2002-08-30 6:51 ` Anssi Saari @ 2002-08-30 7:27 ` Markus Plail 2002-08-30 15:42 ` Anssi Saari 0 siblings, 1 reply; 15+ messages in thread From: Markus Plail @ 2002-08-30 7:27 UTC (permalink / raw) To: Anssi Saari; +Cc: Sergio Bruder, Andre Hedrick, vojtech, linux-kernel 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: PROBLEM: CD burning at 12x uses excessive CPU, although DMA is enabled 2002-08-30 7:27 ` Markus Plail @ 2002-08-30 15:42 ` Anssi Saari 2002-08-30 16:58 ` Markus Plail 0 siblings, 1 reply; 15+ messages in thread From: Anssi Saari @ 2002-08-30 15:42 UTC (permalink / raw) To: Markus Plail; +Cc: Sergio Bruder, Andre Hedrick, vojtech, linux-kernel 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. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: PROBLEM: CD burning at 12x uses excessive CPU, although DMA is enabled 2002-08-30 15:42 ` Anssi Saari @ 2002-08-30 16:58 ` Markus Plail 2002-08-30 21:22 ` Sergio Bruder 2002-08-31 16:29 ` Anssi Saari 0 siblings, 2 replies; 15+ messages in thread From: Markus Plail @ 2002-08-30 16:58 UTC (permalink / raw) To: Anssi Saari; +Cc: Sergio Bruder, Andre Hedrick, vojtech, linux-kernel 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: PROBLEM: CD burning at 12x uses excessive CPU, although DMA is enabled 2002-08-30 16:58 ` Markus Plail @ 2002-08-30 21:22 ` Sergio Bruder 2002-08-31 16:29 ` Anssi Saari 1 sibling, 0 replies; 15+ messages in thread From: Sergio Bruder @ 2002-08-30 21:22 UTC (permalink / raw) To: Markus Plail; +Cc: Anssi Saari, Andre Hedrick, vojtech, linux-kernel 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: PROBLEM: CD burning at 12x uses excessive CPU, although DMA is enabled 2002-08-30 16:58 ` Markus Plail 2002-08-30 21:22 ` Sergio Bruder @ 2002-08-31 16:29 ` Anssi Saari 1 sibling, 0 replies; 15+ messages in thread From: Anssi Saari @ 2002-08-31 16:29 UTC (permalink / raw) To: Markus Plail; +Cc: Sergio Bruder, Andre Hedrick, vojtech, linux-kernel 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. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: PROBLEM: CD burning at 12x uses excessive CPU, although DMA is enabled 2002-08-30 4:33 ` PROBLEM: CD burning at 12x " Sergio Bruder 2002-08-30 4:48 ` Sergio Bruder 2002-08-30 6:14 ` Markus Plail @ 2002-08-30 6:41 ` Andre Hedrick 2002-08-30 12:59 ` Henrique de Moraes Holschuh 2 siblings, 1 reply; 15+ messages in thread From: Andre Hedrick @ 2002-08-30 6:41 UTC (permalink / raw) To: Sergio Bruder; +Cc: Anssi Saari, vojtech, linux-kernel 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- ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: PROBLEM: CD burning at 12x uses excessive CPU, although DMA is enabled 2002-08-30 6:41 ` Andre Hedrick @ 2002-08-30 12:59 ` Henrique de Moraes Holschuh 0 siblings, 0 replies; 15+ messages in thread From: Henrique de Moraes Holschuh @ 2002-08-30 12:59 UTC (permalink / raw) To: linux-kernel [-- 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> ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2002-08-31 16:23 UTC | newest] Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2002-04-09 20:06 PROMBLEM: CD burning at 16x uses excessive CPU, although DMA is enabled Roger Larsson 2002-04-09 20:27 ` Andre Hedrick 2002-04-10 9:10 ` Matthias Andree 2002-04-14 12:39 ` Anssi Saari 2002-08-30 4:33 ` PROBLEM: CD burning at 12x " Sergio Bruder 2002-08-30 4:48 ` Sergio Bruder 2002-08-30 6:14 ` Markus Plail 2002-08-30 6:51 ` Anssi Saari 2002-08-30 7:27 ` Markus Plail 2002-08-30 15:42 ` Anssi Saari 2002-08-30 16:58 ` Markus Plail 2002-08-30 21:22 ` Sergio Bruder 2002-08-31 16:29 ` Anssi Saari 2002-08-30 6:41 ` Andre Hedrick 2002-08-30 12:59 ` Henrique de Moraes Holschuh
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).