mirror of https://lore.kernel.org/lkml/
 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 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®