smartmontools takes the system down to a near halt

[Debian Bug Importer]

Automatically imported from Debian bug report #287195 http://bugs.debian.org/287195

[Debian Bug Importer (debzilla)]

Automatically imported from Debian bug report #287195 http://bugs.debian.org/287195

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Sat, 25 Dec 2004 17:58:29 +0100
From: "Marc L. de Bruin" <email address hidden>
To: Debian Bug Tracking System <email address hidden>
Subject: smartmontools takes the system down to a near halt

Package: smartmontools
Version: 5.32-2
Severity: critical
Justification: breaks the whole system

(this is reproducable)

I'm sorry to mention this, but running smartmontools on my system brings
it down to a near halt. With 'near halt' I mean that the system becomes
very unresponsive, but doesn't really crash.

I configured it in such a way that /etc/default/smartmontools contains
start_smartd=yes and enable_smart="/dev/hda"; this system actually has
hd[abcde]. Running "/etc/init.d/smartmontools start" makes it
unresponsive immediately.

/dev/hda is a IBM-DHEA-36480, connected to a ICH5 onboard
IDE-controller on a Asus P4C800E-Dlx mainboard. Without smartmontools,
the system runs fine. I'm using Debian's kernel-image-2.4.27-1-686-smp.

/var/log/syslog shows that smartd actually scans more that just
"/dev/hda" (also hd[bcde]), but doesn't show any errors.

-- Package-specific info:
Ouput of /usr/share/bug/smartmontools:
# CONFIG_IDE_TASK_IOCTL is not set

-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.4.27-1-686-smp
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)

Versions of packages smartmontools depends on:
ii libc6 2.3.2.ds1-18 GNU C Library: Shared libraries an

-- no debconf information

[Guido Günther (agx)]

# Automatically generated email from bts, devscripts version 2.8.5
severity 287195 important

[Guido Günther (agx)]

Hi Marc,
On Sat, Dec 25, 2004 at 05:58:29PM +0100, Marc L. de Bruin wrote:
> I configured it in such a way that /etc/default/smartmontools contains
> start_smartd=yes and enable_smart="/dev/hda"; this system actually has
No need for the later. start_smartd is sufficient.

> hd[abcde]. Running "/etc/init.d/smartmontools start" makes it
> unresponsive immediately.
>
> /dev/hda is a IBM-DHEA-36480, connected to a ICH5 onboard
> IDE-controller on a Asus P4C800E-Dlx mainboard. Without smartmontools,
> the system runs fine. I'm using Debian's kernel-image-2.4.27-1-686-smp.
>
> /var/log/syslog shows that smartd actually scans more that just
> "/dev/hda" (also hd[bcde]), but doesn't show any errors.
Sure it does, if you don't configure /etc/smartd.conf, it will do a
devicescan, this can easily cause problems. Please enable one drive at a
time and check which one exactly causee the problem. Also, please read
at least README.Debian and WARNINGS.gz.
Additionally please attach 'grep smartd /var/log/syslog' to this mail, when you
have DEVICESCAN enabled in smartd.conf.
Cheers,
 -- Guido

Oh, and could you also please check if the problem persists with
smartmontools 5.33 from experimental?

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Sun, 26 Dec 2004 12:29:43 +0100
From: Guido Guenther <email address hidden>
To: "Marc L. de Bruin" <email address hidden>, <email address hidden>
Subject: Re: Bug#287195: smartmontools takes the system down to a near halt

Hi Marc,
On Sat, Dec 25, 2004 at 05:58:29PM +0100, Marc L. de Bruin wrote:
> I configured it in such a way that /etc/default/smartmontools contains
> start_smartd=yes and enable_smart="/dev/hda"; this system actually has
No need for the later. start_smartd is sufficient.

> hd[abcde]. Running "/etc/init.d/smartmontools start" makes it
> unresponsive immediately.
>
> /dev/hda is a IBM-DHEA-36480, connected to a ICH5 onboard
> IDE-controller on a Asus P4C800E-Dlx mainboard. Without smartmontools,
> the system runs fine. I'm using Debian's kernel-image-2.4.27-1-686-smp.
>
> /var/log/syslog shows that smartd actually scans more that just
> "/dev/hda" (also hd[bcde]), but doesn't show any errors.
Sure it does, if you don't configure /etc/smartd.conf, it will do a
devicescan, this can easily cause problems. Please enable one drive at a
time and check which one exactly causee the problem. Also, please read
at least README.Debian and WARNINGS.gz.
Additionally please attach 'grep smartd /var/log/syslog' to this mail, when you
have DEVICESCAN enabled in smartd.conf.
Cheers,
 -- Guido

