Comment 10 for bug 11461

Message-ID: <email address hidden>
Date: Tue, 04 Jan 2005 21:00:01 +0100
From: "Marc L. de Bruin" <email address hidden>
To: Guido Guenther <email address hidden>, <email address hidden>
Subject: Re: Bug#287195: smartmontools takes the system down to a near halt

Guido Guenther wrote:

First of all, happy newyear!

Second, sorry for not getting back to you earlier. Due to Xmas and
Newyear I had much less time to research this problem than I would have
liked.

>>This is confusing to me. Although /etc/default/smartmontools clearly
>>states that the list mentioned in enable_smart *enables* devices, I
>>assumed that non-mentioned devices actually are *disabled*. This is not
>
> To *enable* S.M.A.R.T. on a device doesn't have to do anything with
> smartd. It merely means that the devices (built in) S.M.A.R.T.
> monitoring is activated at all. You can also enable this functionality
> in the BIOS, smartd does this on startup too but are cases where you
> don't want to run smartd but have S.M.A.R.T. enabled nevertheless (e.g.
> when you only want to use smartctl).
>
> The comment already reads:
> # list of devices you want to explicitly enable S.M.A.R.T. for
> # not needed if the device is monitored by smartd
> isn't that clear enough?

No. :-) Just copy-and-paste the above paragraph ("To *enable* S.M.A.R.T.
...) in /etc/default/smartmontools, as a comment. That will do.

Or: rename the enable_smart variable to enable_SMART. That would have
triggered me as well.

>>I'll do some more research on wednesday and will get back to you.
>
> Thanks for that. Just another question: when you say the system comes to
> a near halt: Is this permanent or does it go away after a couple of
> minutes?
> Cheers,
> -- Guido

It doesn't go away after a couple of minutes.

Regarding the problem: I fixed it.

The short story is that it had nothing to do with smartmontools.

The long story is that I tried a couple of things (5.33 from
experimental, replacing DEVICESCAN with just /dev/hda to keep things
simple, etc., etc., etc.) but none of these helped and did cause the
original effect (near halt). I even tried to switch from kernel 2.4.27
to kernel 2.6.8 but I couldn't even BOOT that kernel! All kind of
ATA-errors and strange kernel-messages regarding irq's that fired but no
service handler was registered to handle it.

That got me thinking about my configuration, which seems to work
perfectly with kernel 2.4.27 *without* smartmontools, but couldn't boot
2.6.8 and couldn't work *with* smartmontools.

I googled and read some pages, specifically
http://www.linuxmafia.com/faq/Hardware/sata.html, which mentions that
'in case of ATA-trouble, switch the motherboard BIOS back to "legacy ATA
mode"'.

I don't have SATA-disks but I *do* have SATA-ports on the motherboard! I
never touched the BIOS but after switching the ATA-support from
"Enhanced mode" to "Compatibility mode", I now *can* run kernel 2.6.8
without problems and *can* run smartmontools.

So this might be something to add to README.Debian. :-)

I you want me to test stuff, let me know.

I guess you can close 287195 now.

Thanks again,

Marc.