Re: [smartmontools-support]Re: Logs - ideas what this is reporting?

[<Nic...@pw...>]

OK, thanks for all the help.

But I am still a bit confused with the messages.  I have a box at home
running the same kernel version on the same machine (Dell Optiplex).  This
doesn't show any DMA time-out or whatnots - smartd runs on this smoothly,
with just the scheduled self-tests showing in syslogs.

This box here at work has copious lines in syslogs all the time.

There are new smartd warnings/notices also now:

Device: /dev/hda, SMART Prefailure Attribute: 8 Seek_Time_Performance
changed from 247 to 248

Along with the Usuage Attribute changes, I get 5 of these every 30 minute
period - but since I cleaned out the box, and re-seated everything, new IDE
cable etc. etc. the DMA timeouts have vanished.

So, if it is a 2.4.6 kernel problem, then really running smartd on systems
like this is really pointless if messages are spurious?

FYI

00:00.0 Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge
(rev 03)
00:01.0 PCI bridge: Intel Corporation 440BX/ZX - 82443BX/ZX AGP bridge (rev
03)
00:07.0 ISA bridge: Intel Corporation 82371AB PIIX4 ISA (rev 02)
00:07.1 IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 01)
00:07.2 USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 01)
00:07.3 Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 02)
00:0f.0 PCI bridge: Digital Equipment Corporation DECchip 21152 (rev 03)


Thanks,

Nick




|---------+------------------------------------------------->
|         |           Bruce Allen                           |
|         |           <ba...@gr...>         |
|         |           Sent by:                              |
|         |           sma...@li...ur|
|         |           ceforge.net                           |
|         |                                                 |
|         |                                                 |
|         |           10/06/2004 16:48                      |
|         |                                                 |
|---------+------------------------------------------------->
  >----------------------------------------------------------------------------------------------|
  |                                                                                              |
  |       To:       Mario 'BitKoenig' Holbe <Mario.Holbe@RZ.TU-Ilmenau.DE>                       |
  |       cc:       sma...@li...                                  |
  |       Subject:  Re: [smartmontools-support]Re: Logs - ideas what this is reporting?          |
  >----------------------------------------------------------------------------------------------|




Hi Mario,

Thanks for the details. I've updated WARNINGS along the lines that you
suggested.

Cheers,
             Bruce

On Thu, 10 Jun 2004, Mario 'BitKoenig' Holbe wrote:

> On Thu, Jun 10, 2004 at 09:49:58AM -0500, Bruce Allen wrote:
> > > > May 30 07:55:40 website2 kernel: hda: dma_timer_expiry: dma status
== 0x21
> >
> > Mario, should I change the SYSTEM name currently in the WARNING file?
If
> > so, what do you suggest I change it to?
>
> Well, I personally have a Promise 20269 (20268 = Ultra100TX,
> 20268 = Ultra133TX). And it seems, such messages came up
> on other Promise controllers too.
>
> However, I don't think, it really has something to do with
> the Promise (or the Promise driver). As I said already: I
> just suspect the Promise to be a little more fragile
> regarding signal qualities. And there are similar reports
> for non-Promise controllers too.
>
> Therefore, I'd suggest SYSTEM to be something like:
> "Promise IDE-controllers and perhaps others too".
>
> And one more thing: the 'dma status == ' shows different
> numbers. This number is just a bitmask what the
> controller thinks about current running DMA requests.
>
> On the other hand, this kernel message (dma_timer_expiry)
> does only mean, that the kernel sent some request and got
> no reply within a reasonable time. In general, this issue
> can have different reasons:
> 1. kernel mistake: The kernel just *thinks* it expects
> a reply, while it really didn't sent a request.
> 2. controller mistake: The controller forgot to reply.
> 3. problems on the wire: The kernel did send a request,
> but the controller didn't receive it.
> 4. real timeout: the kernel sent a request, the controller
> did receive it, but the reply is just too slow.
>
> Thus, I don't think, that replacing the power supply is an
> all-time solution to that issue - it's just one thing to
> try - besindes exchanging cables, cleaning PCI-slots etc.
> (if 3. is the reason, one of them will most likely succeed :)).
>
>
> I'm sorry, but I cannot give a simple-and-clear answer at
> all - the problem is just too wide-spread.
>
>
> regards,
>    Mario
> --
> Independence Day: Fortunately, the alien computer operating system works
just
> fine with the laptop. This proves an important point which Apple
enthusiasts
> have known for years. While the evil empire of Microsoft may dominate the
> computers of Earth people, more advanced life forms clearly prefer Mac's.
>
>



-------------------------------------------------------
This SF.Net email is sponsored by the new InstallShield X.
From Windows to Linux, servers to mobile, InstallShield X is the
one installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504
_______________________________________________
Smartmontools-support mailing list
Sma...@li...
https://lists.sourceforge.net/lists/listinfo/smartmontools-support