Re: svn commit: r205444 - head/sys/i386/i386
* Ed Maste ema...@freebsd.org wrote: I was just about to follow up with a comment to that effect. We do want it to become a panic, but I would prefer to hold off until we address the known issue with padlock(4). I have seen this message appear when using the ndisulator as well. How are we going to solve it in this case? Could the ndisulator be extended to prepare a FPU context using kib's new API? -- Ed Schouten e...@80386.nl WWW: http://80386.nl/ pgp36tpsDbzIS.pgp Description: PGP signature
Re: svn commit: r205444 - head/sys/i386/i386
On Tue, Mar 23, 2010 at 08:21:31PM +0100, Ed Schouten wrote: * Ed Maste ema...@freebsd.org wrote: I was just about to follow up with a comment to that effect. We do want it to become a panic, but I would prefer to hold off until we address the known issue with padlock(4). I have seen this message appear when using the ndisulator as well. How are we going to solve it in this case? Could the ndisulator be extended to prepare a FPU context using kib's new API? I looked at http://msdn.microsoft.com/en-us/library/aa489566.aspx after someone mentioned ndisulator. It seems that windows requires that i386 drivers carefully use braces for use of FPU, while amd64 code allowed to use it freely. That suggests that windows clears TS on kernel mode entry or driver calls, that seems to be too wastefull. I would very much appreciate the help with changing both ndis and padlock to use fpu_kern_enter/leave KPI, since I do not use them. I need some time to polish the patch before. pgpKkrShSR5RW.pgp Description: PGP signature
Re: svn commit: r205444 - head/sys/i386/i386
On 3/23/10, Kostik Belousov kostik...@gmail.com wrote: On Tue, Mar 23, 2010 at 08:21:31PM +0100, Ed Schouten wrote: * Ed Maste ema...@freebsd.org wrote: I was just about to follow up with a comment to that effect. We do want it to become a panic, but I would prefer to hold off until we address the known issue with padlock(4). I have seen this message appear when using the ndisulator as well. How are we going to solve it in this case? Could the ndisulator be extended to prepare a FPU context using kib's new API? I looked at http://msdn.microsoft.com/en-us/library/aa489566.aspx after someone mentioned ndisulator. It seems that windows requires that i386 drivers carefully use braces for use of FPU, while amd64 code allowed to use it freely. That suggests that windows clears TS on kernel mode entry or driver calls, that seems to be too wastefull. I would very much appreciate the help with changing both ndis and padlock to use fpu_kern_enter/leave KPI, since I do not use them. I need some time to polish the patch before. I saw fpudna only on amd64, but I never managed to get ndisulator fully working on amd64 (at least with broadcom card/driver). ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r205444 - head/sys/i386/i386
On Tue, Mar 23, 2010 at 09:35:09PM +0100, Paul B Mahol wrote: On 3/23/10, Kostik Belousov kostik...@gmail.com wrote: On Tue, Mar 23, 2010 at 08:21:31PM +0100, Ed Schouten wrote: * Ed Maste ema...@freebsd.org wrote: I was just about to follow up with a comment to that effect. We do want it to become a panic, but I would prefer to hold off until we address the known issue with padlock(4). I have seen this message appear when using the ndisulator as well. How are we going to solve it in this case? Could the ndisulator be extended to prepare a FPU context using kib's new API? I looked at http://msdn.microsoft.com/en-us/library/aa489566.aspx after someone mentioned ndisulator. It seems that windows requires that i386 drivers carefully use braces for use of FPU, while amd64 code allowed to use it freely. That suggests that windows clears TS on kernel mode entry or driver calls, that seems to be too wastefull. I would very much appreciate the help with changing both ndis and padlock to use fpu_kern_enter/leave KPI, since I do not use them. I need some time to polish the patch before. I saw fpudna only on amd64, but I never managed to get ndisulator fully working on amd64 (at least with broadcom card/driver). I cannot find KeSaveFloatingPointState symbol defined by ndisulator. Could it be that it is a macro or inline function that expands to proper assembly for i386, and nop on amd64 ? That would explain your observation. pgpiRjI8MLMJj.pgp Description: PGP signature
Re: svn commit: r205444 - head/sys/i386/i386
On 3/23/10, Kostik Belousov kostik...@gmail.com wrote: On Tue, Mar 23, 2010 at 09:35:09PM +0100, Paul B Mahol wrote: On 3/23/10, Kostik Belousov kostik...@gmail.com wrote: On Tue, Mar 23, 2010 at 08:21:31PM +0100, Ed Schouten wrote: * Ed Maste ema...@freebsd.org wrote: I was just about to follow up with a comment to that effect. We do want it to become a panic, but I would prefer to hold off until we address the known issue with padlock(4). I have seen this message appear when using the ndisulator as well. How are we going to solve it in this case? Could the ndisulator be extended to prepare a FPU context using kib's new API? I looked at http://msdn.microsoft.com/en-us/library/aa489566.aspx after someone mentioned ndisulator. It seems that windows requires that i386 drivers carefully use braces for use of FPU, while amd64 code allowed to use it freely. That suggests that windows clears TS on kernel mode entry or driver calls, that seems to be too wastefull. I would very much appreciate the help with changing both ndis and padlock to use fpu_kern_enter/leave KPI, since I do not use them. I need some time to polish the patch before. I saw fpudna only on amd64, but I never managed to get ndisulator fully working on amd64 (at least with broadcom card/driver). I cannot find KeSaveFloatingPointState symbol defined by ndisulator. Could it be that it is a macro or inline function that expands to proper assembly for i386, and nop on amd64 ? That would explain your observation. I have never found any driver that reports such symbol missing when loaded. ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
svn commit: r205444 - head/sys/i386/i386
Author: emaste Date: Mon Mar 22 11:52:53 2010 New Revision: 205444 URL: http://svn.freebsd.org/changeset/base/205444 Log: Merge r197455 from amd64: Add a backtrace to the fpudna in kernel mode! case, to help track down where this comes from. Reviewed by:bde Modified: head/sys/i386/i386/trap.c Modified: head/sys/i386/i386/trap.c == --- head/sys/i386/i386/trap.c Mon Mar 22 11:32:19 2010(r205443) +++ head/sys/i386/i386/trap.c Mon Mar 22 11:52:53 2010(r205444) @@ -540,6 +540,10 @@ trap(struct trapframe *frame) * XXX this should be fatal unless the kernel has * registered such use. */ + printf(npxdna in kernel mode!\n); +#ifdef KDB + kdb_backtrace(); +#endif if (npxdna()) goto out; #endif ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r205444 - head/sys/i386/i386
On Monday 22 March 2010 7:52:54 am Ed Maste wrote: Author: emaste Date: Mon Mar 22 11:52:53 2010 New Revision: 205444 URL: http://svn.freebsd.org/changeset/base/205444 Log: Merge r197455 from amd64: Add a backtrace to the fpudna in kernel mode! case, to help track down where this comes from. Reviewed by: bde Should we make this a panic instead perhaps? -- John Baldwin ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r205444 - head/sys/i386/i386
On Mon, Mar 22, 2010 at 08:49:36AM -0400, John Baldwin wrote: On Monday 22 March 2010 7:52:54 am Ed Maste wrote: Author: emaste Date: Mon Mar 22 11:52:53 2010 New Revision: 205444 URL: http://svn.freebsd.org/changeset/base/205444 Log: Merge r197455 from amd64: Add a backtrace to the fpudna in kernel mode! case, to help track down where this comes from. Reviewed by:bde Should we make this a panic instead perhaps? I was just about to follow up with a comment to that effect. We do want it to become a panic, but I would prefer to hold off until we address the known issue with padlock(4). http://www.freebsd.org/cgi/query-pr.cgi?pr=amd64/135014 Bruce Evans' comment in that PR is: The printf should always have been a panic, but changing to a panic now would be too drastic. -Ed ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
