lkml.org 
[lkml]   [2003]   [Sep]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [BUG?] SIS IDE DMA errors
Date
On Saturday 27 September 2003 02:33, Vojtech Pavlik wrote:
> On Fri, Sep 26, 2003 at 07:46:03PM +0200, M?ns Rullg?rd wrote:
> > Vojtech Pavlik <vojtech@suse.cz> writes:
> >
> > >> > Actually, it's me who wrote the 961 and 963 support. It works fine for
> > >> > most people. Did you check you cabling?
> > >>
> > >> I'm dealing with a laptop, but I suppose I could wiggle the cables a
> > >> bit. I still doubt it's a cable problem, since reading works
> > >> flawlessly.
> > >
> > > Hmm, that's indeed interesting and it'd point to a driver problem -
> >
> > See, I told you :)
> >
> > > when reading, the drive is dictating the timing, but when writing, it's
> > > the controllers turn.
> > >
> > > So if the controller timing is not correctly programmed, reads function,
> > > but writes don't.
> >
> > Furthermore, short writes work just fine. The errors usually start
> > happening after about 100 MB at full speed. When copying from NFS
> > over a 100 MB/s network it usually goes a little longer, sometimes
> > even up to 500 MB. All this could indicate that there is some error
> > in the timing, and that it takes some time for it build up enough to
> > trigger the bad things. Or am I wrong?
>
> Well, yes. There's nothing to build up. There are no two timers to
> synchronize - basically the controller sends the data at a certain speed
> and the drive must be able to understand the data at that speed. So, if
> you configure the controller to UDMA133 and the drive can only do
> UDMA100, it'll fail sooner or later. It doesn't necessarily fail
> immediately, since the drive has some margin above its engineered speed
> that it'll be able to receive.
>
> > Why can't the drive give notice when it's ready to accept more data?
>
> It does, it does. The problem would only occur if the signalling rate
> was too high for the driver to receive it. If the drive's buffers are
> full, it'll signal the controller to delay sending, but first the data
> must reach the buffer.
>
> > That would seem like the simple solution, instead of trying to
> > synchronize the timers.
>
> There fortunately are no timers to be synchronized. However, you can't
> do the handshake at every single byte, that'd slow down the transfers
> considerablt.
>
> >
> > > Can you send me the output of 'lspci -vvxxx' of the IDE device?
> > > I'll take a look to see if it looks correct.
> >
> > Here you go:
>
> Thanks.
>
> > 00:02.5 IDE interface: Silicon Integrated Systems [SiS] 5513 [IDE] (rev d0) (prog-if 80 [Master])
> > Subsystem: Asustek Computer, Inc.: Unknown device 1688
> > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
> > Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
> > Latency: 128
> > Region 4: I/O ports at b800 [size=16]
> > 00: 39 10 13 55 07 00 00 00 d0 80 01 01 00 80 80 00
> > 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > 20: 01 b8 00 00 00 00 00 00 00 00 00 00 43 10 88 16
> > 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > 40: 31 81 00 00 31 85 00 00 08 01 e6 51 00 02 00 02
>
> Ok, this means:
>
> 31 - hda: 90ns data active time, 30 ns data recovery time (PIO4)
> 41 - hda: UDMA enabled, UDMA mode 5 (UDMA100)
> 00 - hdb: 240ns/360ns (PIO0) - no drive present
> 00 - hdb: UDMA disabled
> 31 - hdc: 90ns/30ns PIO4
> 85 - hdc: UDMA enabled, UDMA mode 2 (UDMA33)
> 00 - hdd: 240ns/360ns (PIO0) - no drive present
> 00 - hdd: UDMA disabled
>
> So the config is correct if you have /dev/hda your harddrive, that's
> capable of UDMA100 and /dev/hdc a CDROM and capable of UDMA33. Is that
> right?
>
> 08 - 80-wire cables (needed for UDMA44 and higher) NOT installed.
> FIFO threshold set to 3/4 for read and to 1/4 for write.
>
> 01 - IDE controller in compatibility mode. Native and test modes
> disabled. (normal)
>
> e6 - PCI burst enable, EDB R-R pipeline enable, Fast postwrite enable,
> device ID masqueraded as sis5513 (although real is 5517)
> channels 0 and 1 enabled in normal mode
>
> 51 - Postwrite enabled on hda and hdc, prefetch on hda only
>
> 00 02 - 512 bytes prefetch size for hda
> 00 02 - 512 bytes prefetch size for hdc
>
> All this is OK, possibly except for the 80-wire cable not being present,
> but if this is a notebook, there might be a completely different cable
> type than what's standard, and the detection might not work there.
>
> > 50: 01 00 01 06 00 00 00 00 00 00 00 00 00 00 00 00
> > 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>
> > >> It appears to me that during heavy IO load, some DMA interrupts get
> > >> lost, for some reason.
> > >
> > > Well, I've got this feeling that not just IDE interrupts get lost under
> > > heavy IO load with recent kernels ...
> >
> > Like mouse and keyboard...
>
> Like everything. But only for mouse, keyboard, timer and ide it HURTS.
>
> --
> Vojtech Pavlik
> SuSE Labs, SuSE CR
>
>

Was running 2.4.22.

Now running 2.6.0-test5. Fresh boot.

00:0f.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/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 11
Region 0: I/O ports at e000 [size=256]
Region 1: Memory at eb102000 (32-bit, non-prefetchable) [size=256]
Expansion ROM at <unassigned> [disabled] [size=64K]
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: ec 10 39 81 07 00 90 02 10 00 00 02 00 20 00 00
10: 01 e0 00 00 00 20 10 eb 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 ec 10 39 81
30: 00 00 00 00 50 00 00 00 00 00 00 00 0b 01 20 40
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

I am surprised at your analysis of the pci bus data. By what you
stated my drive(r) should be doing PIO ;)

50: 01 00 c2 f7 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

/dev/hda:
Timing buffer-cache reads: 128 MB in 0.36 seconds =352.67 MB/sec
Timing buffered disk reads: 64 MB in 1.20 seconds = 53.25 MB/sec
[root@mhfl4 03:10:20 mhf]# v ht

/dev/hda:
Timing buffer-cache reads: 128 MB in 0.37 seconds =346.00 MB/sec
Timing buffered disk reads: 64 MB in 1.20 seconds = 53.21 MB/sec

It does 53MB/s and by earlier drive info as mailed drive reports set to udma5.

Regards
Michael









-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:48    [from the cache]
©2003-2011 Jasper Spaans