Re: Intel i8xx watchdog driver
On Monday 11 December 2006 10:34, Daniel O'Connor wrote: > I saw your (2004) post about the watchdog driver for the i8xx and I was > wondering if you could send it to me? Whoops, no wonder I didn't get a reply. Not to menion it's already committed :) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgpbNGF805OGe.pgp Description: PGP signature
Re: Intel i8xx watchdog driver
Correction... On Thu, Mar 25, 2004 at 11:26:59PM +, Bruce M Simpson wrote: > I wrote code to unlock the SMM within FreeBSD last summer on an IBM T22 ^^ discover and map. > with the 440BX chipset. Here it is. Half asleep here. Doh! BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Intel i8xx watchdog driver
On Thu, Mar 25, 2004 at 05:40:33PM -0500, Don Bowman wrote: > SMI under freebsd? Ha ha... Good luck! It didn't look very > easy. The SMM, for those who don't know it, is a virtual > 86, real-mode thing, at a location in ram which is locked > and unaccessible unless you are in smm mode :) If you > are lucky, your bios didn't lock you out of it. I wrote code to unlock the SMM within FreeBSD last summer on an IBM T22 with the 440BX chipset. Here it is. BMS /* $FreeBSD$ */ /* * A tool for FreeBSD to discover SMRAM on i440BX based motherboards. * This isn't finished or complete, left as exercise for the reader. */ /* * Copyright (c) 2003 Bruce M. Simpson <[EMAIL PROTECTED]> * All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright *notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright *notice, this list of conditions and the following disclaimer in the *documentation and/or other materials provided with the distribution. * 3. All advertising materials mentioning features or use of this software *must display the following acknowledgement: *This product includes software developed by Bruce M. Simpson. * 4. Neither the name of Bruce M. Simpson nor the names of co- *contributors may be used to endorse or promote products derived *from this software without specific prior written permission. * * THIS SOFTWARE IS PROVIDED BY Bruce M. Simpson AND CONTRIBUTORS * ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED * TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL Bruce M. Simpson OR CONTRIBUTORS * BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE * POSSIBILITY OF SUCH DAMAGE. */ #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #ifndef _DEV_PCI #define _DEV_PCI "/dev/pci" #endif #ifndef _DEV_MEM #define _DEV_MEM "/dev/mem" #endif /* * It appears as though my ThinkPad does not map SMRAM at the default * location. This isn't too much of a surprise. Firmware is responsible * for reprogramming the default location, and has to issue an SMI * during boot in order to do this. The actual SMI handler code is * located at SMBASE+0x8000. A quick way of issuing the SMI is to use * the on-chip APIC. A number of vendor BIOS do it this way. * * Can we discover if the host bridge remaps SMBASE? Yes. * on the i440BX host bridge, check the SMRAMC register. * * There are two modes: Compatible and Extended SMRAM. Compatible mode * is meant to be backwards compatible with older BIOS PM code. * The C_BASE_SEG bits will tell you where the SMRAM memory * really is. Setting D_OPEN to high will let you get at the SMRAM memory. * * If your VGA controller mapping is active, it would be a good idea not * to use it while you're doing this. * * My ThinkPad's BIOS doesn't set the lock bit. * My ThinkPad's BIOS uses traditional SMRAM semantics. * i440BX Compatible SMRAM is hardwired to 0xA-0xB. * * By poking D_OPEN to 1, I was able to extract the SMRAM segment from * my machine. * # pciconf -r -b pci0:0:0 0x72 * 0a * # pciconf -w -b pci0:0:0 0x72 0x4A * # dd bs=0x1000 skip=0xA0 count=0x20 if=/dev/mem of=./foo * # pciconf -w -b pci0:0:0 0x72 0x0A */ #define I440BX 1 #ifdef DEF_SMM #define SMBASE 0x3UL /* default IA-32 SMBASE location */ #define SMSIZE 0x1UL /* default size of SMM area */ #endif #ifdef I440BX #define SMBASE 0xAUL /* default i440BX SMBASE location */ #define SMSIZE 0x2UL /* default size of SMM area (128KB) */ #endif #ifdef I440BX_HIGH #define SMBASE 0x100AUL /* default i440BX SMBASE location */ #define SMSIZE 0x2UL /* default size of SMM area (128KB) */ #endif #define I440BX_VENDOR 0x8086 /* Intel */ #define I440BX_DEVICE 0x7190 /* I440BX host-to-pci bridge */ #define CSR_SMRAMC 0x72/* System Management RAM Control */ #define CSR_ESMRAMC 0x73/* Extended SMRAM Control */ #define SMRAMC_D_OPEN 0x40 #define SMRAMC_D_CLS0x20 #define SMRAMC_D_LCK0x10/* SMRAM locked, game over. */ #define SMRAMC_G_SMRAME 0x08 #define SMRAMC_C_BAS
RE: Intel i8xx watchdog driver
From: Doug Ambrisko [mailto:[EMAIL PROTECTED] > Don Bowman writes: > | The Intel ICH3 (and probably all) has the feature it can > | issue an SMI on first count-down to 0, then a hard reset > | on 2nd. What we did was implement an SMM handler (in bios) > | that, when called due to watchdog, issued an NMI and did > | a return from smm. > | In FreeBSD, an NMI handler caught this (sometimes :), > | poke around to send a bit of data out to serial, moved the > | timer to the maximum value without reseting it, and then > | called panic [after mucking with cpl etc to pretend to > | own all locks :] > | If the NMI handler didn't get run, the hardware counted > | to 0 again and reset. > | If the NMI handler did get run, and then wedged somehow > | in the panic or whatever, the hardware counted to 0, > | and the system reset. > | If all worked well, you got a core, but at a minimum > | the system reset, and usually you got at least the > | serial output of some of the 'why'. > | > | The SMI is non-maskable (and higher priority than NMI). > > That sounds pretty cool. There was some bits in the ICH that > prevented an NMI to get to the CPU unless set a certain way. > I was generating an NMI via the PCI but. BTW you can do the > paper clip trick on PCI. The ICH seemed to be only one shot so > it de-bounced it. I could get multiple on a CPU NMI pin. > > How hard is to setup and trap SMI via a FreeBSD only solution? > > I haven't really looked much at that area but sounds useful. > > Doug A. > SMI under freebsd? Ha ha... Good luck! It didn't look very easy. The SMM, for those who don't know it, is a virtual 86, real-mode thing, at a location in ram which is locked and unaccessible unless you are in smm mode :) If you are lucky, your bios didn't lock you out of it. there's an NMI_NOW in the ICH which can be used to programmatically cause an NMI. Some systems route this funny when in SMP mode... [ie nowhere???]. Some systems may have problems with this and the jumper/button for generating NMI. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Intel i8xx watchdog driver
Don Bowman writes: | The Intel ICH3 (and probably all) has the feature it can | issue an SMI on first count-down to 0, then a hard reset | on 2nd. What we did was implement an SMM handler (in bios) | that, when called due to watchdog, issued an NMI and did | a return from smm. | In FreeBSD, an NMI handler caught this (sometimes :), | poke around to send a bit of data out to serial, moved the | timer to the maximum value without reseting it, and then | called panic [after mucking with cpl etc to pretend to | own all locks :] | If the NMI handler didn't get run, the hardware counted | to 0 again and reset. | If the NMI handler did get run, and then wedged somehow | in the panic or whatever, the hardware counted to 0, | and the system reset. | If all worked well, you got a core, but at a minimum | the system reset, and usually you got at least the | serial output of some of the 'why'. | | The SMI is non-maskable (and higher priority than NMI). That sounds pretty cool. There was some bits in the ICH that prevented an NMI to get to the CPU unless set a certain way. I was generating an NMI via the PCI but. BTW you can do the paper clip trick on PCI. The ICH seemed to be only one shot so it de-bounced it. I could get multiple on a CPU NMI pin. How hard is to setup and trap SMI via a FreeBSD only solution? I haven't really looked much at that area but sounds useful. Doug A. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: Intel i8xx watchdog driver
From: Doug Ambrisko [mailto:[EMAIL PROTECTED] > Scott Long writes: > | In reading the code, it appears that it is indeed an ICHx > service and > | not limited to just i8xx chipsets. I have a few issues with how the > | probe and attach are done, and I'm addressing these in a > private mail > | right now. It's funny that I was reading the Intel ICH5 > docs last night > | and didn't come across this feature at all. > > I haven't looked at the code but have worked with this feature. > The Intel ICH3 (and probably all) has the feature it can issue an SMI on first count-down to 0, then a hard reset on 2nd. What we did was implement an SMM handler (in bios) that, when called due to watchdog, issued an NMI and did a return from smm. In FreeBSD, an NMI handler caught this (sometimes :), poke around to send a bit of data out to serial, moved the timer to the maximum value without reseting it, and then called panic [after mucking with cpl etc to pretend to own all locks :] If the NMI handler didn't get run, the hardware counted to 0 again and reset. If the NMI handler did get run, and then wedged somehow in the panic or whatever, the hardware counted to 0, and the system reset. If all worked well, you got a core, but at a minimum the system reset, and usually you got at least the serial output of some of the 'why'. The SMI is non-maskable (and higher priority than NMI). ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Intel i8xx watchdog driver
Scott Long writes: | In reading the code, it appears that it is indeed an ICHx service and | not limited to just i8xx chipsets. I have a few issues with how the | probe and attach are done, and I'm addressing these in a private mail | right now. It's funny that I was reading the Intel ICH5 docs last night | and didn't come across this feature at all. I haven't looked at the code but have worked with this feature. | I'm not sure if I like the idea of auto-reboot on second expire, unless | it is configurable (i.e. you can turn that feature off depending on the | situation). I understand it's purpose though. Note sure what you mean by that. The second expire means you didn't catch a hang so you must be dead. If the system is dead then you want it to reboot. You do need a way to cancel this and I think PHK API allowed that. I used his early Soekris WD a while back. The real purpose of the TCO timer & SIS timer is that a BIOS can set aggressive timings and back off if the systems fails to boot. This way a user doesn't have to tune the BIOS. A lot of chipsets have it and I've seen it in some Winbond Super I/O chips. However, we can use it for free for our purposes :-) | > A nice concept would be to have a SW watchdog based on the clock tickle | > the HW watchdog. If the SW watchdog goes off you get a panic. | > | > Interesting caveats are having the watchdogs going off while in kgdb/ddb. | | Talking with PHK about this now. There seems to be a growing need for a | mechanism that can inform registered listeners that DDB is about to be | entered. It's just a random thought in my brain right now, need more | time to flesh it out. Perfect. consmute is another. What's the point of entering DDB is the console is muted :-( I have code so if DDB or panic is entered then consmute is disabled for that period. Basically I just switched consmute into a function that can be called from the DDB/panic routines. Now there are reasons to really mute the console no matter what. It would be cool if we could layer all this. One reason I did a HW watchdog to enforce a SW watchdog is that various HW watchdogs have different time ranges. The SW watchdog can easily run within that range. Then a user-land app can set a long SW watchdog and not have to worry about if it get starved for a while triggering a false reboot. For example who cares if the watchdog is set for 15 minutes. That is better then having to drive to a co-lo. etc. on a Sunday morning :-( Your chance for a false trigger is greatly reduced. | > I have code for the SIS 630 chipset that I can give to anyone interested. | | More support it wonderful! I don't have any hardware to test it on, though. I don't have direct access to HW anymore but have working code. I've been watching the HW watchdog stuff and can add it once some of these issues have been resolved. All of my current code is quick hacks to get around immediate issues but it is in production. Doug A. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Intel i8xx watchdog driver
Doug Ambrisko wrote: Scott Long writes: | Wm. Daryl Hawkins wrote: | > I've written a driver for the Intel i8xx TCO watchdog timer for both | > FreeBSD-CURRENT and FreeBSD-STABLE. | | This is wonderful. I'd be happy to test it and shepherd it in. Does it | support the intel 750x chips also? All ICH chips that I've touched support this with the device ID updated as needed. FYI there is a new watchdog device in the 6300ESB. Not sure if it is in prior ICH chips. It is interesting in that during the first expire it will generate and interrupt then it will reboot on the next expire. So if you have an ICH then you can use it. In reading the code, it appears that it is indeed an ICHx service and not limited to just i8xx chipsets. I have a few issues with how the probe and attach are done, and I'm addressing these in a private mail right now. It's funny that I was reading the Intel ICH5 docs last night and didn't come across this feature at all. I'm not sure if I like the idea of auto-reboot on second expire, unless it is configurable (i.e. you can turn that feature off depending on the situation). I understand it's purpose though. A nice concept would be to have a SW watchdog based on the clock tickle the HW watchdog. If the SW watchdog goes off you get a panic. Interesting caveats are having the watchdogs going off while in kgdb/ddb. Talking with PHK about this now. There seems to be a growing need for a mechanism that can inform registered listeners that DDB is about to be entered. It's just a random thought in my brain right now, need more time to flesh it out. Caveat to the ICH TCO timer is that if the speaker output out of the ICH has a pull up resistor on it then the TCO reset is disabled and will not reset the system. I ran into this on a motherboard at a prior company. You cannot via SW disable this feature :-( I have code for the SIS 630 chipset that I can give to anyone interested. More support it wonderful! I don't have any hardware to test it on, though. Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Intel i8xx watchdog driver
Scott Long writes: | Wm. Daryl Hawkins wrote: | > I've written a driver for the Intel i8xx TCO watchdog timer for both | > FreeBSD-CURRENT and FreeBSD-STABLE. | | This is wonderful. I'd be happy to test it and shepherd it in. Does it | support the intel 750x chips also? All ICH chips that I've touched support this with the device ID updated as needed. FYI there is a new watchdog device in the 6300ESB. Not sure if it is in prior ICH chips. It is interesting in that during the first expire it will generate and interrupt then it will reboot on the next expire. So if you have an ICH then you can use it. A nice concept would be to have a SW watchdog based on the clock tickle the HW watchdog. If the SW watchdog goes off you get a panic. Interesting caveats are having the watchdogs going off while in kgdb/ddb. Caveat to the ICH TCO timer is that if the speaker output out of the ICH has a pull up resistor on it then the TCO reset is disabled and will not reset the system. I ran into this on a motherboard at a prior company. You cannot via SW disable this feature :-( I have code for the SIS 630 chipset that I can give to anyone interested. Doug A. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Intel i8xx watchdog driver
Wm. Daryl Hawkins wrote: I've written a driver for the Intel i8xx TCO watchdog timer for both FreeBSD-CURRENT and FreeBSD-STABLE. This is my first driver and it's only seen limited testing, so proceed with caution! The FreeBSD-CURRENT package contains a loadable kernel module and was written to work with Poul-Henning Kamp's watchdog driver model. The FreeBSD-STABLE package contains both the loadable kernel module and a userland daemon. I've tested it with 4.9, 5.2.1, and CURRENT on a Supermicro P4SGE motherboard and would be grateful for any suggestions, comments, bug reports, or complaints! :) If there is sufficient interest (and once I've gotten some comment on the structure and inner workings of this driver), I'd also like to write a driver for the AMD-8000 series chipset. You can get the driver at: http://freebsd.tamu.edu/wdog/ -- Daryl This is wonderful. I'd be happy to test it and shepherd it in. Does it support the intel 750x chips also? Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: Intel i8xx watchdog driver
Yes. The version for current hasn't seen as much testing as the version for stable. I only have one or two test boxes with current on them, but it seems to be working just fine with watchdogd. -- Daryl -Original Message- From: Poul-Henning Kamp [mailto:[EMAIL PROTECTED] Sent: Thursday, March 25, 2004 11:35 AM To: Wm. Daryl Hawkins Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Intel i8xx watchdog driver In message <[EMAIL PROTECTED]>, "Wm. Da ryl Hawkins" writes: > >I've written a driver for the Intel i8xx TCO watchdog timer for >both FreeBSD-CURRENT and FreeBSD-STABLE. Is this written against the API in -current ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Intel i8xx watchdog driver
In message <[EMAIL PROTECTED]>, "Wm. Da ryl Hawkins" writes: > >I've written a driver for the Intel i8xx TCO watchdog timer for >both FreeBSD-CURRENT and FreeBSD-STABLE. Is this written against the API in -current ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Intel i8xx watchdog driver
On Thu, Mar 11, 2004 at 07:07:36PM -0600, Wm. Daryl Hawkins wrote: > I would love to incorporate it in both source trees if possible. Before > it goes into current, I need to make some changes so that it will work > with Poul-Henning Kamp's new watchdog driver model. Hopefully, I'll get > to work on that some tomorrow. I'll release a new version for current > as soon as it's ready. Excellent, I was just going to suggest that. On the subject of 'bits and bobs that hang off buses', Stacy Millions wrote a driver for the FWH RNG, and Doug Ambrisko rolled some code to flash the FWH on an i845 chipset if memory serves... I am happy to look at your code once it fits better with what we currently have providing I have time. Good work BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: Intel i8xx watchdog driver
Thanks, thats great news. Perhaps even as a port would do the trick. ---Mike At 08:07 PM 11/03/2004, Wm. Daryl Hawkins wrote: I would love to incorporate it in both source trees if possible. Before it goes into current, I need to make some changes so that it will work with Poul-Henning Kamp's new watchdog driver model. Hopefully, I'll get to work on that some tomorrow. I'll release a new version for current as soon as it's ready. -- Daryl -Original Message- From: Mike Tancsa [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 10, 2004 9:17 PM To: Wm. Daryl Hawkins Cc: [EMAIL PROTECTED] Subject: Re: Intel i8xx watchdog driver Wow, this is great! I tried it out on a few RELENG_4 boxes and it works as expected wdog0 on motherboard isab0: Found Intel 82801DB watchdog device Are there any plans to incorporate this into the 5.x and 4.x source tree ? This would be useful to a lot of people. ---Mike On Wed, 10 Mar 2004 10:54:38 -0600, in sentex.lists.freebsd.hackers you wrote: > >I've written a driver and userland daemon for the Intel i8xx TCO >watchdog timer. This is my first driver and it's only seen limited >testing, so proceed with caution! I've tested it with 4.9 and 5.2.1 on >a Supermicro P4SGE motherboard and would be grateful for any >suggestions, comments, bug reports, or complaints! :) If there is >sufficient interest (and once I've gotten some comment on the structure >and inner workings of this driver), I'd also like to write a driver for >the AMD-8000 series chipset. You can get the driver at: >http://freebsd.tamu.edu/wdog/ > >-- Daryl > > >Daryl Hawkins >Network Systems >Texas A&M University >[EMAIL PROTECTED] >___ >[EMAIL PROTECTED] mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: Intel i8xx watchdog driver
I would love to incorporate it in both source trees if possible. Before it goes into current, I need to make some changes so that it will work with Poul-Henning Kamp's new watchdog driver model. Hopefully, I'll get to work on that some tomorrow. I'll release a new version for current as soon as it's ready. -- Daryl -Original Message- From: Mike Tancsa [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 10, 2004 9:17 PM To: Wm. Daryl Hawkins Cc: [EMAIL PROTECTED] Subject: Re: Intel i8xx watchdog driver Wow, this is great! I tried it out on a few RELENG_4 boxes and it works as expected wdog0 on motherboard isab0: Found Intel 82801DB watchdog device Are there any plans to incorporate this into the 5.x and 4.x source tree ? This would be useful to a lot of people. ---Mike On Wed, 10 Mar 2004 10:54:38 -0600, in sentex.lists.freebsd.hackers you wrote: > >I've written a driver and userland daemon for the Intel i8xx TCO >watchdog timer. This is my first driver and it's only seen limited >testing, so proceed with caution! I've tested it with 4.9 and 5.2.1 on >a Supermicro P4SGE motherboard and would be grateful for any >suggestions, comments, bug reports, or complaints! :) If there is >sufficient interest (and once I've gotten some comment on the structure >and inner workings of this driver), I'd also like to write a driver for >the AMD-8000 series chipset. You can get the driver at: >http://freebsd.tamu.edu/wdog/ > >-- Daryl > > >Daryl Hawkins >Network Systems >Texas A&M University >[EMAIL PROTECTED] >___ >[EMAIL PROTECTED] mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Intel i8xx watchdog driver
Wow, this is great! I tried it out on a few RELENG_4 boxes and it works as expected wdog0 on motherboard isab0: Found Intel 82801DB watchdog device Are there any plans to incorporate this into the 5.x and 4.x source tree ? This would be useful to a lot of people. ---Mike On Wed, 10 Mar 2004 10:54:38 -0600, in sentex.lists.freebsd.hackers you wrote: > >I've written a driver and userland daemon for the Intel i8xx TCO watchdog timer. >This is my first driver and it's only seen limited testing, so proceed with caution! >I've tested it with 4.9 and 5.2.1 on a Supermicro P4SGE motherboard and would be >grateful for any suggestions, comments, bug reports, or complaints! :) If there is >sufficient interest (and once I've gotten some comment on the structure and inner >workings of this driver), I'd also like to write a driver for the AMD-8000 series >chipset. You can get the driver at: http://freebsd.tamu.edu/wdog/ > >-- Daryl > > >Daryl Hawkins >Network Systems >Texas A&M University >[EMAIL PROTECTED] >___ >[EMAIL PROTECTED] mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
