ich watchdog vs intel smm code
Some time earlier I reported that ichwd driver doesn't produce any effect on my system with Intel DG33TL motherboard when watchdog timer is allowed to expire. I did some investigation and also discussed the issue with a maintainer of Linux iTCO_wdt driver, Wim Van Sebroeck. He told me that the issue is present on most of Intel motherboards with ICH9 chipset. All evidence seems to point in one direction - Intel SMM code. It seems that ICH9 always gets configured by BIOS to produce an SMI when a watchdog timer expires. Also, ICH watchdog has a logic to cause a reboot if its timer expires twice in a row, this is to avoid a potential hang in SMI handler. ICH9 allows SMI to be globally enabled and disabled. BIOS configures it to be enabled. Sometimes this bit is locked down (by BIOS), so it's not possible to change it, but sometimes it is not locked. So, if we globally disable SMI, then the watchdog in ICH9 does indeed cause a reboot. Evidently this happens after the timer expires twice in row. My conclusion is that SMI handler installed by BIOS somehow acknowledges watchdog SMI (e.g. clears a certain status bit, or performs watchdog timer reload). But it doesn't execute any corrective action. My guess is there might some configuration (or some other form of massaging) that needs to be done in order to convince SMM code to perform a reboot upon watchdog SMI. It would be nice if we had some Intel insiders who could provide a glimpse into Intel SMM code logic with respect to the watchdog. Finally some technical details: NMI2SMI_EN and TCO_LOCK bits of TCO1_CNT are set 1: pmbase+0x0068: 0x1200 (TCO1_CNT) in SMI_EN register TCO_EN bit is 1, GBL_SMI_EN is 1, End of SMI (EOS) bit is 1 and (not sure if this matters) LEGACY_USB_EN is 1: pmbase+0x0030: 0x203b (SMI_EN) No Reboot (NR) bit of GCS register is zero: 0x3410: 0x00c01444 -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: ich watchdog vs intel smm code
- Original Message - From: Andriy Gapon a...@icyb.net.ua To: freebsd-hackers@freebsd.org; freebsd-a...@freebsd.org Sent: Monday, January 19, 2009 12:11 PM Subject: ich watchdog vs intel smm code Some time earlier I reported that ichwd driver doesn't produce any effect on my system with Intel DG33TL motherboard when watchdog timer is allowed to expire. I did some investigation and also discussed the issue with a maintainer of Linux iTCO_wdt driver, Wim Van Sebroeck. He told me that the issue is present on most of Intel motherboards with ICH9 chipset. All evidence seems to point in one direction - Intel SMM code. It seems that ICH9 always gets configured by BIOS to produce an SMI when a watchdog timer expires. Also, ICH watchdog has a logic to cause a reboot if its timer expires twice in a row, this is to avoid a potential hang in SMI handler. ICH9 allows SMI to be globally enabled and disabled. BIOS configures it to be enabled. Sometimes this bit is locked down (by BIOS), so it's not possible to change it, but sometimes it is not locked. So, if we globally disable SMI, then the watchdog in ICH9 does indeed cause a reboot. Evidently this happens after the timer expires twice in row. My conclusion is that SMI handler installed by BIOS somehow acknowledges watchdog SMI (e.g. clears a certain status bit, or performs watchdog timer reload). But it doesn't execute any corrective action. My guess is there might some configuration (or some other form of massaging) that needs to be done in order to convince SMM code to perform a reboot upon watchdog SMI. It would be nice if we had some Intel insiders who could provide a glimpse into Intel SMM code logic with respect to the watchdog. Finally some technical details: NMI2SMI_EN and TCO_LOCK bits of TCO1_CNT are set 1: pmbase+0x0068: 0x1200 (TCO1_CNT) in SMI_EN register TCO_EN bit is 1, GBL_SMI_EN is 1, End of SMI (EOS) bit is 1 and (not sure if this matters) LEGACY_USB_EN is 1: pmbase+0x0030: 0x203b (SMI_EN) No Reboot (NR) bit of GCS register is zero: 0x3410: 0x00c01444 I have a simmilar problem on my gigabyte motherboard (one of the X48 ones), however, I believe the fault to be in hardware and not in firmware or software.. Mentioned in the datasheet for the ICH9, the speaker pin is used as a configuration pin while reset it asserted. If a logic 1 is present on this pin when reset is deasserted, the ICH9 chip locks out the ability for software to enable the watchdog. With the ichwd driver for BSD, this condition is announced with a message like Watchdog present, but disabled in BIOS. (Well.. something close to that) ~Peg ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: ich watchdog vs intel smm code
on 19/01/2009 14:27 Pegasus Mc Cleaft said the following: - Original Message - From: Andriy Gapon a...@icyb.net.ua [snip] So, if we globally disable SMI, then the watchdog in ICH9 does indeed cause a reboot. Evidently this happens after the timer expires twice in row. [snip] Mentioned in the datasheet for the ICH9, the speaker pin is used as a configuration pin while reset it asserted. If a logic 1 is present on this pin when reset is deasserted, the ICH9 chip locks out the ability for software to enable the watchdog. With the ichwd driver for BSD, this condition is announced with a message like Watchdog present, but disabled in BIOS. (Well.. something close to that) ICH WDT present but disabled in BIOS or hardware I believe your issue is quite a different one, it is older and known and explicitly reported by the driver. In this case the watchdog does work and does seem to generate SMI. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: panic: Going nowhere without my init!
* Garrett Cooper yanef...@gmail.com wrote: I still don't understand why adding a [C, etc] `comment' would cause these problems. I guess if you break getpid() to not return 1 in the case of init(8), it will just say init: already running and quit. This causes this panic to occur. -- Ed Schouten e...@80386.nl WWW: http://80386.nl/ pgpgNsKwUqyHe.pgp Description: PGP signature
Wi-Fi support - which iface works better?
Hi world, I'm up to build a little Wi-Fi network at my home. So I need to know, what Wi-Fi NIC is working better under FreeBSD 7.1, from the next little list: ZyXEL G-302 EE D-link DWA-510 ASUS WL-138g V2 TRENDnet TEW-423PI P.S. Digging the 7.1 Hardware Notes on the Web gave me no information about that cards. Please note me if they are supported at all. WBR, Igor Krasnoselski ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Wi-Fi support - which iface works better?
igor krasnoselski writes: Hi world, I'm up to build a little Wi-Fi network at my home. So I need to know, what Wi-Fi NIC is working better under FreeBSD 7.1, from the next little list: ZyXEL G-302 EE D-link DWA-510 ASUS WL-138g V2 TRENDnet TEW-423PI P.S. Digging the 7.1 Hardware Notes on the Web gave me no information about that cards. Please note me if they are supported at all. It depends on the wifi chipset present in those NICs. I prefer Atheros, as it is well supported (at least in 8-CURRENT) and has complete FOSS drivers :). So I think you should find which NIC has which chipset. HTH -- Ashish SHUKLA pgpZ7JnWPwE4q.pgp Description: PGP signature
Re: Wi-Fi support - which iface works better?
igor krasnoselski wrote: I'm up to build a little Wi-Fi network at my home. So I need to know, what Wi-Fi NIC is working better under FreeBSD 7.1, from the next little list: ZyXEL G-302 EE D-link DWA-510 ASUS WL-138g V2 TRENDnet TEW-423PI P.S. Digging the 7.1 Hardware Notes on the Web gave me no information about that cards. Please note me if they are supported at all. WBR, Igor Krasnoselski This depends on the card chipset. It's sometimes hard to tell by the card model and I don't know which chipsets these cards have. I used two cards with chipsets: Atheros 5212 (ath) and Ralink Technology RT2561S (ral). Both of them don't work in a stable way under 71-PRERELEASE and in a very similar way. Connections get broken, link goes down sporadically. 'up scan' hangs, pings often don't go through after link is established, 'airdump' command stops working after a while on both of them. Based on these experiences i came to a conclusion that WiFi support isn't stable yet in FreeBSD. Yuri ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: panic: Going nowhere without my init!
Ed Schouten e...@80386.nl writes: I guess if you break getpid() to not return 1 in the case of init(8), it will just say init: already running and quit. This causes this panic to occur. Who knows? We have no idea what the OP actually did, because he didn't bother to tell us. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: threaded, forked, rethreaded processes will deadlock
On Fri, Jan 16, 2009 at 02:36:06PM -0800, Jason Evans wrote: Brian Fundakowski Feldman wrote: Could you, and anyone else who would care to, check this out? It's a regression fix but it also makes the code a little bit clearer. Thanks! Index: lib/libc/stdlib/malloc.c Why does malloc need to change for this? Unless there's a really good reason, I don't want the extra branches in the locking functions. Because malloc is the thing causing the regression. It is easy enough to optimize out the one extra fetch and branch in the single-threaded case if I can get some consensus that the fix to it is actually fine. -- Brian Fundakowski Feldman \'[ FreeBSD ]''\ gr...@freebsd.org \ The Power to Serve! \ Opinions expressed are my own. \,,\ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: panic: Going nowhere without my init!
Hi All,
Sorry for late reply, i was out of work for a week.
I made wrong comment in Getpid():
Getpid() {
/* ..
/* ... */
*/
return()
}
I removed it and now it is working fine.
Thanks
--- On Mon, 1/19/09, Dag-Erling Smørgrav d...@des.no wrote:
From: Dag-Erling Smørgrav d...@des.no
Subject: Re: panic: Going nowhere without my init!
To: Ed Schouten e...@80386.nl
Cc: Garrett Cooper yanef...@gmail.com, shilp.ka...@yahoo.com, FreeBSD
Hackers freebsd-hackers@freebsd.org
Date: Monday, January 19, 2009, 3:13 PM
Ed Schouten e...@80386.nl writes:
I guess if you break getpid() to not return 1 in the case of init(8), it
will just say init: already running and quit. This causes this
panic
to occur.
Who knows? We have no idea what the OP actually did, because he didn't
bother to tell us.
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to
freebsd-hackers-unsubscr...@freebsd.org
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
