I get the following message when copying a 300MB directory under 2.4.2.
uhci:host system error, PCI problems?
uhci:host controller halted, very bad
This does not happen under 2.4.1 and it happens every time under 2.4.2.
The system still runs fine except for usb mouse.
All of the files in the directory are copied correctly.
It happens when dma is enabled by hdparm -d1 /dev/hda or when dma is
enabled automatically by the kernel.
I have an Abit kt7 mb with the kt133 chipset,Athlon 900 , 128MB mem,
quantum fireball 20G disk, gcc 2-95-2 , glibc 2-2-1.
There are no problems with dma disabled.
I was not sure if the VIA82CXXX option should be set with the via kt133
chipset , but setting it results in hundreds of
hda: dma_intr:status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr:error=0x84 { DriveStatusError BadCRC }
mesages along with the uhci: errors mentioned above.
Again , the directory was copied correctly.
Is there anyway to get 2.4.2 to use dma and not turn off my usb mouse ?
thanks jpd
> I get the following message when copying a 300MB directory under 2.4.2.
>
> uhci:host system error, PCI problems?
> uhci:host controller halted, very bad
The USB code should recover from that , if it doesnt report it to the USB
folks.
> I was not sure if the VIA82CXXX option should be set with the via kt133
> chipset , but setting it results in hundreds of
> hda: dma_intr:status=0x51 { DriveReady SeekComplete Error }
> hda: dma_intr:error=0x84 { DriveStatusError BadCRC }
> mesages along with the uhci: errors mentioned above.
> Again , the directory was copied correctly.
That indicates cable problems. The CRC will avoid bad transfers as it will
do retries
Alan
Alan Cox wrote:
>> I was not sure if the VIA82CXXX option should be set with the
>> via kt133 chipset , but setting it results in hundreds of
>> hda: dma_intr:status=0x51 { DriveReady SeekComplete Error }
>> hda: dma_intr:error=0x84 { DriveStatusError BadCRC }
>> mesages along with the uhci: errors mentioned above. Again ,
>> the directory was copied correctly.
> That indicates cable problems. The CRC will avoid bad transfers
> as it will do retries
Oh my god. Are you sure it's a cable problem? I'm using the
cable shipped by ASUS with my K7V and have the same problem:
devfs: v0.102 (20000622) Richard Gooch ([email protected])
devfs: boot_options: 0x2
hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
ide0: reset: success
Again, if it's really a cable problem, then ASUS is selling
cables that don't work with UDMA66 (but they sell it as
UDMA66).
I urge ASUS to explain this problem. If you do a search for
BadCRC at any lkml archive, you should notice most complaints
are from... VIA (and most seem to have an ASUS motherboard).
--
0@pervalidus.{net, {dyndns.}org} Tel: 55-21-717-2399 (Niter?i-RJ BR)
In article <20010225060326.K127@pervalidus> you wrote:
> hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
> hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
I think I saw that with broken Drives, too.
Greetings
Bernd
> hda: dma_intr: status=3D0x51 { DriveReady SeekComplete Error }
> hda: dma_intr: error=3D0x84 { DriveStatusError BadCRC }
> ide0: reset: success
>
> Again, if it's really a cable problem, then ASUS is selling
> cables that don't work with UDMA66 (but they sell it as
> UDMA66).
To get ATA66 working well you need the right cables, you also need a machine
that is to spec on interference and the like. You cant just point at the cables
althoigh they are first guess.
I also am using the cable supplied with the mobo (Abit kt7) so I do not
think it is ASUS specific. More likey it is releated to the
VIA chipset and/or driver.
If I compile kernel with "Generic PCI bus-master DMA support"
and run "hdparm -d1 /dev/hda" I get 700% performance increase
on hdparm -t benchmark and I do not get any dma BadCRC errors.
It is only when I also compile in the VIA82CXXX option that I get the
"hda: dma_intr:status=0x51 { DriveReady SeekComplete Error }"
"hda: dma_intr:error=0x84 { DriveStatusError BadCRC }"
mesages (1000's of them).
Whether I get the messages or not, if I have dma enabled with 2.4.2
my usb mouse stops working .
jpd
>
> > That indicates cable problems. The CRC will avoid bad transfers
> > as it will do retries
>
> Oh my god. Are you sure it's a cable problem? I'm using the
> cable shipped by ASUS with my K7V and have the same problem:
>
> devfs: v0.102 (20000622) Richard Gooch ([email protected])
> devfs: boot_options: 0x2
> hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
> hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
> hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
> hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
> hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
> hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
> hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
> hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
> ide0: reset: success
>
> Again, if it's really a cable problem, then ASUS is selling
> cables that don't work with UDMA66 (but they sell it as
> UDMA66).
>
> I urge ASUS to explain this problem. If you do a search for
> BadCRC at any lkml archive, you should notice most complaints
> are from... VIA (and most seem to have an ASUS motherboard).
>
> --
> 0@pervalidus.{net, {dyndns.}org} Tel: 55-21-717-2399 (Niter?i-RJ BR)
...
> It happens when dma is enabled by hdparm -d1 /dev/hda or when dma is
> enabled automatically by the kernel.
>
> I have an Abit kt7 mb with the kt133 chipset,Athlon 900 , 128MB mem,
> quantum fireball 20G disk, gcc 2-95-2 , glibc 2-2-1.
>
> There are no problems with dma disabled.
>
> I was not sure if the VIA82CXXX option should be set with the via kt133
> chipset , but setting it results in hundreds of
> hda: dma_intr:status=0x51 { DriveReady SeekComplete Error }
> hda: dma_intr:error=0x84 { DriveStatusError BadCRC }
> mesages along with the uhci: errors mentioned above.
...
Try passing kernel params (eg- idebus=33 ide0=ata66 ide1=ata6) rather
than relying on hdparm to set up disks.
I'm on 2.2.19pre8 + ide.2.2.18.1221 but same board and cables, zero
errors. Also run a check with nothing but graphics, kbd, disks. KA7
seems to be particularly edgy with some addon cards (ES1370 & Promise
controller in my case) and <300W power (compared to P3B-F).
rgds,
tim
# hdparm -iv /dev/hdc
/dev/hdc:
multcount = 0 (off)
I/O support = 0 (default 16-bit)
unmaskirq = 0 (off)
using_dma = 1 (on)
keepsettings = 0 (off)
nowerr = 0 (off)
readonly = 0 (off)
readahead = 8 (on)
geometry = 2501/255/63, sectors = 40188960, start = 0
Model=IBM-DTLA-307020, FwRev=TX3OA50C, SerialNo=YH0YHF45553
Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=40
BuffType=DualPortCache, BuffSize=1916kB, MaxMultSect=16, MultSect=off
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=40188960
IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 *udma4 udma5
# hdparm -tT /dev/hdc
/dev/hdc:
Timing buffer-cache reads: 128 MB in 0.94 seconds =136.17 MB/sec
Timing buffered disk reads: 64 MB in 1.87 seconds = 34.22 MB/sec
# lspci
00:00.0 Host bridge: VIA Technologies, Inc.: Unknown device 0391 (rev
02)
00:01.0 PCI bridge: VIA Technologies, Inc.: Unknown device 8391
00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super] (rev
22)
00:07.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev
10)
00:07.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI]
(rev 30)
00:08.0 FireWire (IEEE 1394): Texas Instruments TSB12LV23 OHCI Compliant
IEEE-1394 Controller
00:09.0 Multimedia audio controller: Ensoniq ES1370 [AudioPCI]
00:0b.0 Ethernet controller: Lite-On Communications Inc LNE100TX (rev
20)
01:00.0 VGA compatible controller: nVidia Corporation Riva TNT2 Model 64
(rev 11)
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
CONFIG_BLK_DEV_IDEDMA=y
CONFIG_IDEDMA_AUTO=y
CONFIG_IDEDMA_PCI_EXPERIMENTAL=y
CONFIG_BLK_DEV_VIA82CXXX=y
Linux version 2.2.19pre8+IDE (root@abit) (gcc version egcs-2.91.66
19990314/Linux (egcs-1.1.2 release)) #8 Thu Feb 22 18:12:29 PST 2001
USER-provided physical RAM map:
USER: 0009f000 @ 00000000 (usable)
USER: 1ff00000 @ 00100000 (usable)
Detected 800062 kHz processor.
ide_setup: idebus=33
ide_setup: ide0=ata66
ide_setup: ide1=ata66
Console: colour VGA+ 80x25
Calibrating delay loop... 1595.80 BogoMIPS
Memory: 517196k/524288k available (1120k kernel code, 412k reserved,
5512k data, 48k init)
Dentry hash table entries: 65536 (order 7, 512k)
Buffer cache hash table entries: 524288 (order 9, 2048k)
Page cache hash table entries: 131072 (order 7, 512k)
CPU: L1 I Cache: 64K L1 D Cache: 64K
CPU: L2 Cache: 512K
CPU: AMD Athlon(tm) Processor stepping 02
Checking 386/387 coupling... OK, FPU using exception 16 error reporting.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
mtrr: v1.35a (19990819) Richard Gooch ([email protected])
PCI: PCI BIOS revision 2.10 entry at 0xfb4d0
...
Uniform Multi-Platform E-IDE driver Revision: 6.30
ide: Assuming 33MHz system bus speed for PIO modes
VP_IDE: IDE controller on PCI bus 00 dev 39
VP_IDE: chipset revision 16
VP_IDE: not 100% native mode: will probe irqs later
VT 8371
Chipset Core ATA-66
VP_IDE: ATA-66/100 forced bit set (WARNING)!!
Split FIFO Configuration: 8 Primary buffers, threshold = 1/2
8 Second. buffers, threshold = 1/2
ide0: BM-DMA at 0xd000-0xd007, BIOS settings: hda:DMA, hdb:DMA
ide0: VIA Bus-Master (U)DMA Timing Config Success
VP_IDE: ATA-66/100 forced bit set (WARNING)!!
ide1: BM-DMA at 0xd008-0xd00f, BIOS settings: hdc:DMA, hdd:DMA
ide1: VIA Bus-Master (U)DMA Timing Config Success
hda: IBM-DTLA-307020, ATA DISK drive
hdb: YAMAHA CRW4416E, ATAPI CDROM drive
hdc: IBM-DTLA-307020, ATA DISK drive
hdd: HP COLORADO 20GB, ATAPI TAPE drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: IBM-DTLA-307020, 19623MB w/1916kB Cache, CHS=2501/255/63, UDMA(66)
hdc: IBM-DTLA-307020, 19623MB w/1916kB Cache, CHS=39870/16/63, UDMA(66)
...
--
jerry ([email protected])> I also am using the cable supplied with the mobo (Abit kt7) so I
do not
> think it is ASUS specific. More likey it is releated to the
> VIA chipset and/or driver.
>
> If I compile kernel with "Generic PCI bus-master DMA support"
> and run "hdparm -d1 /dev/hda" I get 700% performance increase
> on hdparm -t benchmark and I do not get any dma BadCRC errors.
>
> It is only when I also compile in the VIA82CXXX option that I get the
> "hda: dma_intr:status=0x51 { DriveReady SeekComplete Error }"
> "hda: dma_intr:error=0x84 { DriveStatusError BadCRC }"
> mesages (1000's of them).
>
> Whether I get the messages or not, if I have dma enabled with 2.4.2
> my usb mouse stops working .
If you use the VIA IDE driver, then you _must_ turn on
the "Automatically enable DMA for PCI-IDE" kernel configuration
option. It is said in the help text for the VIA-IDE option.
--
David Balazic
--------------
"Be excellent to each other." - Bill & Ted
- - - - - - - - - - - - - - - - - - - - - -
At 01:56 PM 2/25/2001 +0000, Alan Cox wrote:
> > hda: dma_intr: status=3D0x51 { DriveReady SeekComplete Error }
> > hda: dma_intr: error=3D0x84 { DriveStatusError BadCRC }
> > ide0: reset: success
> >
> > Again, if it's really a cable problem, then ASUS is selling
> > cables that don't work with UDMA66 (but they sell it as
> > UDMA66).
>
>To get ATA66 working well you need the right cables, you also need a machine
>that is to spec on interference and the like. You cant just point at the
>cables
>althoigh they are first guess.
>
I have a similar setup and had the same problems. Dump your cables and get
ATA/100 Certified cables and you should not have this problem. Also keep
the cable length in mind. Anybody out there know if there's a max cable
length for the ATA/100 spec??
>-
>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/
- - -
Jasmeet Sidhu
Unix Systems Administrator
ArrayComm, Inc.
[email protected]
http://www.arraycomm.com
I did use that option. The system works but it generates a large number of
the BadCRC messages when I do heavy io. Using then generic dma bus master
support gives me fast io without the messages.
jpd
> If you use the VIA IDE driver, then you _must_ turn on
> the "Automatically enable DMA for PCI-IDE" kernel configuration
> option. It is said in the help text for the VIA-IDE option.
>
> the cable length in mind. Anybody out there know if there's a max cable
> length for the ATA/100 spec??
18", like *all* ide/ata cables.
On Mon, Feb 26, 2001 at 03:23:18PM -0500, Mark Hahn wrote:
> > the cable length in mind. Anybody out there know if there's a max cable
> > length for the ATA/100 spec??
>
> 18", like *all* ide/ata cables.
Actually the ATA/66 and ATA/100 cables are specified to be exactly 18",
not longer, not shorter.
--
Vojtech Pavlik
SuSE Labs
On Tue, 27 Feb 2001, Vojtech Pavlik wrote:
> On Mon, Feb 26, 2001 at 03:23:18PM -0500, Mark Hahn wrote:
> > > the cable length in mind. Anybody out there know if there's a max cable
> > > length for the ATA/100 spec??
> >
> > 18", like *all* ide/ata cables.
>
> Actually the ATA/66 and ATA/100 cables are specified to be exactly 18",
> not longer, not shorter.
Not exactly the case, but I do not want to cause more headaches by showing
the method of variation that will work in many cases. Thus 45cm or 18"
will do..
Cheers,
Andre Hedrick
Linux ATA Development
ASL Kernel Development
-----------------------------------------------------------------------------
ASL, Inc. Toll free: 1-877-ASL-3535
1757 Houret Court Fax: 1-408-941-2071
Milpitas, CA 95035 Web: http://www.aslab.com