Re: Dell 1950 does not properly respond to reboot and shutdown -p
On Tue, Oct 10, 2006 at 02:53:15PM -0400, Bill Moran wrote:
In response to Doug Ambrisko [EMAIL PROTECTED]:
John Baldwin writes:
| On Tuesday 10 October 2006 08:54, Bill Moran wrote:
| In response to Doug Ambrisko [EMAIL PROTECTED]:
| Bruno Ducrot writes:
| | On Wed, Oct 04, 2006 at 02:07:12PM -0400, Bill Moran wrote:
| | In response to Bruno Ducrot [EMAIL PROTECTED]:
| | Hi,
| |
| | On Wed, Oct 04, 2006 at 12:28:35PM -0400, Bill Moran wrote:
| |
| |A reboot causes the OS to halt, but the hardware just sits
there on the
| |shutdown screen.
| |
| |A shutdown -p does the same.
| |
| | What exactly are the last few lines?
| |
| | (manually copied)
| |
| | ...
| | All buffers synced.
| | Uptime: 1m16s
| |
| |
| | Thanks. Then this happen after print_uptime().
| |
| | I believe one of the drivers register a shutdown_final (or
| | shutdown_post_sync) event that hang your system. I think (though I
| | may be wrong) mfi may be that one.
| |
| | It would help if you can add some printf in dev/mfi/mfi.c into the
| | mfi_shutdown() function in order to check if that assumption
| | is correct.
|
| Some what related to this we have a local hack:
|
| --- sys/kern/subr_bus.c.orig Tue Jun 27 15:49:39 2006
| +++ sys/kern/subr_bus.c Tue Jun 27 15:49:51 2006
| @@ -2906,6 +2906,7 @@ bus_generic_shutdown(device_t dev)
| device_t child;
|
| TAILQ_FOREACH(child, dev-children, link) {
| + DELAY(1000);
| device_shutdown(child);
| }
|
| This patch seems to fix the problem. I'm going to replace it with
| some printfs and see if I can determine which driver is actually
| causing the problem (hopefully it's only one).
|
| Am I wrong in saying that the correct solution would be to identify the
| driver that needs more time and implementing some sort of polling
| mechanism to ensure the hardware is ready when the driver wants to
| shut down?
|
| Well, first let's see which driver it is. :) You might be able to just
| remove the DELAY and add a printf and see which device is printed last.
I think it was in a different ones. One of our configs has the base
HW + bge NIC the other has base HW + 2 x 2 port em NICs. The more
NIC's the better chance for a problem.
I've removed the hack from our kernel and I'm going to run the reboot
cycle. I don't think a printf will work since I recall trying that
it fixed the problem so I put the DELAY in :-( It could be generic
problem to the system with a sufficiently fast CPU to beat the
HW at shutting down. I'm not sure if his system is Dempsey or Woodcrest.
We use Woodcrest and they are really faster. Other machines might be
slow enough that it's not a a problem! We haven't seen it on our older
platforms with the same kernel and similar HW configs.
Well, I already did this. The only printf is the
device_printf(child, shutdown\n) that Bruno suggested. With this
single change, I'm unable to reproduce the problem.
Have any commits been made to 6-STABLE that might have inadvertently
fixed this in the last week or so?
The device_printf() function take too much time I think, so you get the same
behaviour as the DELAY().
--
Bruno Ducrot
-- Which is worse: ignorance or apathy?
-- Don't know. Don't care.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dell 1950 does not properly respond to reboot and shutdown -p
In response to Bruno Ducrot [EMAIL PROTECTED]:
On Tue, Oct 10, 2006 at 02:53:15PM -0400, Bill Moran wrote:
In response to Doug Ambrisko [EMAIL PROTECTED]:
John Baldwin writes:
| On Tuesday 10 October 2006 08:54, Bill Moran wrote:
| In response to Doug Ambrisko [EMAIL PROTECTED]:
| Bruno Ducrot writes:
| | On Wed, Oct 04, 2006 at 02:07:12PM -0400, Bill Moran wrote:
| | In response to Bruno Ducrot [EMAIL PROTECTED]:
| | Hi,
| |
| | On Wed, Oct 04, 2006 at 12:28:35PM -0400, Bill Moran wrote:
| |
| |A reboot causes the OS to halt, but the hardware just sits
there on the
| |shutdown screen.
| |
| |A shutdown -p does the same.
| |
| | What exactly are the last few lines?
| |
| | (manually copied)
| |
| | ...
| | All buffers synced.
| | Uptime: 1m16s
| |
| |
| | Thanks. Then this happen after print_uptime().
| |
| | I believe one of the drivers register a shutdown_final (or
| | shutdown_post_sync) event that hang your system. I think (though
I
| | may be wrong) mfi may be that one.
| |
| | It would help if you can add some printf in dev/mfi/mfi.c into the
| | mfi_shutdown() function in order to check if that assumption
| | is correct.
|
| Some what related to this we have a local hack:
|
| --- sys/kern/subr_bus.c.origTue Jun 27 15:49:39 2006
| +++ sys/kern/subr_bus.c Tue Jun 27 15:49:51 2006
| @@ -2906,6 +2906,7 @@ bus_generic_shutdown(device_t dev)
| device_t child;
|
| TAILQ_FOREACH(child, dev-children, link) {
| + DELAY(1000);
| device_shutdown(child);
| }
|
| This patch seems to fix the problem. I'm going to replace it with
| some printfs and see if I can determine which driver is actually
| causing the problem (hopefully it's only one).
|
| Am I wrong in saying that the correct solution would be to identify
the
| driver that needs more time and implementing some sort of polling
| mechanism to ensure the hardware is ready when the driver wants to
| shut down?
|
| Well, first let's see which driver it is. :) You might be able to just
| remove the DELAY and add a printf and see which device is printed last.
I think it was in a different ones. One of our configs has the base
HW + bge NIC the other has base HW + 2 x 2 port em NICs. The more
NIC's the better chance for a problem.
I've removed the hack from our kernel and I'm going to run the reboot
cycle. I don't think a printf will work since I recall trying that
it fixed the problem so I put the DELAY in :-( It could be generic
problem to the system with a sufficiently fast CPU to beat the
HW at shutting down. I'm not sure if his system is Dempsey or Woodcrest.
We use Woodcrest and they are really faster. Other machines might be
slow enough that it's not a a problem! We haven't seen it on our older
platforms with the same kernel and similar HW configs.
Well, I already did this. The only printf is the
device_printf(child, shutdown\n) that Bruno suggested. With this
single change, I'm unable to reproduce the problem.
Have any commits been made to 6-STABLE that might have inadvertently
fixed this in the last week or so?
The device_printf() function take too much time I think, so you get the same
behaviour as the DELAY().
True. Problem is that I considered that possibility, and removed the
device_printf(), rebuild the kernel, and have been unable to reproduce
the problem with a stock SMP kernel since yesterday.
I'm seriously considering the possibility that this has been fixed, but
I'm uncomfortable that nobody can say, Sure, I committed a fix to that
last week.
--
Bill Moran
Collaborative Fusion Inc.
IMPORTANT: This message contains confidential information and is
intended only for the individual named. If the reader of this
message is not an intended recipient (or the individual
responsible for the delivery of this message to an intended
recipient), please be advised that any re-use, dissemination,
distribution or copying of this message is prohibited. Please
notify the sender immediately by e-mail if you have received
this e-mail by mistake and delete this e-mail from your system.
E-mail transmission cannot be guaranteed to be secure or
error-free as information could be intercepted, corrupted, lost,
destroyed, arrive late or incomplete, or contain viruses. The
sender therefore does not accept liability for any errors or
omissions in the contents of this message, which arise as a
result of e-mail transmission.
___
Re: Dell 1950 does not properly respond to reboot and shutdown -p
Le 12 oct. 06 à 17:00, Bill Moran a écrit : In response to Bruno Ducrot [EMAIL PROTECTED]: The device_printf() function take too much time I think, so you get the same behaviour as the DELAY(). True. Problem is that I considered that possibility, and removed the device_printf(), rebuild the kernel, and have been unable to reproduce the problem with a stock SMP kernel since yesterday. I'm seriously considering the possibility that this has been fixed, but I'm uncomfortable that nobody can say, Sure, I committed a fix to that last week. I would be happy to test help, I also have a PE1950 around waiting for this problem to be solved to go in production. I would just need to have the patch. (I'll check the list archive later, I just joined freebsd-stable today) Btw, it would be nice if the patched if_bce.c could also be integrated into the cvs (http://yogurt.org/FreeBSD/if_bce.c). At the moment (beg. of the week) I still had to patch the source tree by hand to keep the network interface working fine (cf. thread on freebsd-hardware). Regards, Olivier ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dell 1950 does not properly respond to reboot and shutdown -p
In response to Olivier Mueller [EMAIL PROTECTED]: I would be happy to test help, I also have a PE1950 around waiting for this problem to be solved to go in production. I would just need to have the patch. (I'll check the list archive later, I just joined freebsd-stable today) There isn't really a patch per-se. Just a bunch of recommendations on where to put extra debugging information. You'll find it in the archives. Btw, it would be nice if the patched if_bce.c could also be integrated into the cvs (http://yogurt.org/FreeBSD/if_bce.c). At the moment (beg. of the week) I still had to patch the source tree by hand to keep the network interface working fine (cf. thread on freebsd-hardware). As you might guess, I'm also being bitten by this. Could you point me to the thread in hardware@ please, I've been unable to find it searching the archives. I'm guessing bce is not part of the title? -- Bill Moran Collaborative Fusion Inc. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dell 1950 does not properly respond to reboot and shutdown -p
Le 12 oct. 06 à 18:03, Bill Moran a écrit : There isn't really a patch per-se. Just a bunch of recommendations on where to put extra debugging information. You'll find it in the archives. ok thanks, I'll check. Btw, it would be nice if the patched if_bce.c could also be integrated into the cvs (http://yogurt.org/FreeBSD/if_bce.c). At the moment (beg. of the week) I still had to patch the source tree by hand to keep the network interface working fine (cf. thread on freebsd-hardware). As you might guess, I'm also being bitten by this. Could you point me to the thread in hardware@ please, I've been unable to find it searching the archives. I'm guessing bce is not part of the title? http://groups.google.com/group/muc.lists.freebsd.hardware/browse_frm/ thread/133aaa7da3792049/ Subject: dell poweredge 1950 : not rebooting under 6.1 (sometimes) HTH regards, Olivier ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dell 1950 does not properly respond to reboot and shutdown -p
In response to Olivier Mueller [EMAIL PROTECTED]: Btw, it would be nice if the patched if_bce.c could also be integrated into the cvs (http://yogurt.org/FreeBSD/if_bce.c). At the moment (beg. of the week) I still had to patch the source tree by hand to keep the network interface working fine (cf. thread on freebsd-hardware). Are you saying that the version from that site makes your bce card reliable? Doesn't seem to address the issues being worked on: http://lists.freebsd.org/pipermail/freebsd-stable/2006-October/029407.html -- Bill Moran Collaborative Fusion Inc. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dell 1950 does not properly respond to reboot and shutdown -p
On Thu, 2006-10-12 at 15:16 -0400, Bill Moran wrote: In response to Olivier Mueller [EMAIL PROTECTED]: Btw, it would be nice if the patched if_bce.c could also be integrated into the cvs (http://yogurt.org/FreeBSD/if_bce.c). At the moment (beg. of the week) I still had to patch the source tree by hand to keep the network interface working fine (cf. thread on freebsd-hardware). Are you saying that the version from that site makes your bce card reliable? Doesn't seem to address the issues being worked on: http://lists.freebsd.org/pipermail/freebsd-stable/2006-October/029407.html On my system, it seems to work 100% fine, I transfered hundreds of GB via the network using rsync and ftp during tests, and no problem anymore. But I heard that some people were still having issues with UDP and/or NFS traffic. regards, Olivier ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Dell 1950 does not properly respond to reboot and shutdown -p
-Original Message- From: [EMAIL PROTECTED] [mailto:owner-freebsd- [EMAIL PROTECTED] On Behalf Of Olivier Mueller Sent: Thursday, October 12, 2006 3:30 PM To: [EMAIL PROTECTED] Subject: Re: Dell 1950 does not properly respond to reboot and shutdown -p On Thu, 2006-10-12 at 15:16 -0400, Bill Moran wrote: In response to Olivier Mueller [EMAIL PROTECTED]: Btw, it would be nice if the patched if_bce.c could also be integrated into the cvs (http://yogurt.org/FreeBSD/if_bce.c). At the moment (beg. of the week) I still had to patch the source tree by hand to keep the network interface working fine (cf. thread on freebsd-hardware). Are you saying that the version from that site makes your bce card reliable? Doesn't seem to address the issues being worked on: http://lists.freebsd.org/pipermail/freebsd-stable/2006- October/029407.html On my system, it seems to work 100% fine, I transfered hundreds of GB via the network using rsync and ftp during tests, and no problem anymore. But I heard that some people were still having issues with UDP and/or NFS traffic. regards, Olivier Yep- UDP is pretty much the issue. I've got a 2950 up for ~20 days, 100s of GB's of traffic over TCP (SSH PostgreSQL in particular) and no problems. One little snippit of udp (raw, NFS, or for some odd reason, even Webmin over SSL) and it barfs. Oh, and this is on 6.1 amd64 release. (yes, I'll update to 6-2 beta sometime soon when I'm feeling lucky.. fortunately for me I need neither webmin nor UDP/NFS at the moment ;) - Bucky ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dell 1950 does not properly respond to reboot and shutdown -p
In response to Doug Ambrisko [EMAIL PROTECTED]:
Bruno Ducrot writes:
| On Wed, Oct 04, 2006 at 02:07:12PM -0400, Bill Moran wrote:
| In response to Bruno Ducrot [EMAIL PROTECTED]:
| Hi,
|
| On Wed, Oct 04, 2006 at 12:28:35PM -0400, Bill Moran wrote:
|
|A reboot causes the OS to halt, but the hardware just sits there on
the
|shutdown screen.
|
|A shutdown -p does the same.
|
| What exactly are the last few lines?
|
| (manually copied)
|
| ...
| All buffers synced.
| Uptime: 1m16s
|
|
| Thanks. Then this happen after print_uptime().
|
| I believe one of the drivers register a shutdown_final (or
| shutdown_post_sync) event that hang your system. I think (though I
| may be wrong) mfi may be that one.
|
| It would help if you can add some printf in dev/mfi/mfi.c into the
| mfi_shutdown() function in order to check if that assumption
| is correct.
Some what related to this we have a local hack:
--- sys/kern/subr_bus.c.orig Tue Jun 27 15:49:39 2006
+++ sys/kern/subr_bus.c Tue Jun 27 15:49:51 2006
@@ -2906,6 +2906,7 @@ bus_generic_shutdown(device_t dev)
device_t child;
TAILQ_FOREACH(child, dev-children, link) {
+ DELAY(1000);
device_shutdown(child);
}
This patch seems to fix the problem. I'm going to replace it with
some printfs and see if I can determine which driver is actually
causing the problem (hopefully it's only one).
Am I wrong in saying that the correct solution would be to identify the
driver that needs more time and implementing some sort of polling
mechanism to ensure the hardware is ready when the driver wants to
shut down?
--
Bill Moran
Collaborative Fusion Inc.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dell 1950 does not properly respond to reboot and shutdown -p
On Tuesday 10 October 2006 08:54, Bill Moran wrote:
In response to Doug Ambrisko [EMAIL PROTECTED]:
Bruno Ducrot writes:
| On Wed, Oct 04, 2006 at 02:07:12PM -0400, Bill Moran wrote:
| In response to Bruno Ducrot [EMAIL PROTECTED]:
| Hi,
|
| On Wed, Oct 04, 2006 at 12:28:35PM -0400, Bill Moran wrote:
|
|A reboot causes the OS to halt, but the hardware just sits there on
the
|shutdown screen.
|
|A shutdown -p does the same.
|
| What exactly are the last few lines?
|
| (manually copied)
|
| ...
| All buffers synced.
| Uptime: 1m16s
|
|
| Thanks. Then this happen after print_uptime().
|
| I believe one of the drivers register a shutdown_final (or
| shutdown_post_sync) event that hang your system. I think (though I
| may be wrong) mfi may be that one.
|
| It would help if you can add some printf in dev/mfi/mfi.c into the
| mfi_shutdown() function in order to check if that assumption
| is correct.
Some what related to this we have a local hack:
--- sys/kern/subr_bus.c.origTue Jun 27 15:49:39 2006
+++ sys/kern/subr_bus.c Tue Jun 27 15:49:51 2006
@@ -2906,6 +2906,7 @@ bus_generic_shutdown(device_t dev)
device_t child;
TAILQ_FOREACH(child, dev-children, link) {
+ DELAY(1000);
device_shutdown(child);
}
This patch seems to fix the problem. I'm going to replace it with
some printfs and see if I can determine which driver is actually
causing the problem (hopefully it's only one).
Am I wrong in saying that the correct solution would be to identify the
driver that needs more time and implementing some sort of polling
mechanism to ensure the hardware is ready when the driver wants to
shut down?
Well, first let's see which driver it is. :) You might be able to just
remove the DELAY and add a printf and see which device is printed last.
--
John Baldwin
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dell 1950 does not properly respond to reboot and shutdown -p
John Baldwin writes:
| On Tuesday 10 October 2006 08:54, Bill Moran wrote:
| In response to Doug Ambrisko [EMAIL PROTECTED]:
| Bruno Ducrot writes:
| | On Wed, Oct 04, 2006 at 02:07:12PM -0400, Bill Moran wrote:
| | In response to Bruno Ducrot [EMAIL PROTECTED]:
| | Hi,
| |
| | On Wed, Oct 04, 2006 at 12:28:35PM -0400, Bill Moran wrote:
| |
| |A reboot causes the OS to halt, but the hardware just sits there
on the
| |shutdown screen.
| |
| |A shutdown -p does the same.
| |
| | What exactly are the last few lines?
| |
| | (manually copied)
| |
| | ...
| | All buffers synced.
| | Uptime: 1m16s
| |
| |
| | Thanks. Then this happen after print_uptime().
| |
| | I believe one of the drivers register a shutdown_final (or
| | shutdown_post_sync) event that hang your system. I think (though I
| | may be wrong) mfi may be that one.
| |
| | It would help if you can add some printf in dev/mfi/mfi.c into the
| | mfi_shutdown() function in order to check if that assumption
| | is correct.
|
| Some what related to this we have a local hack:
|
| --- sys/kern/subr_bus.c.orig Tue Jun 27 15:49:39 2006
| +++ sys/kern/subr_bus.c Tue Jun 27 15:49:51 2006
| @@ -2906,6 +2906,7 @@ bus_generic_shutdown(device_t dev)
| device_t child;
|
| TAILQ_FOREACH(child, dev-children, link) {
| + DELAY(1000);
| device_shutdown(child);
| }
|
| This patch seems to fix the problem. I'm going to replace it with
| some printfs and see if I can determine which driver is actually
| causing the problem (hopefully it's only one).
|
| Am I wrong in saying that the correct solution would be to identify the
| driver that needs more time and implementing some sort of polling
| mechanism to ensure the hardware is ready when the driver wants to
| shut down?
|
| Well, first let's see which driver it is. :) You might be able to just
| remove the DELAY and add a printf and see which device is printed last.
I think it was in a different ones. One of our configs has the base
HW + bge NIC the other has base HW + 2 x 2 port em NICs. The more
NIC's the better chance for a problem.
I've removed the hack from our kernel and I'm going to run the reboot
cycle. I don't think a printf will work since I recall trying that
it fixed the problem so I put the DELAY in :-( It could be generic
problem to the system with a sufficiently fast CPU to beat the
HW at shutting down. I'm not sure if his system is Dempsey or Woodcrest.
We use Woodcrest and they are really faster. Other machines might be
slow enough that it's not a a problem! We haven't seen it on our older
platforms with the same kernel and similar HW configs.
Doug A.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dell 1950 does not properly respond to reboot and shutdown -p
On Tuesday 10 October 2006 13:20, Doug Ambrisko wrote:
John Baldwin writes:
| On Tuesday 10 October 2006 08:54, Bill Moran wrote:
| In response to Doug Ambrisko [EMAIL PROTECTED]:
| Bruno Ducrot writes:
| | On Wed, Oct 04, 2006 at 02:07:12PM -0400, Bill Moran wrote:
| | In response to Bruno Ducrot [EMAIL PROTECTED]:
| | Hi,
| |
| | On Wed, Oct 04, 2006 at 12:28:35PM -0400, Bill Moran wrote:
| |
| |A reboot causes the OS to halt, but the hardware just sits
there on the
| |shutdown screen.
| |
| |A shutdown -p does the same.
| |
| | What exactly are the last few lines?
| |
| | (manually copied)
| |
| | ...
| | All buffers synced.
| | Uptime: 1m16s
| |
| |
| | Thanks. Then this happen after print_uptime().
| |
| | I believe one of the drivers register a shutdown_final (or
| | shutdown_post_sync) event that hang your system. I think (though I
| | may be wrong) mfi may be that one.
| |
| | It would help if you can add some printf in dev/mfi/mfi.c into the
| | mfi_shutdown() function in order to check if that assumption
| | is correct.
|
| Some what related to this we have a local hack:
|
| --- sys/kern/subr_bus.c.origTue Jun 27 15:49:39 2006
| +++ sys/kern/subr_bus.c Tue Jun 27 15:49:51 2006
| @@ -2906,6 +2906,7 @@ bus_generic_shutdown(device_t dev)
| device_t child;
|
| TAILQ_FOREACH(child, dev-children, link) {
| + DELAY(1000);
| device_shutdown(child);
| }
|
| This patch seems to fix the problem. I'm going to replace it with
| some printfs and see if I can determine which driver is actually
| causing the problem (hopefully it's only one).
|
| Am I wrong in saying that the correct solution would be to identify the
| driver that needs more time and implementing some sort of polling
| mechanism to ensure the hardware is ready when the driver wants to
| shut down?
|
| Well, first let's see which driver it is. :) You might be able to just
| remove the DELAY and add a printf and see which device is printed last.
I think it was in a different ones. One of our configs has the base
HW + bge NIC the other has base HW + 2 x 2 port em NICs. The more
NIC's the better chance for a problem.
I've removed the hack from our kernel and I'm going to run the reboot
cycle. I don't think a printf will work since I recall trying that
it fixed the problem so I put the DELAY in :-( It could be generic
problem to the system with a sufficiently fast CPU to beat the
HW at shutting down. I'm not sure if his system is Dempsey or Woodcrest.
We use Woodcrest and they are really faster. Other machines might be
slow enough that it's not a a problem! We haven't seen it on our older
platforms with the same kernel and similar HW configs.
Can you break into the debugger when it is broken? If so, then change the
printf to a KTR trace and enable just that KTR trace and do 'show ktr' in
ddb to see which devices were shutdown.
--
John Baldwin
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dell 1950 does not properly respond to reboot and shutdown -p
Bill Moran wrote: A reboot causes the OS to halt, but the hardware just sits there on the shutdown screen. A shutdown -p does the same. Other ACPIish stuff seems to work as advertised. (i.e. hitting the power button cleanly shuts down the OS) I'm posting this to stable@, but the same behaviour occurs with FreeBSD 6.1-RELEASE as well. Does setting hw.acpi.handle_reboot to 1 via sysctl help? If set, this variable will use ACPI to perform the reboot action via the reset register instead of using the keyboard controller or a triple fault to reboot. Guy -- Guy Helmer, Ph.D. Chief System Architect Palisade Systems, Inc. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dell 1950 does not properly respond to reboot and shutdown -p
In response to Guy Helmer [EMAIL PROTECTED]: Bill Moran wrote: A reboot causes the OS to halt, but the hardware just sits there on the shutdown screen. A shutdown -p does the same. Other ACPIish stuff seems to work as advertised. (i.e. hitting the power button cleanly shuts down the OS) I'm posting this to stable@, but the same behaviour occurs with FreeBSD 6.1-RELEASE as well. Does setting hw.acpi.handle_reboot to 1 via sysctl help? If set, this variable will use ACPI to perform the reboot action via the reset register instead of using the keyboard controller or a triple fault to reboot. I manually changed that setting and the behaviour did not change. Does the setting need set before the kernel boots? -- Bill Moran Collaborative Fusion Inc. IMPORTANT: This message contains confidential information and is intended only for the individual named. If the reader of this message is not an intended recipient (or the individual responsible for the delivery of this message to an intended recipient), please be advised that any re-use, dissemination, distribution or copying of this message is prohibited. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dell 1950 does not properly respond to reboot and shutdown -p
Bill Moran wrote: In response to Guy Helmer [EMAIL PROTECTED]: Bill Moran wrote: A reboot causes the OS to halt, but the hardware just sits there on the shutdown screen. A shutdown -p does the same. Other ACPIish stuff seems to work as advertised. (i.e. hitting the power button cleanly shuts down the OS) I'm posting this to stable@, but the same behaviour occurs with FreeBSD 6.1-RELEASE as well. Does setting hw.acpi.handle_reboot to 1 via sysctl help? If set, this variable will use ACPI to perform the reboot action via the reset register instead of using the keyboard controller or a triple fault to reboot. I manually changed that setting and the behaviour did not change. Does the setting need set before the kernel boots? The value of that parameter is checked at runtime so you should be able to set it while the system is running. Do you get an ACPI reset failed message on the console? Guy -- Guy Helmer, Ph.D. Chief System Architect Palisade Systems, Inc. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dell 1950 does not properly respond to reboot and shutdown -p
Hi, On Wed, Oct 04, 2006 at 12:28:35PM -0400, Bill Moran wrote: A reboot causes the OS to halt, but the hardware just sits there on the shutdown screen. A shutdown -p does the same. What exactly are the last few lines? Other ACPIish stuff seems to work as advertised. (i.e. hitting the power button cleanly shuts down the OS) -- Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dell 1950 does not properly respond to reboot and shutdown -p
On Wednesday 04 October 2006 12:42, Guy Helmer wrote: Bill Moran wrote: In response to Guy Helmer [EMAIL PROTECTED]: Bill Moran wrote: A reboot causes the OS to halt, but the hardware just sits there on the shutdown screen. A shutdown -p does the same. Other ACPIish stuff seems to work as advertised. (i.e. hitting the power button cleanly shuts down the OS) I'm posting this to stable@, but the same behaviour occurs with FreeBSD 6.1-RELEASE as well. Does setting hw.acpi.handle_reboot to 1 via sysctl help? If set, this variable will use ACPI to perform the reboot action via the reset register instead of using the keyboard controller or a triple fault to reboot. I manually changed that setting and the behaviour did not change. Does the setting need set before the kernel boots? The value of that parameter is checked at runtime so you should be able to set it while the system is running. Do you get an ACPI reset failed message on the console? Guy For what it's worth I have 6.1-R on a 1950 and reboot works just fine. Haven't tried the shutdown -p command. -- Thanks, Josh Paetzel ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dell 1950 does not properly respond to reboot and shutdown -p
In response to Guy Helmer [EMAIL PROTECTED]: Bill Moran wrote: In response to Guy Helmer [EMAIL PROTECTED]: Bill Moran wrote: A reboot causes the OS to halt, but the hardware just sits there on the shutdown screen. A shutdown -p does the same. Other ACPIish stuff seems to work as advertised. (i.e. hitting the power button cleanly shuts down the OS) I'm posting this to stable@, but the same behaviour occurs with FreeBSD 6.1-RELEASE as well. Does setting hw.acpi.handle_reboot to 1 via sysctl help? If set, this variable will use ACPI to perform the reboot action via the reset register instead of using the keyboard controller or a triple fault to reboot. I manually changed that setting and the behaviour did not change. Does the setting need set before the kernel boots? The value of that parameter is checked at runtime so you should be able to set it while the system is running. Do you get an ACPI reset failed message on the console? No. -- Bill Moran Collaborative Fusion Inc. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dell 1950 does not properly respond to reboot and shutdown -p
In response to Bruno Ducrot [EMAIL PROTECTED]: Hi, On Wed, Oct 04, 2006 at 12:28:35PM -0400, Bill Moran wrote: A reboot causes the OS to halt, but the hardware just sits there on the shutdown screen. A shutdown -p does the same. What exactly are the last few lines? (manually copied) ... All buffers synced. Uptime: 1m16s -- Bill Moran Collaborative Fusion Inc. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dell 1950 does not properly respond to reboot and shutdown -p
On Wed, 4 Oct 2006, Bill Moran wrote: A reboot causes the OS to halt, but the hardware just sits there on the shutdown screen. A shutdown -p does the same. Other ACPIish stuff seems to work as advertised. (i.e. hitting the power button cleanly shuts down the OS) I'm posting this to stable@, but the same behaviour occurs with FreeBSD 6.1-RELEASE as well. Although it is most probably not related, I had similar problems when I used an NDIS-wrapped driver on my Dell Latitude C840 with 6-STABLE. It was fixed by switching to the ath driver. I do not recall if the power button worked or not. reboots always worked. Sean -- [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dell 1950 does not properly respond to reboot and shutdown -p
On Wed, Oct 04, 2006 at 02:07:12PM -0400, Bill Moran wrote: In response to Bruno Ducrot [EMAIL PROTECTED]: Hi, On Wed, Oct 04, 2006 at 12:28:35PM -0400, Bill Moran wrote: A reboot causes the OS to halt, but the hardware just sits there on the shutdown screen. A shutdown -p does the same. What exactly are the last few lines? (manually copied) ... All buffers synced. Uptime: 1m16s Thanks. Then this happen after print_uptime(). I believe one of the drivers register a shutdown_final (or shutdown_post_sync) event that hang your system. I think (though I may be wrong) mfi may be that one. It would help if you can add some printf in dev/mfi/mfi.c into the mfi_shutdown() function in order to check if that assumption is correct. Cheers, -- Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dell 1950 does not properly respond to reboot and shutdown -p
Bruno Ducrot writes:
| On Wed, Oct 04, 2006 at 02:07:12PM -0400, Bill Moran wrote:
| In response to Bruno Ducrot [EMAIL PROTECTED]:
| Hi,
|
| On Wed, Oct 04, 2006 at 12:28:35PM -0400, Bill Moran wrote:
|
|A reboot causes the OS to halt, but the hardware just sits there on the
|shutdown screen.
|
|A shutdown -p does the same.
|
| What exactly are the last few lines?
|
| (manually copied)
|
| ...
| All buffers synced.
| Uptime: 1m16s
|
|
| Thanks. Then this happen after print_uptime().
|
| I believe one of the drivers register a shutdown_final (or
| shutdown_post_sync) event that hang your system. I think (though I
| may be wrong) mfi may be that one.
|
| It would help if you can add some printf in dev/mfi/mfi.c into the
| mfi_shutdown() function in order to check if that assumption
| is correct.
Some what related to this we have a local hack:
--- sys/kern/subr_bus.c.origTue Jun 27 15:49:39 2006
+++ sys/kern/subr_bus.c Tue Jun 27 15:49:51 2006
@@ -2906,6 +2906,7 @@ bus_generic_shutdown(device_t dev)
device_t child;
TAILQ_FOREACH(child, dev-children, link) {
+ DELAY(1000);
device_shutdown(child);
}
Seems like we were tearing things done to fast and resources
stolen away from HW that was totally shutdown yet or something.
I think this was worse when things had shared interrupts but
I forget the exact details. It's been a lot time when I put
in the hack and moved onto the next fire. It seems the more HW
we had in the machine the worse the problem was.
This is just a hack and not a fix.
Doug A.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
