[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Netra T1 200 watchdog timeouts

On Sat, Sep 22, 2012 at 12:26:26PM +0100, Richard Mortimer wrote:
> On 19/09/2012 13:10, Mark Morgan Lloyd wrote:
> >Richard Mortimer wrote:
> >>On 18/09/2012 18:49, Mark Morgan Lloyd wrote:
> >>>Richard Mortimer wrote:
> ... snip ...
> >>>>>This affects both Lenny and Wheezy but does not affect Squeeze,
> >>>>>i.e. it
> >>>>>appears to be a regression. Since this happens in between the OBP boot
> >>>>>command and SILO's boot prompt, I presume that it is a SILO problem or
> >>>>>that the installer is doing something odd to the disklabel.
> >>>>>
> >>>>>Lenny:    1.4.13
> >>>>>Squeeze: 1.4.14
> >>>>>Wheezy:    1.4.14
> >>>>
> >>>>I don't see how the LOM firmware would affect this. OBP maybe but if
> >>>>it is a processor watchdog then it I doubt its LOM. SILO would be my
> >>>>first suspect.
> >>>
> >>>SILO is also my suspect (after a lot of fiddling trying to disable lom
> >>>watchdog from OBP etc.) and those are SILO version numbers :-/
> >>>
> >>Brain wasn't turned on enough to realise that!
> >>
> >> From memory I don't think the LOM watchdog is ever enabled in OBP on
> >>the T1 200. It only ever gets enabled by the device drivers once
> >>Solaris is running (if the packages you mention below are installed of
> >>course).
> >
> >OK but at the same time the README from Solaris patch 110208-21
> >explicitly says
> >
> >5043823  Patch 110208-18 changes watchdog behavior and causes watchdog
> >resets when probed
> >
> >and
> >
> >4412177  lomlite2 watchdog is not always disabled on "reboot" - 110208-07
> >
> >both of which read as though there could be spurious watchdog events
> >even without Solaris's intervention. However I note your point about the
> >LOM log not showing anything.
> I'm still pretty convinced that the problem you are seeing is
> nothing to do with LOM. I think that both of those are Solaris
> device driver issues too.
> >
> >Should I be raising this as a bug, or can I assume that the people who
> >need to know about it are already aware of the issue?
> Given that this affects Wheezy then a Debian bug is certainly in order.
> I haven't had time to track the development of Wheezy closely but I
> think that it is pretty much using upstream SILO. I vaguely remember
> a few changes upstream recently for both ext2/4 support and for cpu
> detection. One of those could be causing your problem on the Wheezy
> build.

Well, Mark mentioned that the same issue is encountered in both Wheezy 
and Squeeze SILO versions, which predates the recent ext2/4 changes.

And yes, there haven't been any Debian-specific changes to upstream 
SILO as of version 1.4.14+git20100228-1, uploaded in February 2010. 
Before that we had some Debian-specific patches included.

Mark, if you can try different SILO versions and find out which one 
introduced the regression, that would be great. As far as I can tell, 
releases shipped with the following versions:

Lenny  : 1.4.13a+git20070930-3
Squeeze: 1.4.14+git20100228-1+b1 

Assuming that the failure was introduced between 1.4.13a+git20070930-3 
(Lenny version) and 1.4.14+git20100228-1+b1 (Squeeze version), you 
just have one intermediate version (1.4.14+git20100207-1) to test.

> Given the nature of the problem I think it would be useful to have a
> good description of your installation in the bug. In particular
> filesystem layout (partition table), type (ext2/3/4) etc. may be
> relevant. A copy of the console session would be good to attach too.

Yep, the bug would be useful. Given that it's the first report like 
this that I see and that a simple enough workaround exists, I would 
don't think it qualifies as RC.

Best regards,
Jurij Smakov                                           jurij@wooyd.org
Key: http://www.wooyd.org/pgpkey/                      KeyID: C99E03CC

Reply to: