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