> There's also a bit of temp diagnostic/debuggy stuff in this patch.
>
> - Detect the occurence of CPU0 doing a del_timer() during
> CPU1's execution of the handler. If this does occur, direct
> people to
>
> http://www.uow.edu.au/~andrewm/linux/del_timer.html
>
> Reminder: this scenario is the whole reason for this
> patch (and this long email). We need to gather these statistics
> so we can decide whether or not to patch 2.2. If I don't get
> any emails this whole thing was a waste of time. (But I've
> already seen it happen three times, and I haven't even tried...)
>
Hi, i just got your "del_timer(c77ebf40) during handler execution"
message.
I got the message seconds prior to a "hdk: timeout waiting for DMA"
message.
Ive been having DMA problems for a long time with my HPT366
controller(s) which is why i tried your patch. hdk is my onboard hpt366
controller, i have a bp6 dual celeron with a promise ultra66 card to
give 6 ide channels. (more details if interested)
The program i was running that caused the DMA timeout was tiobench.pl,
which is a disk benchmark script that uses tiotest.
Im using 2.3.99-pre10-pre3 + your timer-race-6 patch, i did "tweak" the
kernel a bit to force my HPT366 to not use UDMA66, by changing #define
HPT366_ALLOW_ATA66_3 (and 4) to 0.
Prior to this tweak the kernel locked up after testing with bonnie.
So, this means that a race condition was found. Is it likely that this
race condition was casued by the DMA timeout, or could the DMA timeout
be caused by the race ?
Thanks
Glenn
-
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 : Wed May 31 2000 - 21:00:14 EST