All of lore.kernel.org
 help / color / mirror / Atom feed
From: Corey Minyard <cminyard@mvista.com>
To: "Randy.Dunlap" <rddunlap@osdl.org>
Cc: torvalds@transmeta.com, linux-kernel@vger.kernel.org
Subject: Re: IPMI fix for panic handling
Date: Thu, 21 Aug 2003 11:53:31 -0500	[thread overview]
Message-ID: <3F44F90B.7060101@mvista.com> (raw)
In-Reply-To: <20030821093037.64962c27.rddunlap@osdl.org>

Randy.Dunlap wrote:

>On Thu, 21 Aug 2003 08:05:04 -0500 Corey Minyard <cminyard@mvista.com> wrote:
>
>| This patch adds something I missed that previous IPMI drivers did, 
>| adding panic information to the event log. Some programs use this 
>
>adding to which event log?
>
This is the IPMI event log (the System Event Log).

>
>| information to analyze panics. Please apply.
>
>
>Few corrections below.
>
>
>diff -u -r1.3 Kconfig
>--- drivers/char/ipmi/Kconfig	28 Mar 2003 05:14:18 -0000	1.3
>+++ drivers/char/ipmi/Kconfig	19 Aug 2003 14:20:43 -0000
>@@ -24,6 +24,18 @@
> 	 generate an IPMI event describing the panic to each interface
> 	 registered with the message handler.
> 
>+config IPMI_PANIC_STRING
>+	bool 'Generate a OEM events holding the panic string'
>
>I can't decode/translate that quoted string...
>'an OEM event' ??
>s/holding/containing/ ??
>
I'll work on that.  Is the description below good enough?

>
>+	depends on IPMI_PANIC_EVENT
>+	help
>+	  When a panic occurs, this will cause the IPMI message handler to
>+	  generate an IPMI OEM type f0 events holding the IPMB address of the
>                                       event
>+	  panic generator (byte 4 of the event), a sequence number for the
>+	  string (byte 5 of the event) and part of the string (the rest of the
>+	  event).  Bytes 1, 2, and 3 are the normal usage for an OEM event.
>+	  You can fetch these events and use the sequence numbers to piece the
>+	  string together.
>+
> config IPMI_DEVICE_INTERFACE
>        tristate 'Device interface for IPMI'
>        depends on IPMI_HANDLER
>
>diff -u -r1.7 ipmi_msghandler.c
>--- drivers/char/ipmi/ipmi_msghandler.c	24 May 2003 17:02:51 -0000	1.7
>+++ drivers/char/ipmi/ipmi_msghandler.c	19 Aug 2003 14:20:45 -0000
>@@ -1813,18 +1829,48 @@
> {
> }
> 
>-static void send_panic_events(void)
>+#ifdef CONFIG_IPMI_PANIC_STRING
>+static void event_receiver_fetcher(ipmi_smi_t intf, struct ipmi_smi_msg *msg)
>+{
>+	if ((msg->rsp[0] == (0x5 << 2))
>
>Some named constants would be good here (defines/macros)
>and below.
>
Ok, I'm being lazy.

>+
>+		/* Request the device info from the local MC. */
>+		msg.netfn = 0x06; /* App. */
>+		msg.cmd = 0x01; /* Get device id cmd */
>+		msg.data = NULL;
>+		msg.data_len = 0;
>+		intf->null_user_handler = device_id_fetcher;
>+		i_ipmi_request(NULL,
>+			       intf,
>+			       &addr,
>+			       0,
>+			       &msg,
>+			       &smi_msg,
>+			       &recv_msg,
>+			       0,
>+			       intf->my_address,
>+			       intf->my_lun);
>
>Looks like a Windows interface call.  One parameter/line isn't needed.
>
It seems to me that with a function with this many parameter calls, it's 
a lot easier to handle them one per line, since counting lines is a lot 
easier than finding commas.  I'd prefer to leave this as is (I'll work 
on reducing the number of parameters, which is the real problem :-), but 
I'm not picky either way.  I didn't know Windows developers did this.

-Corey


  reply	other threads:[~2003-08-21 17:04 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-08-21 13:05 IPMI fix for panic handling Corey Minyard
2003-08-21 16:30 ` Randy.Dunlap
2003-08-21 16:53   ` Corey Minyard [this message]
2003-08-21 17:03     ` Randy.Dunlap

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3F44F90B.7060101@mvista.com \
    --to=cminyard@mvista.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rddunlap@osdl.org \
    --cc=torvalds@transmeta.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.