Oh, and could you also please check if the problem persists with
smartmontools 5.33 from experimental?

[Debian Bug Importer (debzilla)]

Message-Id: <email address hidden>
Date: Sun, 26 Dec 2004 12:30:11 +0100
From: Guido Guenther <email address hidden>
To: <email address hidden>
Subject: severity of 287195 is important

# Automatically generated email from bts, devscripts version 2.8.5
severity 287195 important

[meaculpa (marc-debruin)]

Guido Guenther wrote:

  >>I configured it in such a way that /etc/default/smartmontools contains
>>start_smartd=yes and enable_smart="/dev/hda"; this system actually has
>
> No need for the later. start_smartd is sufficient.

[...]

>
>>/var/log/syslog shows that smartd actually scans more that just
>>"/dev/hda" (also hd[bcde]), but doesn't show any errors.
>
> Sure it does, if you don't configure /etc/smartd.conf, it will do a
> devicescan, this can easily cause problems. Please enable one drive at a

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
the case, I guess, if DEVICESCAN is still on. You might want to add just
an extra comment regarding this in /etc/default/smartmontools, since it
doesn't have a man-page.

> time and check which one exactly causee the problem. Also, please read
> at least README.Debian and WARNINGS.gz.

Most of these warnings regard Promise controllers; I'm just using the
on-board ICH5. Furthermore, all problems seem to relate to kernel-2.4.18
up and including 2.4.21. Those are really old, like over 2 years. ;-)
I'm guessing those problems have already been fixed (??).

> Additionally please attach 'grep smartd /var/log/syslog' to this mail, when you
> have DEVICESCAN enabled in smartd.conf.
>
> Oh, and could you also please check if the problem persists with
> smartmontools 5.33 from experimental?

I'll do some more research on wednesday and will get back to you.

Thanks for your quick reply!

Marc.

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Mon, 27 Dec 2004 10:25:49 +0100
From: "Marc L. de Bruin" <email address hidden>
To: Guido Guenther <email address hidden>
CC: <email address hidden>
Subject: Re: Bug#287195: smartmontools takes the system down to a near halt

Guido Guenther wrote:

  >>I configured it in such a way that /etc/default/smartmontools contains
>>start_smartd=yes and enable_smart="/dev/hda"; this system actually has
>
> No need for the later. start_smartd is sufficient.

[...]

>
>>/var/log/syslog shows that smartd actually scans more that just
>>"/dev/hda" (also hd[bcde]), but doesn't show any errors.
>
> Sure it does, if you don't configure /etc/smartd.conf, it will do a
> devicescan, this can easily cause problems. Please enable one drive at a

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
the case, I guess, if DEVICESCAN is still on. You might want to add just
an extra comment regarding this in /etc/default/smartmontools, since it
doesn't have a man-page.

> time and check which one exactly causee the problem. Also, please read
> at least README.Debian and WARNINGS.gz.

Most of these warnings regard Promise controllers; I'm just using the
on-board ICH5. Furthermore, all problems seem to relate to kernel-2.4.18
up and including 2.4.21. Those are really old, like over 2 years. ;-)
I'm guessing those problems have already been fixed (??).

> Additionally please attach 'grep smartd /var/log/syslog' to this mail, when you
> have DEVICESCAN enabled in smartd.conf.
>
> Oh, and could you also please check if the problem persists with
> smartmontools 5.33 from experimental?

I'll do some more research on wednesday and will get back to you.

Thanks for your quick reply!

Marc.

[meaculpa (marc-debruin)]

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.

[Debian Bug Importer (debzilla)]

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.

[Bruce Allen (ballen)]

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

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Tue, 4 Jan 2005 14:30:58 -0600 (CST)
From: Bruce Allen <email address hidden>
To: "Marc L. de Bruin" <email address hidden>, <email address hidden>
cc: Guido Guenther <email address hidden>
Subject: Re: Bug#287195: smartmontools takes the system down to a near halt

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

[Matt Zimmerman (mdz)]

Withdrawn by submitter

[meaculpa (marc-debruin)]

Bruce Allen wrote:

>Guido,
>
>We haven't had to add much to WARNINGS for quite some time. How about
>putting a summary of this in?
>
>
I would have to agree immediately, since it would have saved me a lot of
work. I *will* save other ppl a lot of work.

Marc.

[meaculpa (marc-debruin)]

Bruce Allen wrote:

>Guido,
>
>We haven't had to add much to WARNINGS for quite some time. How about
>putting a summary of this in?
>
>
Please do so, so that other people won't have to research it anymore.

Marc.

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Wed, 05 Jan 2005 14:04:56 +0100
From: "Marc L. de Bruin" <email address hidden>
To: Bruce Allen <email address hidden>
CC: <email address hidden>, Guido Guenther <email address hidden>
Subject: Re: Bug#287195: smartmontools takes the system down to a near halt

Bruce Allen wrote:

>Guido,
>
>We haven't had to add much to WARNINGS for quite some time. How about
>putting a summary of this in?
>
>
I would have to agree immediately, since it would have saved me a lot of
work. I *will* save other ppl a lot of work.

Marc.

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Wed, 05 Jan 2005 14:08:19 +0100
From: "Marc L. de Bruin" <email address hidden>
To: Bruce Allen <email address hidden>
CC: <email address hidden>, Guido Guenther <email address hidden>
Subject: Re: Bug#287195: smartmontools takes the system down to a near halt

Bruce Allen wrote:

>Guido,
>
>We haven't had to add much to WARNINGS for quite some time. How about
>putting a summary of this in?
>
>
Please do so, so that other people won't have to research it anymore.

Marc.

[Guido Günther (agx)]

On Tue, Jan 04, 2005 at 09:00:01PM +0100, Marc L. de Bruin wrote:
> Guido Guenther wrote:
>
> First of all, happy newyear!
Thanks, for you too!

> 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'm still puzzled. You can run 2.4.27 _without_ smartmontools but not
with smartmontools if you enable "enhanced mode", right? Even if you
_only_ select /dev/hda in /etc/smartd.conf?
Could you check if not starting smartd but running "smartctl -a /dev/hda"
shows the same symptoms?
Bruce, do you think that asking a device for smart data can cause
problems on a completely different bus? Sound very weird.

>
> 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. :-)
Definitely. Lets try to sort some things out first.
Thanks a lot for your help Marc!
 -- Guido

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Thu, 6 Jan 2005 17:06:48 +0100
From: Guido Guenther <email address hidden>
To: "Marc L. de Bruin" <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#287195: smartmontools takes the system down to a near halt

On Tue, Jan 04, 2005 at 09:00:01PM +0100, Marc L. de Bruin wrote:
> Guido Guenther wrote:
>
> First of all, happy newyear!
Thanks, for you too!

> 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'm still puzzled. You can run 2.4.27 _without_ smartmontools but not
with smartmontools if you enable "enhanced mode", right? Even if you
_only_ select /dev/hda in /etc/smartd.conf?
Could you check if not starting smartd but running "smartctl -a /dev/hda"
shows the same symptoms?
Bruce, do you think that asking a device for smart data can cause
problems on a completely different bus? Sound very weird.

>
> 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. :-)
Definitely. Lets try to sort some things out first.
Thanks a lot for your help Marc!
 -- Guido

[meaculpa (marc-debruin)]

Guido Guenther wrote:

>>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'm still puzzled. You can run 2.4.27 _without_ smartmontools but not
> with smartmontools if you enable "enhanced mode", right? Even if you
> _only_ select /dev/hda in /etc/smartd.conf?

Euh, no. I can run 2.4.27, even in "enhanced mode". That was the default
mode which the BIOS was in when I installed the motherboard. Never
looked at it, never changed it.

In "enhanced mode", I can't run smartmontools, not even in /dev/hda
which isn't that strange considering the fact that /dev/hda _is_
connected to the onboard chipset.

Also, in "enhanced mode", I can't even start 2.6.8.

Switching back from "enhanced mode" to "compatibility mode" fixes
everything.

Or is that the same as you stated above, I'm puzzled, in fact it is, I
guess.

> Could you check if not starting smartd but running "smartctl -a /dev/hda"
> shows the same symptoms?

I will tomorrow.

> Bruce, do you think that asking a device for smart data can cause
> problems on a completely different bus? Sound very weird.

It is not on a completely different bus. Note: the message you sent me
didn't contain a CC: for Bruce...

  > Definitely. Lets try to sort some things out first.
> Thanks a lot for your help Marc!

That's okay. I'll get back to you.

Marc.

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Fri, 07 Jan 2005 21:59:14 +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:

>>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'm still puzzled. You can run 2.4.27 _without_ smartmontools but not
> with smartmontools if you enable "enhanced mode", right? Even if you
> _only_ select /dev/hda in /etc/smartd.conf?

Euh, no. I can run 2.4.27, even in "enhanced mode". That was the default
mode which the BIOS was in when I installed the motherboard. Never
looked at it, never changed it.

In "enhanced mode", I can't run smartmontools, not even in /dev/hda
which isn't that strange considering the fact that /dev/hda _is_
connected to the onboard chipset.

Also, in "enhanced mode", I can't even start 2.6.8.

Switching back from "enhanced mode" to "compatibility mode" fixes
everything.

Or is that the same as you stated above, I'm puzzled, in fact it is, I
guess.

> Could you check if not starting smartd but running "smartctl -a /dev/hda"
> shows the same symptoms?

I will tomorrow.

> Bruce, do you think that asking a device for smart data can cause
> problems on a completely different bus? Sound very weird.

It is not on a completely different bus. Note: the message you sent me
didn't contain a CC: for Bruce...

  > Definitely. Lets try to sort some things out first.
> Thanks a lot for your help Marc!

That's okay. I'll get back to you.

Marc.

[meaculpa (marc-debruin)]

Guido Guenther wrote:

>Could you check if not starting smartd but running "smartctl -a /dev/hda"
>shows the same symptoms?
>
>
I just did.

What I did is this. I rebooted the system, put the IDE-channel back in
"enhanced" mode and booted 2.4.27 in single-user mode, so that smartd
didn't start.

Then, on a bash-prompt, I ran smartctl -a /dev/hda.

Immediately, the system becomes non-responsive, but doesn't crash. It
does not react on Ctrl-C. Even worse, I have signs that the kernel
doesn't even get those keys; I'm sharing 1 keyboard/mouse with another
PC via a KVM-switch and when I switch to that other machine, THAT
machine receives the "C"!

As mentioned, it doesn't crash. In fact, it *is* producing the same
output as in "compatible" mode, but it takes a smashing 45 minutes (!!!)
to accomplish that! When smartctl finishes and I get my prompt back,
nothing changed; still the system is very unresponsive but at least the
characters are accepted again. Typing the words "shutdown -r now" takes
another 2-3 minutes to accept, and the actual reboot another 10 minutes.
Then I changed the channel back to "compatible" and now I'm typing this
message on a perfectly working machine running 2.6.8 with smartd.

Strange, heh?

>>So this might be something to add to README.Debian. :-)
>>
>>
>Definitely. Lets try to sort some things out first.
>Thanks a lot for your help Marc!
> -- Guido
>
>
Is there anything else you want me to try? Just let me know...

Marc.

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Sun, 09 Jan 2005 18:38:33 +0100
From: "Marc L. de Bruin" <email address hidden>
To: Guido Guenther <email address hidden>
CC: <email address hidden>
Subject: Re: Bug#287195: smartmontools takes the system down to a near halt

Guido Guenther wrote:

>Could you check if not starting smartd but running "smartctl -a /dev/hda"
>shows the same symptoms?
>
>
I just did.

What I did is this. I rebooted the system, put the IDE-channel back in
"enhanced" mode and booted 2.4.27 in single-user mode, so that smartd
didn't start.

Then, on a bash-prompt, I ran smartctl -a /dev/hda.

Immediately, the system becomes non-responsive, but doesn't crash. It
does not react on Ctrl-C. Even worse, I have signs that the kernel
doesn't even get those keys; I'm sharing 1 keyboard/mouse with another
PC via a KVM-switch and when I switch to that other machine, THAT
machine receives the "C"!

As mentioned, it doesn't crash. In fact, it *is* producing the same
output as in "compatible" mode, but it takes a smashing 45 minutes (!!!)
to accomplish that! When smartctl finishes and I get my prompt back,
nothing changed; still the system is very unresponsive but at least the
characters are accepted again. Typing the words "shutdown -r now" takes
another 2-3 minutes to accept, and the actual reboot another 10 minutes.
Then I changed the channel back to "compatible" and now I'm typing this
message on a perfectly working machine running 2.6.8 with smartd.

Strange, heh?

>>So this might be something to add to README.Debian. :-)
>>
>>
>Definitely. Lets try to sort some things out first.
>Thanks a lot for your help Marc!
> -- Guido
>
>
Is there anything else you want me to try? Just let me know...

Marc.

[Guido Günther (agx)]

Source: smartmontools
Source-Version: 5.32-3

We believe that the bug you reported is fixed in the latest version of
smartmontools, which is due to be installed in the Debian FTP archive:

