public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "'Roger Luethi'" <rl@hellgate.ch>
To: "Richard B. Johnson" <root@chaos.analogic.com>
Cc: Shing Chuang <ShingChuang@via.com.tw>,
	Urban Widmark <urban@teststation.com>,
	"Ivan G." <ivangurdiev@linuxfreemail.com>,
	Jeff Garzik <jgarzik@mandrakesoft.com>,
	linux-kernel@vger.kernel.org, AJ Jiang <AJJiang@via.com.tw>
Subject: Re: [PATCH] #2 VIA Rhine stalls: TxAbort handling
Date: Thu, 16 May 2002 22:31:59 +0200	[thread overview]
Message-ID: <20020516203159.GA10868@k3.hellgate.ch> (raw)
In-Reply-To: <20020516180354.GA9151@k3.hellgate.ch> <Pine.LNX.3.95.1020516141423.993A-100000@chaos.analogic.com>

> > The driver "waits a little" in the interrupt handler? How long can that
> > take, worst case?
> 
> Forever..........^;)

We should assume that this is indeed the case, but it often helps to know
what the expected values and their distribution are.

It's a weird situation anyway: both the buffer descriptor and the interrupt
status have been updated by the chip to reflect the abort, but by the time
we handle the error it may still be busy coming to a halt.

What tickles my curiosity is that my previous patch didn't fix the stalling
for Ivan G. on his VT86C100A. Maybe the chip just wasn't ready to be
restarted.

> Even if the chip never breaks, you end up with reports like..
> "Strange, I make frisbees when buring CDs while M$ machines do
> backups over the network..."

Not if the chip is guaranteed to have its thing done after one or two
iterations. We make some inb and outb calls in the ISR either way.

That was hypothetically speaking of course, I'm not suggesting we rely on
such a "guarantee".

Roger

  reply	other threads:[~2002-05-16 20:32 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-05-16 10:03 [PATCH] #2 VIA Rhine stalls: TxAbort handling Shing Chuang
2002-05-16 18:03 ` 'Roger Luethi'
2002-05-16 18:25   ` Richard B. Johnson
2002-05-16 20:31     ` 'Roger Luethi' [this message]
2002-05-16 16:39       ` Ivan G.
2002-05-17  2:54         ` [PATCH] #3 VIA Rhine stalls: Wait for the chip? 'Roger Luethi'
2002-05-16 21:05       ` [PATCH] #2 VIA Rhine stalls: TxAbort handling Richard B. Johnson
2002-05-17  0:16         ` 'Roger Luethi'
2002-05-17 12:51           ` Richard B. Johnson
2002-05-17 16:25             ` 'Roger Luethi'
     [not found] <369B0912E1F5D511ACA5003048222B75A3C06E@EXCHANGE2>
     [not found] ` <20020518040143.GA9318@k3.hellgate.ch>
2002-05-17 23:13   ` Ivan G.
2002-05-18 19:11     ` 'Roger Luethi'
  -- strict thread matches above, loose matches on Subject: below --
2002-05-17 18:46 Manfred Spraul
2002-05-17 19:56 ` 'Roger Luethi'
2002-05-18 10:08 ` David Woodhouse
2002-05-16  3:13 Roger Luethi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20020516203159.GA10868@k3.hellgate.ch \
    --to=rl@hellgate.ch \
    --cc=AJJiang@via.com.tw \
    --cc=ShingChuang@via.com.tw \
    --cc=ivangurdiev@linuxfreemail.com \
    --cc=jgarzik@mandrakesoft.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=root@chaos.analogic.com \
    --cc=urban@teststation.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox