From: "Petr Vandrovec" <VANDROVE@vc.cvut.cz>
Organization: CC CTU Prague
To: Marcin Dalecki <dalecki@evision.ag>
Date: Thu, 1 Aug 2002 19:07:21 +0200
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: IDE from current bk tree, UDMA and two channels...
CC: linux-kernel@vger.kernel.org, mingo@elte.hu
Message-ID: <C94E6D2807@vcnet.vc.cvut.cz>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1720
Lines: 35

On 31 Jul 02 at 22:01, Marcin Dalecki wrote:
> 
> Well OK this was my next idea, but apparently you already did the
> experient on your own. Thanks for the result. I'm still scratching my
> head and I have already observed this before myself.
> It's always funny to see what happens when one stops a driver
> from deliberately disabling IRQs for eons of jiffies :-).

I finally managed to compile older kernels, and I found that
2.5.27 (and 2.4.19-rc1 and 2.5.26) works fine (modulo endless loop 
in ide_do_request... but it takes at least 5 minutes to trigger it), 
while 2.5.28 dies in one second with UDMA status 0x25 (irq requested, 
transfer in progress) and IDE status 0x58 (drq asserted).

Because of only change in IDE system between 2.5.27 and 2.5.28 is
renaming __save_flags => local_save_flags, fixing get_request for
ioctl commands (so 2.5.28 should be correct while 2.5.27 is not),
and moving some ioctls around, it looks like that problem is triggered
by something else.

I currently suspect IRQ handling changes, but maybe someone has
better idea? Also, I cannot reproduce problem with Seagate UDMA66
drive switched to UDMA33 mode, so it looks like that problem is 
timming/firmware (Toshiba MK6409MAV) dependent.

And I did all these tests with UP kernel, just to eliminate cli/sti 
changes.
                                            Petr Vandrovec
                                            vandrove@vc.cvut.cz
                                            
-
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/