Hey Holger,
(BTW, I'm splitting this thread into two, so the response to the other
part is in the new thread).
I had intended to add this into ipmi-sel, but w/o a mobo to test on I
let it pass. If you're game to test a patch for me, I'd be glad to
implement it into ipmi-sel. I'm busy
Hey Dan,
Finally got a chance to look through your patch. For the most part it's
fine. I'll tweak a few formatting things to be consistent to other
parts of FreeIPMI, and I think I'll do first and last instead of 0
or -1 for the first/last SEL entry. But I'm a tad confused on this in
your
Hey Dan,
On Tue, 2010-08-17 at 11:04 -0700, Albert Chu wrote:
Hey Dan,
Finally got a chance to look through your patch. For the most part it's
fine. I'll tweak a few formatting things to be consistent to other
parts of FreeIPMI, and I think I'll do first and last instead of 0
or -1 for
On 08/16/10 22:40, Albert Chu:
This should already be handled.
You are true, problem is elsewhere.
I croped the sources to just:
---
int main (int argc, char **argv) {
char x[684*1024];
}
---
Compiled and linked:
gcc -shared
Hey Dan,
Glad it's not a freeipmi issue. That is quite odd though.
Al
On Tue, 2010-08-17 at 13:04 -0700, Dan Lukes wrote:
On 08/16/10 22:40, Albert Chu:
This should already be handled.
You are true, problem is elsewhere.
I croped the sources to just:
Hey Dan,
Attached is my reworked patch for ipmi-oem. Can you give it a shot and
LMK if it works?
I cleaned up some chunks for code consistency to other code in ipmi-oem
and added a manpage entry. I ended up removing the first and last
because I guess I don't see users wanting to/commonly using
On 08/17/10 23:10, Albert Chu:
Attached is my reworked patch for ipmi-oem. Can you give it a shot and
LMK if it works?
Done. Some notes:
1. --
if user call for record id = 65536 the number record ID is silently
changed to something else. I recommend not to allow out-of-range
