[patch] IPMI driver for Linux

[patch] IPMI driver for Linux

[Corey Minyard]

I have been working on an IPMI driver for Linux for MontaVista, and I 
think it's ready to see the light of day :-).  I would like to see this 
included in the mainstream kernel eventually.   You can get it at 
http://home.attbi.com/~minyard.  It should work on any kernel version, 
although you will have to fix up the Config.in and Makefile, and the 
Configure.help stuff may not work (it's currently in the 2.4 location).

The web page has documentation on the driver, and documentation is 
included in the patch, too.  This is a fairly full-featured driver with 
a watchdog, panic event generation, full kernel and userland access to 
the driver, multi-user/multi-interface support, and emulators for other 
IPMI device drivers.

-Corey
minyard@acm.org

Re: [patch] IPMI driver for Linux

[Alan Cox]

On Wed, 2002-08-21 at 16:47, Corey Minyard wrote:
> I have been working on an IPMI driver for Linux for MontaVista, and I 
> think it's ready to see the light of day :-).  I would like to see this 
> included in the mainstream kernel eventually.   You can get it at 
> http://home.attbi.com/~minyard.  It should work on any kernel version, 
> although you will have to fix up the Config.in and Makefile, and the 
> Configure.help stuff may not work (it's currently in the 2.4 location).
> 
> The web page has documentation on the driver, and documentation is 
> included in the patch, too.  This is a fairly full-featured driver with 
> a watchdog, panic event generation, full kernel and userland access to 
> the driver, multi-user/multi-interface support, and emulators for other 
> IPMI device drivers.

Comments in general.

It touches user space with spinlocks held -> bad idea
It doesnt check copy_*_user returns instead commenting that some other
driver didnt so it wont - bad idea too
It seems to be allocating a major - can you have > 1 ipmi per host, can
it use misc devices, can it get one registered properly with lanana

Otherwise its way way way nicer than the hideous thing a certain chip
vendor sent me.

Re: [patch] IPMI driver for Linux

[Corey Minyard]

Alan Cox wrote:

>On Wed, 2002-08-21 at 16:47, Corey Minyard wrote:
>  
>
>>I have been working on an IPMI driver for Linux for MontaVista, and I 
>>think it's ready to see the light of day :-).  I would like to see this 
>>included in the mainstream kernel eventually.   You can get it at 
>>http://home.attbi.com/~minyard.  It should work on any kernel version, 
>>although you will have to fix up the Config.in and Makefile, and the 
>>Configure.help stuff may not work (it's currently in the 2.4 location).
>>
>>The web page has documentation on the driver, and documentation is 
>>included in the patch, too.  This is a fairly full-featured driver with 
>>a watchdog, panic event generation, full kernel and userland access to 
>>the driver, multi-user/multi-interface support, and emulators for other 
>>IPMI device drivers.
>>    
>>
>
>Comments in general.
>
>It touches user space with spinlocks held -> bad idea
>
Oops, thanks.  I've uploaded a version that fixes this.  I only found 
one instance of this, but it's pretty bad.

>It doesnt check copy_*_user returns instead commenting that some other
>driver didnt so it wont - bad idea too
>
This was only in the emulation code.  I debated about this, but it's 
quite possible that doing the check will break the current users of this 
code.  I'm afraid if I add the checks it will cause other broken code to 
not work.  I could pull out the emulation code and supply it separately; 
I would probably choose to not put that part into the mainstream kernel, 
anyway.

>It seems to be allocating a major - can you have > 1 ipmi per host, can
>it use misc devices, can it get one registered properly with lanana
>
Yes, you can have multiple IPMI interfaces on a host (I have a board 
that has 3!).  There are serial-port interfaces planned that could also 
easily have multiple instances as well as an on-board KCS.  If there's 
an easy way to do this with a minor device, I'm all ears, but I'd prefer 
to have a separate device for each interface.  This is one of the things 
I wanted discussion about.  Once that gets settled, I'll go to lanana. 
 Right now it's just being auto-assigned.

>Otherwise its way way way nicer than the hideous thing a certain chip
>vendor sent me.
>  
>
I know what you mean.

Thank you for your response and suggestions.

-Corey
minyard@acm.org

Preempt kernel patch for 2.4.19?

[Jurgen Kramer]

I am looking for the preemptive kernel patch for 2.4.19. The latest
2.4.19 patch is for 2.4.19rc5-ac1 dated August 1st. And there is also a
patch for 2.4.20pre2 but not for plain 2.4.19.

Any change somebody made a patch for 2.4.19?
 

Thanks,

Jurgen

Re: Preempt kernel patch for 2.4.19?

[J Sloan]

IIRC 2.4.19 is basically identical to 2.4.19-rc5 -

(except for the version number )

I'm running 2.4.19rc5aa1 on top of 2.4.19 -

Joe

Jurgen Kramer wrote:

>I am looking for the preemptive kernel patch for 2.4.19. The latest
>2.4.19 patch is for 2.4.19rc5-ac1 dated August 1st. And there is also a
>patch for 2.4.20pre2 but not for plain 2.4.19.
>
>Any change somebody made a patch for 2.4.19?
> 
>  
>

Re: Preempt kernel patch for 2.4.19?

[J Sloan]

ACK!

That should have read

    return ENOCAFEINE;

Anyway, running -ac is the best bet for 2.4-preempt...

Joe

J Sloan wrote:

> IIRC 2.4.19 is basically identical to 2.4.19-rc5 -
>
> (except for the version number )
>
> I'm running 2.4.19rc5aa1 on top of 2.4.19 -
>
> Joe
>
> Jurgen Kramer wrote:
>
>> I am looking for the preemptive kernel patch for 2.4.19. The latest
>> 2.4.19 patch is for 2.4.19rc5-ac1 dated August 1st. And there is also a
>> patch for 2.4.20pre2 but not for plain 2.4.19.
>>
>> Any change somebody made a patch for 2.4.19?
>>
>>  
>>
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe 
> linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Re: [patch] IPMI driver for Linux

[Pavel Machek]

Hi!

> I have been working on an IPMI driver for Linux for MontaVista, and I 
> think it's ready to see the light of day :-).  I would like to see this 

Just out of curiosity, what is IPMI?
								Pavel
-- 
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.

Re: [patch] IPMI driver for Linux

[Matthew Dharm]

[-- Attachment #1: Type: text/plain, Size: 1186 bytes --]

The "Intelligent Perhiperal Management Interface".  It's a managment system
for communicating to intelligent or semi-intelligent devices on a separate
communication channel from the 'typical' data paths.

I think you can download the specs from the Intel web site.

Matt

On Tue, Aug 27, 2002 at 02:55:13PM +0000, Pavel Machek wrote:
> Hi!
> 
> > I have been working on an IPMI driver for Linux for MontaVista, and I 
> > think it's ready to see the light of day :-).  I would like to see this 
> 
> Just out of curiosity, what is IPMI?
> 								Pavel
> -- 
> Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
> details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
Matthew Dharm                              Home: mdharm-usb@one-eyed-alien.net 
Maintainer, Linux USB Mass Storage Driver

We can customize our colonels.
					-- Tux
User Friendly, 12/1/1998

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: [patch] IPMI driver for Linux

[Corey Minyard]

Matthew Dharm wrote:

>The "Intelligent Perhiperal Management Interface".  It's a managment system
>for communicating to intelligent or semi-intelligent devices on a separate
>communication channel from the 'typical' data paths.
>
>I think you can download the specs from the Intel web site.
>
It's at http://www.intel.com/design/servers/ipmi/index.htm.  Note that 
many people are doing things far beyond what the spec says in multi-card 
chassis like CompactPCI and PICMG2.16.  Someone mentioned earlier that I 
must have access to documentation they don't have, I just know stuff 
lots of people are doing.

-Corey

Re: [patch] IPMI driver for Linux

[Corey Minyard]

I tie into the highres timer code for short sleeps.  It does require 
that you have highres timers installed in your kernel and enabled. 
 Otherwise you are right, it is very slow.

Since I had access to highres timers, that was a lot easier than hooking 
into and configuring the timer interrupt, and a lot more portable, too.

If you want to post your code or modify mine to add the timer interrupt 
support, that would be great.

-Corey

Larry Butler wrote:

>Corey,
>
>I've been working on a driver too because the busy waits in the drivers that 
>are out there can hold a CPU for too long.  I've measured as much as 120ms.
>
>First I tried sleeping in the driver until the very next jiffy.  I found that 
>my driver became unreliable under high CPU load because the scheduling delays 
>were too long.  I even managed wedge the BMC on one of my test systems in a 
>way I can't seem to fix. :)
>
>What I finally settled on was using the timer interrupt.  This seems to work 
>well both in terms of being nice to the rest of the system (I register a 
>shared irq handler only while I need it) and being reliable even under high 
>load.   So, just consider it a suggestion.  I'd like to see your driver 
>included too.  It's certainly more complete than mine.  You must have access 
>to more documentation than I do.
>
>Larry
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/
>  
>

Re: [patch] IPMI driver for Linux

[Larry Butler]

Corey,

I've been working on a driver too because the busy waits in the drivers that 
are out there can hold a CPU for too long.  I've measured as much as 120ms.

First I tried sleeping in the driver until the very next jiffy.  I found that 
my driver became unreliable under high CPU load because the scheduling delays 
were too long.  I even managed wedge the BMC on one of my test systems in a 
way I can't seem to fix. :)

What I finally settled on was using the timer interrupt.  This seems to work 
well both in terms of being nice to the rest of the system (I register a 
shared irq handler only while I need it) and being reliable even under high 
load.   So, just consider it a suggestion.  I'd like to see your driver 
included too.  It's certainly more complete than mine.  You must have access 
to more documentation than I do.

Larry