smartmontools_5.32-3.diff.gz
  to pool/main/s/smartmontools/smartmontools_5.32-3.diff.gz
smartmontools_5.32-3.dsc
  to pool/main/s/smartmontools/smartmontools_5.32-3.dsc
smartmontools_5.32-3_powerpc.deb
  to pool/main/s/smartmontools/smartmontools_5.32-3_powerpc.deb

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to <email address hidden>,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Guido Guenther <email address hidden> (supplier of updated smartmontools package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing <email address hidden>)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Sat, 5 Feb 2005 17:07:15 +0100
Source: smartmontools
Binary: smartmontools
Architecture: source powerpc
Version: 5.32-3
Distribution: unstable
Urgency: medium
Maintainer: Guido Guenther <email address hidden>
Changed-By: Guido Guenther <email address hidden>
Description:
 smartmontools - control and monitor storage systems using S.M.A.R.T.
Closes: 254953 287195 292489
Changes:
 smartmontools (5.32-3) unstable; urgency=medium
 .
   * urgency medium since this fixes an important bug targeted for Sarge
   * grab patch from CVS by Doug Gilbert that fixes wrong health
     reporting of SCSI disks (Closes: #292489)
   * document problems with Asus P4C800E-Dlx (Closes: #287195)
   * document fixed ntp time drift with kernels >= 2.4.26 (Closes: #254953)
Files:
 ee2ee9ac7729a0c45d93ec1b51449682 577 utils optional smartmontools_5.32-3.dsc
 f7c0c85c9ca7fadf5ec2c1ba3ccb6677 32118 utils optional smartmontools_5.32-3.diff.gz
 dfcec03bd22705735c0ffbce34de134c 228740 utils optional smartmontools_5.32-3_powerpc.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQFCBPL+n88szT8+ZCYRAsEwAJ9FjsU/WqWFNUGOx+HOCs0kJrVjgQCbB+WN
k1XkzfdU/tDajVuqcTNxnKc=
=DVmT
-----END PGP SIGNATURE-----

[Debian Bug Importer (debzilla)]

Message-Id: <email address hidden>
Date: Sat, 05 Feb 2005 11:47:04 -0500
From: Guido Guenther <email address hidden>
To: <email address hidden>
Subject: Bug#287195: fixed in smartmontools 5.32-3

Source: smartmontools
Source-Version: 5.32-3

We believe that the bug you reported is fixed in the latest version of
smartmontools, which is due to be installed in the Debian FTP archive:

smartmontools_5.32-3.diff.gz
  to pool/main/s/smartmontools/smartmontools_5.32-3.diff.gz
smartmontools_5.32-3.dsc
  to pool/main/s/smartmontools/smartmontools_5.32-3.dsc
smartmontools_5.32-3_powerpc.deb
  to pool/main/s/smartmontools/smartmontools_5.32-3_powerpc.deb

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to <email address hidden>,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Guido Guenther <email address hidden> (supplier of updated smartmontools package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing <email address hidden>)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Sat, 5 Feb 2005 17:07:15 +0100
Source: smartmontools
Binary: smartmontools
Architecture: source powerpc
Version: 5.32-3
Distribution: unstable
Urgency: medium
Maintainer: Guido Guenther <email address hidden>
Changed-By: Guido Guenther <email address hidden>
Description:
 smartmontools - control and monitor storage systems using S.M.A.R.T.
Closes: 254953 287195 292489
Changes:
 smartmontools (5.32-3) unstable; urgency=medium
 .
   * urgency medium since this fixes an important bug targeted for Sarge
   * grab patch from CVS by Doug Gilbert that fixes wrong health
     reporting of SCSI disks (Closes: #292489)
   * document problems with Asus P4C800E-Dlx (Closes: #287195)
   * document fixed ntp time drift with kernels >= 2.4.26 (Closes: #254953)
Files:
 ee2ee9ac7729a0c45d93ec1b51449682 577 utils optional smartmontools_5.32-3.dsc
 f7c0c85c9ca7fadf5ec2c1ba3ccb6677 32118 utils optional smartmontools_5.32-3.diff.gz
 dfcec03bd22705735c0ffbce34de134c 228740 utils optional smartmontools_5.32-3_powerpc.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQFCBPL+n88szT8+ZCYRAsEwAJ9FjsU/WqWFNUGOx+HOCs0kJrVjgQCbB+WN
k1XkzfdU/tDajVuqcTNxnKc=
=DVmT
-----END PGP SIGNATURE-----