On Thu, 4 May 2000, Jens Axboe wrote:
> On Wed, May 03 2000, Jeff Garzik wrote:
> > What sort of wait is this?
>
> I have no idea, I didn't write that code.
Lead time to protect us from devices that can sometime issue their
interrupt before the status is set.
> > Looking at the code for ide_spin_wait_hwgroup, a couple things come to
> > mind.
> >
> > * IIRC this was one of the places which people hacked in 2.2.x to fix an
> > IDE<->SMP problem. There may be issues here which are getting missed.
> > Namely,
>
> Exactly, which is why I wanted Andre to comment on that.
>
> > * you notice how the old code drops the spinlock, then calls
> > __save_flags (not save_flags) and __sti (not sti). your patch
> > completely eliminates that per-CPU synchronization (or whatever that
> > code does). I'm not sure that's correct.
>
> Yes, the IDE stuff is very odd this way.
One has to setup the interrupt to the device and that takes a little time
(task file commands). Bad move........we just found/corrected the
crossover spinlocks WRT to interrupt services.
Not until ATA dsc-overlap and/or command-queuing is in place would I even
attempt to detatch from the global(io_request_lock).
> > * spin waiting like this in general seems wrong anyway. can't we do
> > better? can you sneak a schedule() call in there? anyway, IIRC Alan
> > commented [about the 2.2.x IDE code] that it needed to be cleaned up,
> > that the IDE<->SMP fix in place was really a band-aid.
>
> I agree, busy looping is always bad. Andre, do we really have to busy wait
> here?
Tell me when we want to NUKE legacy hardware........SUPPORT
This would include ISA and possible ISA-PNP-IDE.........
> > Maybe Andre or Alan can comment about the "right fix", if this code even
> > needs to be changed.... IMHO you can probably use spin_lock_irq here,
> > but you probably shouldn't remove the __save_flags/__sti stuff.
>
> I hope so, sneaking in the __save_flags/__sti again is three liner
> anyway.
Or is this a point to split code form IDE to ATA-IDE.
Since ATA-1 and ATA-2 are retired, but SFF people still design hardware
based upon retired and dropped standards group........OOPS!!
Jens you should know this all to well........all the goofy workarounds
that you have to deploy by devices specific........
Cheers,
Andre Hedrick
The Linux ATA/IDE guy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun May 07 2000 - 21:00:13 EST