Comment 11 for bug 11461

Guido,

We haven't had to add much to WARNINGS for quite some time. How about
putting a summary of this in?

Happy New Year!!

Cheers,
 Bruce

On Tue, 4 Jan 2005, Marc L. de Bruin wrote:

> 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.
>
>
>