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    [W:0.063 / U:0.108 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site