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
[email protected]
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.
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
[email protected]
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
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 [email protected]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
>
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.
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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Matthew Dharm Home: [email protected]
Maintainer, Linux USB Mass Storage Driver
We can customize our colonels.
-- Tux
User Friendly, 12/1/1998
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
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
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?
>
>
>