esm module and ntp problem

Brian Smith BSmith at lyrix.com
Tue Jan 14 10:17:07 CST 2003


Mike,

Yes, we found that out as well.  I'm still going to leave the systems going
as they are just to see how they time drift without the dcstor32d.

This should not have slipped past Dell QA.

Thank you for keeping us posted.

- Brian



                                                                                                                          
                    Michael Redinger                                                                                      
                    <Michael.Redinger at ui        To:     Linux-Poweredge at dell.com                                          
                    bk.ac.at>                   cc:                                                                       
                    Sent by:                    Subject:     Re: esm module and ntp problem                               
                    linux-poweredge-admi                                                                                  
                    n at dell.com                                                                                            
                                                                                                                          
                                                                                                                          
                    01/14/03 10:23 AM                                                                                     
                                                                                                                          
                                                                                                                          





Bad news:
dcstor32d seems to be responsible for much of the core functionality of
OMSA.
If you disable it, you don't get any information about the system
(components, service tag etc.) and, even worse, you don't get any alarms
any more!
So, this is definitely no solution, not even a workaround ...

Just wanted you to know about the status.

I'm back again at the support hotline. My next try is to flash BIOS, ERA
and the backblane to see if anything changes (don't think so, but the
support guy wants me to try this ...).

Will be back with more news.

Michael

On Tue, 14 Jan 2003, Brian Smith wrote:

> Do you know what the function of "dcstor32d" is?   I assume "dcsnmp32d"
is
> for the snmp support.  And I assume "dcevt32d" is for the event logging
in
> the /var/log/messages file when the status of something changes.  Does
> anyone know what each daemon does?


> Some news:
>
> This is based on information provided by the Dell Support Hotline
(thanks)
> and it seems as if I can verify this:
>
> The problem is _not_ the esm module (directly, at least) but dcstor32d.
>
> When I kill dcstor32d (and restart ntpd), things seem to work fine (for
> some hours now ...).
>
> (However, if I disable dcstor32d, I basically loose all of OMSA's
> functionality ...)
>
>
> Michael
>
> On Sat, 11 Jan 2003, Michael Redinger wrote:
>
> > On Fri, 10 Jan 2003, JP Vossen wrote:
> >
> > > On Fri, 10 Jan 2003, Michael Redinger wrote:
> > >
> > > > Summary:
> > > > when esm kernel module is loaded on a 2650, the ntpd regularily
> looses the
> > > > synchronization. 100% reproduceable for me.
> > >
> > > I have a PE500SC and am NOT running the esm module, byt my ntp loses
> > > synchronization every Monday morning just as my backup job is ending.
> All RH8
> > > errata applied.  Search the list archives for details.  No joy so
> far... :-(
> >
> >
> > I've several 1550, 1650 and 2650 here, I've never seen something
similar
> > to your problem ...
> >
> > Well, my problem seems to be different. However, your mail reminded me
to
>
> > add the ntpd -d output (to the web forum page). Thanks.
> >
> > I now found that a mail from Geoff French (Geoff.French at noaa.gov)
> > describes maybe exactly the same problem:
> >
> >
>
http://lists.us.dell.com/pipermail/linux-poweredge/2002-December/010629.html

>
> >
> >
> > A small part of the debugging output is given below.
> > If I interpret it correctly, the interresting part is
> > "ntp_set_tod: settimeofday: 0: Interrupted system call", then ntpd
clears
>
> > the connections and restarts syncing (again completely reproducable for
> > me):
> >
> >
> > Jan 11 16:18:09 ns0 ntpd: clock_update: at 1104 assoc 6
> > Jan 11 16:18:09 ns0 ntpd: local_clock: assocID 44887 off 3.842509 jit
> > 0.001390 sta 3
> > Jan 11 16:18:09 ns0 ntpd: step_systime: step 3.842509 residual 0.000000
> > Jan 11 16:18:09 ns0 ntpd: In ntp_set_tod
> > Jan 11 16:18:09 ns0 ntpd: ntp_set_tod: settimeofday: 0: Interrupted
> system
> > call
> > Jan 11 16:18:09 ns0 ntpd: ntp_set_tod: Final result: settimeofday: 0:
> > Interrupted system call
> > Jan 11 16:18:09 ns0 ntpd: local_clock: mu 908 noi 127846.538 stb 0.000
> pol
> > 4 cnt 0
> > Jan 11 16:18:09 ns0 ntpd: peer_clear: at 1104 assoc ID 44884
> > Jan 11 16:18:09 ns0 ntpd: peer_clear: at 1104 assoc ID 44888
> > Jan 11 16:18:09 ns0 ntpd: peer_clear: at 1104 assoc ID 44889
> > Jan 11 16:18:09 ns0 ntpd: peer_clear: at 1104 assoc ID 44887
> > Jan 11 16:18:09 ns0 ntpd: peer_clear: at 1104 assoc ID 44885
> > Jan 11 16:18:09 ns0 ntpd: peer_clear: at 1104 assoc ID 44886
> > Jan 11 16:18:09 ns0 ntpd: clear_all: at 1104
> > Jan 11 16:18:09 ns0 ntpd: report_event: system event
'event_clock_reset'
> > (0x05) status 'leap_none, sync_unspec, 15 events, event_peer/strat_chg'
> > (0xf4)
> > Jan 11 16:18:09 ns0 ntpd: report_event: system event
> > 'event_peer/strat_chg' (0x04) status 'leap_none, sync_unspec, 15
events,
> > event_clock_reset' (0xf5)
> >
> >
> >
> >
> > Michael
> >
> >
>
> --
> Michael Redinger
> Zentraler Informatikdienst (Computer Centre)
> Universitaet Innsbruck
> Technikerstrasse 13                     Tel.: ++43 512 507 2335
> 6020 Innsbruck                          Fax.: ++43 512 507 2944
> Austria                                                  Mail:
> Michael.Redinger at uibk.ac.at
>
> _______________________________________________
> Linux-PowerEdge mailing list
> Linux-PowerEdge at dell.com
> http://lists.us.dell.com/mailman/listinfo/linux-poweredge
> Please read the FAQ at http://lists.us.dell.com/faq or search the list
> archives at http://lists.us.dell.com/htdig/
>
>
>
>
>

--
Michael Redinger
Zentraler Informatikdienst (Computer Centre)
Universitaet Innsbruck
Technikerstrasse 13                     Tel.: ++43 512 507 2335
6020 Innsbruck                          Fax.: ++43 512 507 2944
Austria                                                  Mail:
Michael.Redinger at uibk.ac.at


_______________________________________________
Linux-PowerEdge mailing list
Linux-PowerEdge at dell.com
http://lists.us.dell.com/mailman/listinfo/linux-poweredge
Please read the FAQ at http://lists.us.dell.com/faq or search the list
archives at http://lists.us.dell.com/htdig/







More information about the Linux-PowerEdge mailing list