On 2/17/06, Ingo Molnar <[email protected]> wrote:
>
> * Bartlomiej Zolnierkiewicz <[email protected]> wrote:
>
> > Sorry but I have enough more high priority issues to take care of and
> > I'm not going to spend any more time on soft lockups even if they are
> > really problems in IDE subsystem. If this is not fixed before 2.6.16
> > I'm submitting patch to Linus making DETECT_SOFTLOCKUP depend on
> > "CONFIG_IDE=n"... at least users will be able to use their systems
> > instead of seeing lockups.
>
> i have lots of IDE based systems (they dont use PIO though) and i'm not
> seeing these. I'll oppose such a patch if it's to hide genuine issues -
> the 10 seconds tolerance is already generous i think. I'll of course fix
> any false positives which are the fault of the softlockup-watchdog, but
> from your mails it appears to me that the IDE warnings are indeed
> genuine.
>
> If the source of the delay is hard to fix you can temporarily work it
> around in the code by putting in the touch_softlockup_watchdog() lines -
> that will also document the places that cause long delays - which is a
> good thing.
>
> It is entirely feasible to put a touch_softlockup_watchdog() call into
> every PIO OP - even a single-byte PIO related IN/OUT instruction takes a
> couple of microseconds, so a touch_softlockup_watchdog() wont even show
> up on the radar.
OK, I'll just add touch_softlockup_watchdog() if needed but first lets
wait for results of your patch.
Note that I'll invest my time on this which could be invested into other
things and I don't see it as top-priority issue if you differ in your opinion
you should be the person fixing affected drivers.
The conclusion of the rant is: people making changes at higher layers
should start paying maintenance costs of their changes. Over few years
of maintaining IDE I learned quite a lot about block layer, VFS, VM, ACPI,
PM, IRQ routing, scheduling, sysfs etc (I'm not talking about interface
changes but about bugs/changes which are reported by end users
and driver maintainers are end-point). This is all good but distracts me
from my primary task and now it is turn for people hacking on generic
code to learn few driver specific things... :)
No wonder that nobody wants to hack drivers: less fame, more flames,
and actually besides knowing hardware you need to know a lot about
kernel in general to do your job right. I hope that Andrew is reading this.
End of whining.
> > DETECT_SOFTLOCKUP should be an aim in development not a method of
> > forcing driver maintainers to work on specific issues...
>
> well, 10+ seconds delays on a running system are not really acceptable,
> and can cause other problems. The softlockup-watchdog is optional and
> can be easily turned off in the .config.
It is "y" by default so anybody saying "y" to DEBUG_KERNEL will get it as
added bonus and moreover DEBUG_KERNEL is "y" in x86_64 defconfig.
Bartlomiej
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
