Re: bhyve regression ?
On 20. 1. 8., mike tancsa wrote: > On 1/8/2020 10:15 AM, mike tancsa wrote: >> Going from a kernel from Dec 21st to today, my bhyve image no longer >> starts up. Is this possibly related to the mfc 356471 ? >> >> > OK, confirmed. Doing a svnlite update -r356469, to just before the ACPI > MFC allows be to start up my bhyve image. I forgot to merge r354056. Please update your source (r356500) and try again. Sorry for the breakage. Jung-uk Kim ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: /dev/crypto not being used in 12-STABLE
On 18. 12. 7., Jung-uk Kim wrote: > On 18. 12. 7., Jeremy Chadwick wrote: >> https://github.com/openssl/openssl/pull/3744/files#diff-e4eb329834da3d36278b1b7d943b3bc9 >> >> *) Add devcrypto engine. This has been implemented against >> cryptodev-linux, >> then adjusted to work on FreeBSD 8.4 as well. >> Enable by configuring with 'enable-devcryptoeng'. This is done by >> default >> on BSD implementations, as cryptodev.h is assumed to exist on all of >> them. >> [Richard Levitte] >> >> Is this message incorrect/false? > > Yes, it is incorrect. It turned out to be a bug in the Configure script. Now it is enabled by default on head (r342009). Please see the commit log for more info. https://svnweb.freebsd.org/changeset/base/342009 Jung-uk Kim signature.asc Description: OpenPGP digital signature
Re: /dev/crypto not being used in 12-STABLE
On 18. 12. 7., Jeremy Chadwick wrote: > On Fri, Dec 07, 2018 at 06:38:04PM -0500, Jung-uk Kim wrote: >> On 18. 12. 6., Jeremy Chadwick wrote: >>> I'm not subscribed to -stable. >>> >>> This is in response to jkim@'s messages here: >>> >>> https://lists.freebsd.org/pipermail/freebsd-stable/2018-December/090202.html >>> https://lists.freebsd.org/pipermail/freebsd-stable/2018-December/090202.html >>> >>> Based on what I can tell, OpenSSL 1.1.1 or thereabouts removed the >>> cryptodev OpenSSL engine, which was a tie-in to BSD's cryptodev(4), >>> which is accessed via /dev/crypto and related crypto(4) ioctls. >>> >>> Instead, they offered a replacement engine called devcrypto (what an >>> awful name), with the primary focus being against something from Linux >>> called cryptodev-linux, then was made to work on FreeBSD 8.4. This code >>> was as of June 2017; 8.4 was EOL'd August 2015. Interesting. >>> >>> https://github.com/openssl/openssl/commit/4f79aff is not "add support >>> for BSD" at all. It's "tweak further stuff for BSD", probably to get it >>> to work on newer FreeBSD; they seem to care about crypto/cryptodev.h >>> details. I asked myself: why do they care about that if they're doing >>> it all themselves? Looking at the code sheds light on that. The actual >>> devcrypto engine commits that added BSD support are here: >>> >>> https://github.com/openssl/openssl/pull/3744 >>> https://github.com/openssl/openssl/pull/3744/files >>> >>> The commits indicate that the devcrypto is enabled by default on >>> FreeBSD. But we can tell from Herbert's post and jkim@'s patch that's >>> not true at all, i.e. FreeBSD disables it. Why? And is that a good >>> default? >> >> Why do you think it is enabled by default? >> >> https://github.com/openssl/openssl/blob/619eb33/Configure#L428 > > Because of this commit to OpenSSL's CHANGES file, which is part of what > I linked above; last sentence: > > https://github.com/openssl/openssl/pull/3744/files#diff-e4eb329834da3d36278b1b7d943b3bc9 > > *) Add devcrypto engine. This has been implemented against cryptodev-linux, > then adjusted to work on FreeBSD 8.4 as well. > Enable by configuring with 'enable-devcryptoeng'. This is done by > default > on BSD implementations, as cryptodev.h is assumed to exist on all of > them. > [Richard Levitte] > > Is this message incorrect/false? Yes, it is incorrect. > While I can read the perl code that is > the Configure script just fine, the CHANGES entry makes me think there > may be "other pieces" that affect the value of the key in that hash > (e.g. some script that uses uname detection and calls Configure with > argument). Are there? There is config script but it does not change the configuration. >> Note crypto(4) was imported from OpenBSD. Since OpenBSD 4.9, it was >> disabled by default. >> >> https://www.openbsd.org/plus49.html >> >> Then, they killed it in 5.7. >> >> https://www.openbsd.org/plus57.html >> >> o Unlinked the crypto(4) pseudo device (disabled by default for about 4 >> years). >> >> Now FreeBSD is the only major BSD with /dev/crypto. That's why new >> engine was not thoroughly tested. > > Thanks for the information. > > So this implies there is a desire to get rid of cryptodev(4) (which is > the /dev/crypto endpoint), at least on OpenBSD. Yes. > Apologies if this is off-topic, but: is "device cryptodev" something > that should be removed from one's kernel config (due to what sounds like > desired deprecation), while keeping "device crypto" (to ensure userland > applications that use libcrypto/crypto(4) functions can still get at > crypto(9))? I have no desire to deprecate cryptodev(4) from FreeBSD. I only disabled it for OpenSSL 1.1.1 because it was the default configuration. >>> Here's why I ask: >>> >>> The new devcrypto engine most definitely utilises /dev/crypto (thus >>> cryptodev(4) and crypto(4)). cipher_init(), prepare_cipher_methods(), >>> digest_init(), and prepare_digest_methods() all utilise that interface: >>> >>> https://github.com/openssl/openssl/pull/3744/files#diff-027f92eb0a10c0986aec873d9fd1ab66 >>> >>> So while OpenSSL now uses more of its own native C and assembly code >>> (e.g. for AES-NI support), and that's certainly faster than all the >>> overhead that cryptodev(4) brings with it (see jhb@'s post), I wonder: >>> &g
Re: /dev/crypto not being used in 12-STABLE
On 18. 12. 6., Jeremy Chadwick wrote: > I'm not subscribed to -stable. > > This is in response to jkim@'s messages here: > > https://lists.freebsd.org/pipermail/freebsd-stable/2018-December/090202.html > https://lists.freebsd.org/pipermail/freebsd-stable/2018-December/090202.html > > Based on what I can tell, OpenSSL 1.1.1 or thereabouts removed the > cryptodev OpenSSL engine, which was a tie-in to BSD's cryptodev(4), > which is accessed via /dev/crypto and related crypto(4) ioctls. > > Instead, they offered a replacement engine called devcrypto (what an > awful name), with the primary focus being against something from Linux > called cryptodev-linux, then was made to work on FreeBSD 8.4. This code > was as of June 2017; 8.4 was EOL'd August 2015. Interesting. > > https://github.com/openssl/openssl/commit/4f79aff is not "add support > for BSD" at all. It's "tweak further stuff for BSD", probably to get it > to work on newer FreeBSD; they seem to care about crypto/cryptodev.h > details. I asked myself: why do they care about that if they're doing > it all themselves? Looking at the code sheds light on that. The actual > devcrypto engine commits that added BSD support are here: > > https://github.com/openssl/openssl/pull/3744 > https://github.com/openssl/openssl/pull/3744/files > > The commits indicate that the devcrypto is enabled by default on > FreeBSD. But we can tell from Herbert's post and jkim@'s patch that's > not true at all, i.e. FreeBSD disables it. Why? And is that a good > default? Why do you think it is enabled by default? https://github.com/openssl/openssl/blob/619eb33/Configure#L428 Note crypto(4) was imported from OpenBSD. Since OpenBSD 4.9, it was disabled by default. https://www.openbsd.org/plus49.html Then, they killed it in 5.7. https://www.openbsd.org/plus57.html o Unlinked the crypto(4) pseudo device (disabled by default for about 4 years). Now FreeBSD is the only major BSD with /dev/crypto. That's why new engine was not thoroughly tested. > Here's why I ask: > > The new devcrypto engine most definitely utilises /dev/crypto (thus > cryptodev(4) and crypto(4)). cipher_init(), prepare_cipher_methods(), > digest_init(), and prepare_digest_methods() all utilise that interface: > > https://github.com/openssl/openssl/pull/3744/files#diff-027f92eb0a10c0986aec873d9fd1ab66 > > So while OpenSSL now uses more of its own native C and assembly code > (e.g. for AES-NI support), and that's certainly faster than all the > overhead that cryptodev(4) brings with it (see jhb@'s post), I wonder: > > 1. What happens to people using crypto hardware accelerators, ex. > hifn(4), padlock(4), ubsec(4), and safe(4)? How exactly would OpenSSL > utilise these H/W accelerators if the devcrypto engine is disabled? padlock has a dynamic engine, i.e., /usr/lib/engines/padlock.so. I believe glxsb, hifn(4), safe(4), and ubsec(4) users are very rare nowadays. If we have significant number of users and they show reasonable performance, then I will reconsider my decision. > 2. If the devcrypto engine is *enabled*, and people have aesni(4) > loaded alongside cryptodev(4), which gets priority: OpenSSL's native > AES-NI code or cryptodev(4)/aesni(4)? I believe jhb@ answered this question already. > Likewise: if the decrypto engine is to remain disabled as a default: > this needs to be made crystal clear in Release Notes, so that folks > using H/W accelerators know they'll no longer benefit from those cards > unless they use a patch (third-party so/module won't work, AFAIT, as > OpenSSL's dynamic engine loading is unavailable per openssl engine -t). > Might I suggest enabling devcrypto be capable via src.conf, ex. > WITH_OPENSSL_ENGINE_DEVCRYPTO=true? Actually, dynamic engines work as expected[1]. % openssl version OpenSSL 1.1.1a-freebsd 20 Nov 2018 % cat silly-engine.c ... % cc -fPIC -o silly-engine.o -c silly-engine.c % cc -shared -o silly-engine.so -lcrypto silly-engine.o % openssl engine -t -c `pwd`/silly-engine.so (/home/jkim/silly-engine.so) A silly engine for demonstration purposes Loaded: (silly) A silly engine for demonstration purposes [ available ] Jung-uk Kim 1. https://www.openssl.org/blog/blog/2015/10/08/engine-building-lesson-1-a-minimum-useless-engine/ signature.asc Description: OpenPGP digital signature
Re: /dev/crypto not being used in 12-STABLE
On 18. 12. 6., Jung-uk Kim wrote:
> On 18. 12. 6., John Nielsen wrote:
>>> On Dec 6, 2018, at 4:04 PM, Xin LI wrote:
>>>
>>> On Thu, Dec 6, 2018 at 11:37 AM John Nielsen wrote:
>>>>
>>>> I have upgraded two physical machines from 11-STABLE to 12-STABLE recently
>>>> (one is 12.0-PRERELEASE r341380 and the other is 12.0-PRERELEASE r341391).
>>>> I noticed today that neither machine seems to be utilizing /dev/crypto.
>>>> Typically I see at least ssh/sshd have the device open plus some programs
>>>> from ports. But 'fuser' doesn't list any processes on either machine:
>>>>
>>>> # fuser /dev/crypto
>>>> /dev/crypto:
>>>>
>>>> Both machines are running custom kernels that include "device crypto" and
>>>> "device cryptodev". One of them additionally has "device aesni".
>>>>
>>>> Is anyone else seeing this? Any idea what would cause it?
>>>
>>> Your average OpenSSL applications should not use /dev/crypto, if your
>>> goal is to utilize AES-NI (which does not require /dev/crypto). On
>>> capable systems, AES-NI would be used automatically (and it's faster
>>> this way).
>>
>> Thanks for the response. Is there a way to verify that AES-NI is being used
>> for e.g. ssh?
>> I'm also curious why/when/how the change to not use (or support?)
>> /dev/crypto from base
>> openssl was made.
>
> OpenSSL 1.1.1 removed the old cryptodev:
>
> https://svnweb.freebsd.org/base/vendor-crypto/openssl/dist/CHANGES?revision=340690=markup#l400
>
> Instead, OpenSSL added devcrypto engine for Linux:
>
> https://github.com/openssl/openssl/commit/619eb33
>
> and added BSD support:
>
> https://github.com/openssl/openssl/commit/4f79aff
>
> then, completely removed BSD-specific cryptodev:
>
> https://github.com/openssl/openssl/commit/f39a550
>
> However, it is disabled by default. Theoretically, it is functionally
> equivalent but it wasn't tested much.
>
> I can enable the new engine on head if many users request it.
FYI, the attached patch should enable the new engine.
Jung-uk Kim
Index: secure/lib/libcrypto/Makefile
===
--- secure/lib/libcrypto/Makefile (revision 341666)
+++ secure/lib/libcrypto/Makefile (working copy)
@@ -192,8 +192,8 @@ SRCS+= ecp_nistz256-x86.S ecp_nistz256.c
.endif
# engine
-SRCS+= eng_all.c eng_cnf.c eng_ctrl.c eng_dyn.c eng_err.c eng_fat.c
-SRCS+= eng_init.c eng_lib.c eng_list.c eng_openssl.c eng_pkey.c
+SRCS+= eng_all.c eng_cnf.c eng_ctrl.c eng_devcrypto.c eng_dyn.c eng_err.c
+SRCS+= eng_fat.c eng_init.c eng_lib.c eng_list.c eng_openssl.c eng_pkey.c
SRCS+= eng_rdrand.c eng_table.c tb_asnmth.c tb_cipher.c tb_dh.c tb_digest.c
SRCS+= tb_dsa.c tb_eckey.c tb_pkmeth.c tb_rand.c tb_rsa.c
Index: secure/lib/libcrypto/opensslconf.h.in
===
--- secure/lib/libcrypto/opensslconf.h.in (revision 341666)
+++ secure/lib/libcrypto/opensslconf.h.in (working copy)
@@ -46,9 +46,6 @@ extern "C" {
#ifndef OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE
# define OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE
#endif
-#ifndef OPENSSL_NO_DEVCRYPTOENG
-# define OPENSSL_NO_DEVCRYPTOENG
-#endif
#ifndef OPENSSL_NO_EC_NISTP_64_GCC_128
# define OPENSSL_NO_EC_NISTP_64_GCC_128
#endif
signature.asc
Description: OpenPGP digital signature
Re: /dev/crypto not being used in 12-STABLE
On 18. 12. 6., John Nielsen wrote: >> On Dec 6, 2018, at 4:04 PM, Xin LI wrote: >> >> On Thu, Dec 6, 2018 at 11:37 AM John Nielsen wrote: >>> >>> I have upgraded two physical machines from 11-STABLE to 12-STABLE recently >>> (one is 12.0-PRERELEASE r341380 and the other is 12.0-PRERELEASE r341391). >>> I noticed today that neither machine seems to be utilizing /dev/crypto. >>> Typically I see at least ssh/sshd have the device open plus some programs >>> from ports. But 'fuser' doesn't list any processes on either machine: >>> >>> # fuser /dev/crypto >>> /dev/crypto: >>> >>> Both machines are running custom kernels that include "device crypto" and >>> "device cryptodev". One of them additionally has "device aesni". >>> >>> Is anyone else seeing this? Any idea what would cause it? >> >> Your average OpenSSL applications should not use /dev/crypto, if your >> goal is to utilize AES-NI (which does not require /dev/crypto). On >> capable systems, AES-NI would be used automatically (and it's faster >> this way). > > Thanks for the response. Is there a way to verify that AES-NI is being used > for e.g. ssh? > I'm also curious why/when/how the change to not use (or support?) /dev/crypto > from base > openssl was made. OpenSSL 1.1.1 removed the old cryptodev: https://svnweb.freebsd.org/base/vendor-crypto/openssl/dist/CHANGES?revision=340690=markup#l400 Instead, OpenSSL added devcrypto engine for Linux: https://github.com/openssl/openssl/commit/619eb33 and added BSD support: https://github.com/openssl/openssl/commit/4f79aff then, completely removed BSD-specific cryptodev: https://github.com/openssl/openssl/commit/f39a550 However, it is disabled by default. Theoretically, it is functionally equivalent but it wasn't tested much. I can enable the new engine on head if many users request it. Jung-uk Kim signature.asc Description: OpenPGP digital signature
Re: GCC + FreeBSD 11.0 Stable - stat.h does not have vm_ooffset_t definition
On 04/30/2017 08:06, Konstantin Belousov wrote: > On Sat, Apr 29, 2017 at 07:55:24PM +0200, Dimitry Andric wrote: >> On 29 Apr 2017, at 19:00, Gerald Pfeifer <ger...@pfeifer.com> wrote: >>> >>> On Thu, 27 Apr 2017, Jung-uk Kim wrote: >>>>>>>>> I found the problem, but I do not know how to resolve this. When you >>>>>>>>> install the GCC compiler from the PKG repository it appears to create >>>>>>>>> a >>>>>>>>> modified set of include files from the system (default?) include files >>>>>>>>> (/usr/include). However, when the modified /usr/include/sys/types.h >>>>>>>>> file is created, the typedef for vm_ooffset_t is modified, and there >>>>>>>>> is >>>>>>>>> no reference to __vm_ooffset_t that the compiler can resolve. >>>>>>>>> >>>>>>>>> < typedef __int64_t vm_ooffset_t; >>>>>>>>> --- >>>>>>>>>> typedef __vm_ooffset_t vm_ooffset_t; >>>>>>>> ... >>>>>>>> You have to rebuild lang/gcc from the ports tree to fix this problem. >>>>>>>> >>>>>>>> https://lists.freebsd.org/pipermail/freebsd-current/2017-February/064937.html >>>>>>> Does this mean that the GCC port/package needs to be updated? If so, >>>>>>> should I file a PR report on this issue? >>>>>>> I (temporarily) fixed this problem by hand editting the modified types.h >>>>>>> file and things seem to work. >>>>>> I already wrote a patch (attached). :-) >>>> If the maintainer (gerald) approves. CC'd. >>> >>> Thanks for bringing this to my attention. >>> >>> Can you please help me understand why this is necessary? >> >> This is because gcc's fixincludes process makes copies of certain system >> headers (in this case, /usr/include/sys/types.h) with slight >> modifications. Then, it places the directory containing the modified >> headers at the front of the include search path. So far so good. >> >> Now, whenever sys/types.h is updated, as happened with the vm_ooffset_t >> change, the header in gcc's own preferred directory might not match the >> definitions which are expected, leading to compilation errors. >> >> >>> If the >>> port/package is builts from scratch, does this trigger the problem? >> >> Yes, basically you need to rebuild all gcc ports from scratch, whenever >> you update any system header that matches gcc's list of files it wants >> to modify. >> >> But getting those errors in the first place can be very confusing to an >> end-user. And having to rebuild all those ports might be a burden. >> >> As some people pointed out, simply moving away or deleting the directory >> with fixed includes appears to work around the problems. So maybe the >> question is if gcc really needs to modify those headers at all? >> >> I have looked at gcc's build system a bit, but it does not seem very >> easy to disable the fixincludes step. I guess that is simply not >> supported. >> >> So in that case, if Jung-uk's solution works, it is probably the best >> way forward, and it can even be upstreamed. Jung-uk, how does your >> patch handle an updated header under /usr/include which contains e.g. >> new definitions, which are not in the fixed includes directory? > > Am I right that Jung-uk fix replaces vm_ooffset_t and vm_pindex_t with > explicit int64_t and uint64_t use, as the course of action for gcc > fixincludes step ? If yes, I completely disagree. > > The change blocks any future changes to the type that might occur in the > base system, for the code compiled by gcc. End result might be as bad > as mismatched ABI, in the worst case. Good point. > I share the opinion that fixincludes is not only useless, but really > damaging. Gcc ships workarounds for e.g. issues in X11 headers, which > application depends on the presence of the corresponding headers at the > gcc build time. For clean (poudriere-like) builds these fixes are never > applied, so port build results are inconsistent, at least. > > Nobody so far explained why fixincludes is needed for the modern base > headers. IMO if we have real problems in headers we ship, we must fix it > in the base. > > With all of the above, IMO most sane way to fix problems is to > rename fixincludes directory to some name which is ignored by gcc, > e.g. include-fixed -> include-fixed.saved. This can be done as > post-installation step in the ports. Agreed. Jung-uk Kim signature.asc Description: OpenPGP digital signature
Re: GCC + FreeBSD 11.0 Stable - stat.h does not have vm_ooffset_t definition
On 04/27/2017 19:07, Patrick Powell wrote: > On 04/27/17 13:59, Jung-uk Kim wrote: >> On 04/27/2017 12:45, Patrick Powell wrote: >>> On 04/26/17 09:34, Jung-uk Kim wrote: >>>> On 04/26/2017 10:14, Patrick Powell wrote: >>>>> First: a big thank-you to the support/fixit people for all of their work! >>>>> >>>>> I was doing some testing using FreeBSD 11.0-STABLE and some of my >>>>> configure scripts died. However, they were working fine on FreeBSD 11.0 >>>>> RELEASE. >>>>> >>>>> I found the problem, but I do not know how to resolve this. When you >>>>> install the GCC compiler from the PKG repository it appears to create a >>>>> modified set of include files from the system (default?) include files >>>>> (/usr/include). However, when the modified /usr/include/sys/types.h >>>>> file is created, the typedef for vm_ooffset_t is modified, and there is >>>>> no reference to __vm_ooffset_t that the compiler can resolve. >>>>> >>>>> < typedef __int64_t vm_ooffset_t; >>>>> --- >>>>>> typedef __vm_ooffset_t vm_ooffset_t; >>>> ... >>>> You have to rebuild lang/gcc from the ports tree to fix this problem. >>>> >>>> https://lists.freebsd.org/pipermail/freebsd-current/2017-February/064937.html >>>> >>>> Jung-uk Kim >>>> >>> Does this mean that the GCC port/package needs to be updated? If so, >>> should I file a PR report on this issue? >>> I (temporarily) fixed this problem by hand editting the modified types.h >>> file and things seem to work. >> I already wrote a patch (attached). :-) >> >> Jung-uk Kim > Will the GCC port be updated with this patch? If the maintainer (gerald) approves. CC'd. > Any action needed by me on this? No, thanks. :-) Jung-uk Kim signature.asc Description: OpenPGP digital signature
Re: GCC + FreeBSD 11.0 Stable - stat.h does not have vm_ooffset_t definition
On 04/27/2017 12:45, Patrick Powell wrote:
> On 04/26/17 09:34, Jung-uk Kim wrote:
>> On 04/26/2017 10:14, Patrick Powell wrote:
>>> First: a big thank-you to the support/fixit people for all of their work!
>>>
>>> I was doing some testing using FreeBSD 11.0-STABLE and some of my
>>> configure scripts died. However, they were working fine on FreeBSD 11.0
>>> RELEASE.
>>>
>>> I found the problem, but I do not know how to resolve this. When you
>>> install the GCC compiler from the PKG repository it appears to create a
>>> modified set of include files from the system (default?) include files
>>> (/usr/include). However, when the modified /usr/include/sys/types.h
>>> file is created, the typedef for vm_ooffset_t is modified, and there is
>>> no reference to __vm_ooffset_t that the compiler can resolve.
>>>
>>> < typedef __int64_t vm_ooffset_t;
>>> ---
>>>> typedef __vm_ooffset_t vm_ooffset_t;
>> ...
>> You have to rebuild lang/gcc from the ports tree to fix this problem.
>>
>> https://lists.freebsd.org/pipermail/freebsd-current/2017-February/064937.html
>>
>> Jung-uk Kim
>>
> Does this mean that the GCC port/package needs to be updated? If so,
> should I file a PR report on this issue?
> I (temporarily) fixed this problem by hand editting the modified types.h
> file and things seem to work.
I already wrote a patch (attached). :-)
Jung-uk Kim
Index: lang/gcc/files/patch-fixincludes_fixincl.x
===
--- lang/gcc/files/patch-fixincludes_fixincl.x (nonexistent)
+++ lang/gcc/files/patch-fixincludes_fixincl.x (working copy)
@@ -0,0 +1,78 @@
+--- fixincludes/fixincl.x.orig 2016-02-01 20:25:12 UTC
fixincludes/fixincl.x
+@@ -15,7 +15,7 @@
+ * certain ANSI-incompatible system header files which are fixed to work
+ * correctly with ANSI C and placed in a directory that GNU C will search.
+ *
+- * This file contains 231 fixup descriptions.
++ * This file contains 232 fixup descriptions.
+ *
+ * See README for more information.
+ *
+@@ -9480,14 +9480,43 @@ static const char* apzX11_SprintfPatch[] = {
+ #endif /* !defined __STDC__ */",
+ (char*)NULL };
+
++/* * * * * * * * * * * * * * * * * * * * * * * * * *
++ *
++ * Description of Freebsd_Sys_Types fix
++ */
++tSCC zFreebsd_Sys_TypesName[] =
++ "freebsd_sys_types";
+
++/*
++ * File name selection pattern
++ */
++tSCC zFreebsd_Sys_TypesList[] =
++ "sys/types.h\0";
++/*
++ * Machine/OS name selection pattern
++ */
++tSCC* apzFreebsd_Sys_TypesMachs[] = {
++"*-*-freebsd*",
++(const char*)NULL };
++#define FREEBSD_SYS_TYPES_TEST_CT 0
++#define aFreebsd_Sys_TypesTests (tTestDesc*)NULL
++
++/*
++ * Fix Command Arguments for Freebsd_Sys_Types
++ */
++static const char* apzFreebsd_Sys_TypesPatch[] = { sed_cmd_z,
++"-e", "s/^typedef\t__vm_ooffset_t\t/typedef\t__int64_t\t/",
++"-e", "s/^typedef\t__vm_pindex_t\t/typedef\t__uint64_t\t/",
++(char*)NULL };
++
++
+ /* * * * * * * * * * * * * * * * * * * * * * * * * *
+ *
+ * List of all fixes
+ */
+ #define REGEX_COUNT 268
+ #define MACH_LIST_SIZE_LIMIT 187
+-#define FIX_COUNT231
++#define FIX_COUNT232
+
+ /*
+ * Enumerate the fixes
+@@ -9723,7 +9752,8 @@ typedef enum {
+ X11_CLASS_FIXIDX,
+ X11_CLASS_USAGE_FIXIDX,
+ X11_NEW_FIXIDX,
+-X11_SPRINTF_FIXIDX
++X11_SPRINTF_FIXIDX,
++FREEBSD_SYS_TYPES_FIXIDX
+ } t_fixinc_idx;
+
+ tFixDesc fixDescList[ FIX_COUNT ] = {
+@@ -10880,5 +10910,10 @@ tFixDesc fixDescList[ FIX_COUNT ] = {
+ { zX11_SprintfName,zX11_SprintfList,
+ apzX11_SprintfMachs,
+ X11_SPRINTF_TEST_CT, FD_MACH_ONLY | FD_SUBROUTINE,
+- aX11_SprintfTests, apzX11_SprintfPatch, 0 }
++ aX11_SprintfTests, apzX11_SprintfPatch, 0 },
++
++ { zFreebsd_Sys_TypesName,zFreebsd_Sys_TypesList,
++ apzFreebsd_Sys_TypesMachs,
++ FREEBSD_SYS_TYPES_TEST_CT, FD_MACH_ONLY,
++ aFreebsd_Sys_TypesTests, apzFreebsd_Sys_TypesPatch, 0 }
+ };
Property changes on: lang/gcc/files/patch-fixincludes_fixincl.x
___
Added: fbsd:nokeywords
## -0,0 +1 ##
+yes
\ No newline at end of property
Added: svn:eol-style
## -0,0 +1 ##
+native
\ No newline at end of property
Added: svn:mime-type
## -0,0 +1 ##
+text/plain
\ No newline at end of property
signature.asc
Description: OpenPGP digital signature
Re: GCC + FreeBSD 11.0 Stable - stat.h does not have vm_ooffset_t definition
On 04/26/2017 10:14, Patrick Powell wrote: > First: a big thank-you to the support/fixit people for all of their work! > > I was doing some testing using FreeBSD 11.0-STABLE and some of my > configure scripts died. However, they were working fine on FreeBSD 11.0 > RELEASE. > > I found the problem, but I do not know how to resolve this. When you > install the GCC compiler from the PKG repository it appears to create a > modified set of include files from the system (default?) include files > (/usr/include). However, when the modified /usr/include/sys/types.h > file is created, the typedef for vm_ooffset_t is modified, and there is > no reference to __vm_ooffset_t that the compiler can resolve. > > < typedef __int64_t vm_ooffset_t; > --- >> typedef __vm_ooffset_t vm_ooffset_t; ... You have to rebuild lang/gcc from the ports tree to fix this problem. https://lists.freebsd.org/pipermail/freebsd-current/2017-February/064937.html Jung-uk Kim signature.asc Description: OpenPGP digital signature
Re: stable/11 Problems with Unicode character and ls(1) sorting
On 07/15/16 09:55 AM, Thomas Eberhardt wrote: > % uname -a > FreeBSD clarence.ocp.lan 11.0-BETA1 FreeBSD 11.0-BETA1 #0 r302457: Sat Jul 9 > 10:41:40 CEST 2016 tho...@clarence.ocp.lan:/usr/obj/usr/src/sys/GENERIC > amd64 > > % locale > LANG=en_US.UTF-8 > LC_CTYPE="en_US.UTF-8" > LC_COLLATE="en_US.UTF-8" > LC_TIME="en_US.UTF-8" > LC_NUMERIC="en_US.UTF-8" > LC_MONETARY="en_US.UTF-8" > LC_MESSAGES="en_US.UTF-8" > LC_ALL= > > % mkdir x > % touch x/Æon1 > % ls x > Æon1 > % touch x/Æon2 > % ls -f x > . ..Æon1 Æon2 > % ls -f x | hd > 2e 0a 2e 2e 0a c3 86 6f 6e 31 0a c3 86 6f 6e 32 |...on1...on2| > 0010 0a|.| > 0011 > % ls x > [hangs and consumes 100% CPU] > ^C > > % gdb /bin/ls > […] > (gdb) run x > Starting program: /bin/ls x > [hangs] > ^C > Program received signal SIGINT, Interrupt. > 0x000800ffa9dd in _collate_lookup (table=, t= optimized out>, > len=, pri=, which= optimized out>, state=) > at /usr/src/lib/libc/locale/collate.c:340 > 340 *pri = table->char_pri_table[*t].pri[which]; > Current language: auto; currently minimal > (gdb) bt > #0 0x000800ffa9dd in _collate_lookup (table=, > t=, > len=, pri=, which= optimized out>, state=) > at /usr/src/lib/libc/locale/collate.c:340 > #1 0x000800fdc38a in wcscoll_l (ws1=, ws2= optimized out>, > locale=) at /usr/src/lib/libc/string/wcscoll.c:158 > #2 0x000800fd9071 in strcoll_l (s=, s2= optimized out>, locale=0x80124f338) > at /usr/src/lib/libc/string/strcoll.c:101 > #3 0x000800fee253 in qsort (a=, n= out>, es=, > cmp=0x800f28530 ) at /usr/src/lib/libc/stdlib/qsort.c:130 > #4 0x000800f27397 in fts_sort (sp=, head= optimized out>, nitems=) > at /usr/src/lib/libc/gen/fts.c:995 > #5 0x000800f2848e in fts_children (sp=, instr=Error > accessing memory address 0x2: Bad address. > ) at /usr/src/lib/libc/gen/fts.c:570 > #6 0x004030df in traverse (argc=, argv= optimized out>, > options=) at /usr/src/bin/ls/ls.c:576 > #7 0x00402eeb in main (argc=, argv= optimized out>) at /usr/src/bin/ls/ls.c:498 > #8 0x004020cf in _start () > #9 0x000800629000 in ?? () > #10 0x in ?? () > (gdb) br strcoll.c:101 > Breakpoint 1 at 0x800fd9063: file /usr/src/lib/libc/string/strcoll.c, line > 101. > (gdb) run > The program being debugged has been started already. > Start it from the beginning? (y or n) y > Starting program: /bin/ls x > […] > > Breakpoint 1, strcoll_l (s=, s2=, > locale=0x80124f338) > at /usr/src/lib/libc/string/strcoll.c:101 > 101 ret = wcscoll_l(w1, w2, locale); > (gdb) n > [wcscoll_l never returns] > > > Does anybody know what’s going on? This is on a ZFS filesystem if that > matters. Yes, it is a known problem and bapt is working on it. If you're in hurry, reverting r302324 will fix the regression for now. https://svnweb.freebsd.org/changeset/base/302324 FYI, this problem is tracked as PR211135. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211135 Jung-uk Kim signature.asc Description: OpenPGP digital signature
Re: FreeBSD_STABLE_10-i386 - Build #1167 - Failure
On 05/16/16 03:48 PM, jenkins-ad...@freebsd.org wrote: > FreeBSD_STABLE_10-i386 - Build #1167 - Failure: > > Build information: > https://jenkins.FreeBSD.org/job/FreeBSD_STABLE_10-i386/1167/ > Full change log: > https://jenkins.FreeBSD.org/job/FreeBSD_STABLE_10-i386/1167/changes > Full build log: > https://jenkins.FreeBSD.org/job/FreeBSD_STABLE_10-i386/1167/console ... Sorry, it's mine. I'm working on it. Jung-uk Kim signature.asc Description: OpenPGP digital signature
Re: RELENG_10 performance regression (was Re: 35-40% performance drop releng9 vs releng10 openvpn
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 03/21/2015 14:42, Konstantin Belousov wrote: It seems to be a consequnce of the code from r222869. The test_tsc() does not trust the P-state invariant report and explicitely check for the family. Your CPU family is 0x14, while code only bumps TSC priority for family 0x15+. We need to find out whether the Bobcat cores have well-synchronized TSCs. If it does, we can white-list it, too. However, I doubt it. Sorry for the late response, Jung-uk Kim -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJVEfKMAAoJEHyflib82/FGZUgH/RZ8LBBeW2ue+0SIJj8Er9Ni uyEA3KJL7ZmdjuGUtOdDl3s3cwHcTxbKN39rdabjOyJy/OoNnJK3GfL8UgYSpERa ztdHHNLbxJK9Z3iN7rvjXxQMHBJy3D4LIQ9BXFau3xcO7K8WDXqdHjUZx/ujrSpU WwDoZRFohvUf2FT1J23NfWBOx0Mnls3PrQm4f6YLhVst6RojDgx8XA24LyIm+AkF WUZcPttydp9nde1Hc7qyFI5qB3ZMhT1tG9jp+J2jQWeqCn/SPR3VymF+Lyz/T0sC POEa6NTJf4lWXOHRZ21Fdkrtr1hBltdO1FImX9M2iNlyRwz57UsNW6yJawGhYJA= =w6Hk -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Why can't gcc-4.2.1 build usable libreoffice?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-02-19 12:23:07 -0500, Adrian Chadd wrote: In any case, why hasn't that port been blessed with the requires gcc 4.6+ port option/dependency? I thought that's why we _have_ that. The short answer is we cannot support gcc 4.6+ unless we have a dedicated *ports* compiler. Okay, it seems to be a FAQ now and I'll try to explain as much as I can. If you have binaries compiled with g++ from ports tree, those binaries should not be linked with binaries that are compiled with the base compiler because they pull in different libstdc++ and friends and they have different ABIs. Also, some C++ libraries are very sensitive to standard C++ libraries, e.g., Boost. On top of that, UNO C++ bridge is really tightly coupled with C++ runtime. [1] Some libraries come with configuration headers and they are usually coupled with *build* environment, not *runtime* environment. So on and so forth. You see, that's why we had numerous build failure reports for LibreOffice in C++ unit tests. [2] Traditionally, OpenOffice.org builds everything from bundled libraries and headers so that it is almost self-contained. For example, STLport is used as a C++ STL library by default. This model makes perfect sense for a stand-alone downloadable package because the build environment may be very different from runtime environment. LO has kinda opposite philosophy, i.e., modular is better. This model works well if users are using prebuilt packages, i.e., Linux distros. [3] What do we go from here? I don't know. One thing I know for sure is we cannot support every possible build/runtime environment. Feel free to suggest your ideas and thoughts. Jung-uk Kim 1. http://wiki.openoffice.org/wiki/Uno 2. Most of them are actually legit but I gave up on explaining why and turned them off by default. If you had build failure before, now you may experience runtime failures instead, sorry. 3. We may go back to monolithic build model, perhaps. Not sure. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBAgAGBQJRI883AAoJECXpabHZMqHO+6gH/2uvg/KTlsHKuxGG1XGPjJct icKy/nsCJK9XkkNaA3O7Zkpiddb1y2TNf9WW+/NmttfsnZ2aMos1jBnfIBr9l+ny Gw8V09JXOtUj1Ew3QZRF0efXz0sB7C37jEEeJWgF6IB4spq+BLAriCKShsa8bh+p PTwbE+ooib5Pzyf9NWIHzATiykeC1pSHz+3lnRhpNv9TFawcHsGyOfJRmr37eefO jodUWXzbJivCMFteWBaZwUHJkWVfMq4h+sdUyui0dP+T1EULQPpafNNkFkPcHthA dZzFfYGKgUjqn7PfO4B8wK5wqb/mO1rxgQ7NPQMla30PCN6iy9mNCFnMaR/nrzw= =PgIy -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Why can't gcc-4.2.1 build usable libreoffice?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-02-19 14:31:02 -0500, Mikhail T. wrote: On 19.02.2013 14:15, Jung-uk Kim wrote: What do we go from here? I don't know. One thing I know for sure is we cannot support every possible build/runtime environment. Feel free to suggest your ideas and thoughts. Well, support for every possible combination is, of course, a toll order, but support for the base cc/c++ is a reasonable expectation, in my opinion... Actually, I tried very hard to build sane LO with gcc 4.2 but it wasn't fruitful. Eventually, I gave up on adding kludges after kludges because LO is moving away from pre-C++11 compilers anyway. :-( And if there is a *good* reason to reject the base compiler, I'd expect such good reason to be documented -- preferably with bug-reports filed against either the FreeBSD and its toolchain or against the LibreOffice code. Or both... I believe there were plenty PRs already. Jung-uk Kim -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBAgAGBQJRI9ZdAAoJECXpabHZMqHOetMH+gMVJvAdp9x8jSzqvZQoaw28 fXoyNunlPTMq5U1sBzL1ZURm1nPwSutlAp5dccd4oRWQUXZ5uf09vNP8hI02cXz6 xteVQXtPEYYbkk6ySlpUfCl/Xostr1vkzT1a52KwGK8VHZsV41SXZEEylbBmTRfx ikoSpwQGBo8M6IpdrI29cfUWriajMSqXGYqNMFsloGj7kJVY/WKSe1OGraPtQMwR Y61255VJ83tpYo7a0HGSAKEOXCGLNg8cvXNG3F7bz/rP9eikbIvx8CYYWFPQ8IrO gB7l1Nz4XL0Z5J9jUi/QZ+dl/gM/OthaKH05WkTimmJJvlBfxphWkrELgJUwmPM= =hTpo -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Why can't gcc-4.2.1 build usable libreoffice?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-02-19 15:05:13 -0500, Mikhail T. wrote: On 19.02.2013 14:45, Jung-uk Kim wrote: Actually, I tried very hard to build sane LO with gcc 4.2 but it wasn't fruitful. Eventually, I gave up on adding kludges after kludges because LO is moving away from pre-C++11 compilers anyway. :-( Should not a pre-C++11 compiler simply /fail/ upon encountering C++11 code? configure script detects the C++ compiler and sets various compiler flags. It basically tries to work around *known* issues as much as possible. However, it does not cover every possible combination. Moving away means not actively tested. And if there is a *good* reason to reject the base compiler, I'd expect such good reason to be documented -- preferably with bug-reports filed against either the FreeBSD and its toolchain or against the LibreOffice code. Or both... I believe there were plenty PRs already. I can not find any :-( The ones against FreeBSD http://www.freebsd.org/cgi/query-pr-summary.cgi?category=severity=priority=class=state=sort=nonetext=libreofficeresponsible=multitext=originator=release= all talk about build failures (except the 176269 http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/176269, filed today). There are no relevant bug-reports against LibreOffice, that mention gcc-4.2.1 https://bugassistant.libreoffice.org/buglist.cgi?quicksearch=gcc-4.2.1 or gcc 4.2.1 https://bugassistant.libreoffice.org/buglist.cgi?quicksearch=gcc%204.2.1. Okay, sorry. I really love to build LO with GCC 4.2, too. I really do. However, I don't see much point of mentioning that fact in PR. Jung-uk Kim -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBAgAGBQJRI/0TAAoJECXpabHZMqHOsy0IANi1KZSRdqARfxJ65r1MLi4a tQkCq7LmyMNA81ND1GKAatg52UDLF2GN5o9Yw71l/XiYN2JV667aGVaF9e96a789 ONnXRWaGw2DohTH8SpGu81Vstj5Vn/iots4b0bFdhz3HCW6lTgUsqlD/+n3dVVpo c4MlUAFtEhpqejvsX7g10kPqn8IZwZc7pBUfoeSw1sMIChajxmlfXDlHkvtKwVJu jHbu2PDMwty2kgJ1kRdYNt5yZXl9chSuSxqy23O5odfHyLWV6+SGk+SOb32MSp7H /oJ0UdFLFzqwGSqlK7bDOMIyL0yLaPz5WJd8X+HC/BmR5FUugdILe8lHOeJ/rq0= =ZyWD -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: acpidump -dt broken in 9 stable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2012-06-16 08:34:45 -0400, Konstantin Belousov wrote: On Fri, Jun 15, 2012 at 09:57:45PM -0700, mnln.l4 wrote: Just upgrade from 9.0 to 9 stable. `acpidump -dt` shows error message realpath tmp file: No such file or directory It is related to the recent change made to realpath(3) This was a bug/specific operation in acpidump relying on non-conforming realpath(3) behaviour. The r235948 should be merged. Committed as r237232. Thanks for letting me know. Jung-uk Kim -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/fZkUACgkQmlay1b9qnVPwUgCgr8mQhgFSd3+Se8PapbbAN71P 0jkAoLL5LKm8xTIRDk0VBVdghNFYMXL6 =CqQO -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: [stable 9] broken hwpstate calls
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2012-06-06 17:58:57 -0400, Andriy Gapon wrote:
on 31/05/2012 23:28 Jung-uk Kim said the following:
It is simple but I don't like locking scheduler, binding CPU, and
writing the same MSR, multiple times for each core.
Not sure if parse this. The MSR is _written_ /once/ for each
core. (BTW, locking scheduler is not a completely accurate
description of what thread_lock does)
I apologize. I didn't see the whole picture and read your patch wrong.
Any way, hwpstate still isn't quite right even without your patch.
sys/kern/kern_cpu.c
cpufreq_curr_sysctl() -
CPUFREQ_SET() -/* for all CPU devices */
cf_set_method() - /* thread_lock(), sched_bind(), ... */
CPUFREQ_DRV_SET() -
sys/x86/cpufreq/hwpstate.c
hwpstate_set() -
hwpstate_goto_pstate() /* for each CPU unit */
/* thread_lock(), sched_bind(), ... */
Therefore, sysctl dev.cpu.0.cpufreq=freq loops n^2 times (i.e., n
times per CPU) where n is number of CPUs. At least, it should check
unit == 0, e.g.,
hwpstate_goto_pstate(...)
{
...
if (unit == 0) {
/* XXX Is this really necessary? */
CPU_FOREACH(i) {
...
wrmsr(MSR_AMD_10H_11H_CONTROL, id);
...
}
}
/* Check the current P-state. */
for (...) {
...
msr = rdmsr(MSR_AMD_10H_11H_STATUS);
if (msr == id)
break;
...
}
/* XXX Maybe your patch here? */
...
}
Besides, it introduces more delay and you may be reading the
correct status because of that. :-P
Having a separate reading pass does introduce more delay indeed.
Reading the correct status is a good thing, OTOH.
That's what I said.
Why would anyone want to read incorrect status? (just want to note
that correct and expected are different things)
Okay, okay.
If people really think checking MSRC001_0071[18:16] is unworthy
for
Well, other people hasn't demonstrated/proved/convinced yet that
it is worthy
Bulldozer, I prefer skipping status check
That's what I suggested from the very start.
Buy me a Bulldozer and I'll fix it for you! :-P
but I disagree with this patch.
Since I am not invested in this issue (I am not affected by the
problem and I do not have any personal attachment to the code in
question), I will just defer any decision to those who do care
about the problem. I hope that a fix will be provided in the end.
Same here.
Jung-uk Kim
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk/P4XgACgkQmlay1b9qnVP8cgCgl9sAzyE956YjB2B3bK0wvOHu
n64Anih7sdWYQgflQVHuUGstdk05Fs9i
=2dS0
-END PGP SIGNATURE-
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: [stable 9] broken hwpstate calls
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2012-05-26 05:34:25 -0400, Andriy Gapon wrote: on 26/05/2012 10:02 Yamagi Burmeister said the following: On Fri, 25 May 2012 16:05:56 -0400 Jung-uk Kim j...@freebsd.org wrote: if we decide so, then I think that we could still keep the things simple. As we currently use the wholesale approach (all CPUs are set to the same P-state regardless of topology), then we could first make a pass of writing the MSR on all processors with a new P-state value and then make another pass of checking via MSR C001_0063 that the P-state is acquired. No, I believe checking MSRC001_0071[18:16] is much simpler if it works. And it does not break current cpufreq(4) design principles. Okay, thank's for your input. I'll come up with a patch. But it won't happen until tuesday or wednesday next week. I believe the approach that I suggested to be so trivial to implement (and also correct) that here is a patch: ... It is simple but I don't like locking scheduler, binding CPU, and writing the same MSR, multiple times for each core. Besides, it introduces more delay and you may be reading the correct status because of that. :-P If people really think checking MSRC001_0071[18:16] is unworthy for Bulldozer, I prefer skipping status check but I disagree with this patch. Thanks, Jung-uk Kim -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/H1GQACgkQmlay1b9qnVM+RQCfaYl6LpyARoO2oiyimwrWrhXD BPoAoIna4GHZKlsCRaXV3jqH8ujpzur5 =NYS0 -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: [stable 9] broken hwpstate calls
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2012-05-25 11:47:53 -0400, Andriy Gapon wrote: on 25/05/2012 17:36 Yamagi Burmeister said the following: Hello, a user at BSDForen.de had the same problem and I helped him to track it down. While I was unable to find a solution I found the cause of the problems. The problem is (all files and line numbers relative to FreeBSD 9.0-RELEASE): 1. When a new p-state is requested (by powerd or by changing the sysctl) in kern/kern_cpu.c the function cf_set_method() is invoked. 2. In line 335 the driver depended function is called. For newer AMD CPU it's hwpstate_set() in x86/cpufreq/hwpstate.c 3. In x86/cpufreq/hwpstate.c line 227 hwpstate_goto_pstate() is called which does the actual magic. 4. In line 199 if (msr != id) triggers, returns ENXIO. The error is send back to cf_set_method(), which prints the hwpstate0: set freq failed. powerd translates the error to Device not configured After some further investigation and looking at the linux driver [0] I changed the loop at x86/cpufreq/hwpstate.c 188ff from 100 iterations to 250. It lessend the problem but didn't solve it. The next step was to rewrite the logic between line 183 and 203 and adding a lot of debug printf. The patch (non style(9) compliant) is attached. With the new logic every 100 usec the new p-state is set again, until it's accepted. After 100 tries ENXIO is returned. This lessend the problem even more and showed that - On an old Phenom II X4 940 (K10 / Deneb) the new p-state is always accepted at the first try. At a test run for about 3 hours there was not a single failure. - On the Bulldozer CPU in about 9 in 10 times the new p-state is accepted at the first try. At most other times the new p-state is accepted after 1 to 10 tries. And there is a ~0,25% chance that the new p-state is never accepted, leading to hwpstate0: set freq failed. At the next call to cf_set_method() (about 500ms to 1s later) the new p-state it's most likely set successfull. This can be seen at the log (full log attached): # First call, failed after 102 iterations hwpstate0: MSR: 0 ID: 1 hwpstate0: Setting failed! hwpstate0: Iterations: 102 # Second call, successfull hwpstate0: setting P1-state on cpu1 hwpstate0: MSR: 1 ID: 1 hwpstate0: Iterations: 1 So the big question is: Why is the new p-state sometimes not accepted? And why does this only happen on Bulldozer CPUs and not at the old K10 (Barcelona, Deneb), etc? Reading the BIOS and kernel developer guide for Bulldozer didn't show anything, but I may have overlooked it. One solution may be to change hwpstate not to set p-states but Frequency IDs (FID) and Voltage ID (VID) like the linux driver does. I think that you misread their code a little bit. The vid/fid transition is used for K8 processors, for newer ones they do the same P-state transitioning. The secret of their success seems to be that they just write the MSR without any post-write checks. As to your questions about hardware behavior - yes, they are quite interesting, but perhaps irrelevant. The BKDG never specifies the OS P-state transition command sequence and timings, it just says write the MSR (exactly what Linux does). There could be different reasons why a core could be in a different P-state (mostly I suspect interactions between cores in a Bulldozer compute unit). When BKDG does specify the P-state transitioning sequence (for BIOS) it suggest a different one from what we do - first write the MSR on al processors, only then check the result (and the way of checking the result is also a bit different - using MSR xxx71). I just looked through the BKDG and I think you should definitely check MSRC001_0071[18:16]. MSRC001_0063[2:0] is SharedC but MSRC001_0062[2:0] and MSRC001_0071[18:15] are Not-same-for-all. I think this means writing a P-state to MSRC001_0062[2:0] will be reflected in MSRC001_0070[18:16] first, then MSRC001_0071[18:16] gets updated when the P-state transition is complete. MSRC001_0063[2:0] will only change when all cores in a compute unit is in sync., which may be too late. But as I've said, these details are probably not really useful in practice. We should just quit worrying and double-checking the hardware :-) I think we should check. Jung-uk Kim 0: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=drivers/cpufreq/powernow-k8.c;h=c0e816468e300f242735f4825d09b9d291a9b522;hb=HEAD 1: http://support.amd.com/us/Processor_TechDocs/42301_15h_Mod_00h-0Fh_BKDG.pdf -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+/vTkACgkQmlay1b9qnVPY9QCgqcEvUHKKQ3U0Rec5Kzdlrw3L kSkAnj6ofOf8PVkEHlxNrgGZAHJ2so1p =GQw9 -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send
Re: [stable 9] broken hwpstate calls
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2012-05-25 13:11:21 -0400, Jung-uk Kim wrote: I just looked through the BKDG and I think you should definitely check MSRC001_0071[18:16]. MSRC001_0063[2:0] is SharedC but MSRC001_0062[2:0] and MSRC001_0071[18:15] are Not-same-for-all. ^^ 16 Sorry for the typo. Jung-uk Kim -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+/vb4ACgkQmlay1b9qnVOjPACbBIyx9eHTXqDqJjeAQpamAfPT 9+oAoL99VMf9MAhspIBJGvjFBG2aLynE =4Z9b -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: [stable 9] broken hwpstate calls
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2012-05-25 15:39:39 -0400, Andriy Gapon wrote: on 25/05/2012 20:11 Jung-uk Kim said the following: I just looked through the BKDG and I think you should definitely check MSRC001_0071[18:16]. MSRC001_0063[2:0] is SharedC but MSRC001_0062[2:0] and MSRC001_0071[18:15] are Not-same-for-all. I think this means writing a P-state to MSRC001_0062[2:0] will be reflected in MSRC001_0070[18:16] first, then MSRC001_0071[18:16] gets updated when the P-state transition is complete. MSRC001_0063[2:0] will only change when all cores in a compute unit is in sync., which may be too late. [snip] I think we should check. Jung-uk, if we decide so, then I think that we could still keep the things simple. As we currently use the wholesale approach (all CPUs are set to the same P-state regardless of topology), then we could first make a pass of writing the MSR on all processors with a new P-state value and then make another pass of checking via MSR C001_0063 that the P-state is acquired. No, I believe checking MSRC001_0071[18:16] is much simpler if it works. And it does not break current cpufreq(4) design principles. Jung-uk Kim -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+/5iQACgkQmlay1b9qnVOHLgCfY0ELt5oN1hml8S+bDGSHbOux bj4AoKisSh9DlK46U+LFthaSGicp/+Hc =BYej -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: [stable 9] broken hwpstate calls
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2012-05-18 01:32:09 -0400, Sean Bruno wrote: Looks like my AMD box isn't quite working correctly with regards to P-states.I noted this repeating periodically: hwpstate0: set freq failed, err 6 I noted these errors when setting the hwpstate verbose systctl on: May 17 22:28:32 Alice kernel: hwpstate0: set freq failed, err 6 May 17 22:28:32 Alice kernel: hwpstate0: setting P1-state on cpu0 May 17 22:28:32 Alice kernel: hwpstate0: result P1-state on cpu0 May 17 22:28:32 Alice kernel: hwpstate0: setting P1-state on cpu1 May 17 22:28:32 Alice kernel: hwpstate0: result P1-state on cpu1 May 17 22:28:32 Alice kernel: hwpstate0: setting P1-state on cpu2 May 17 22:28:32 Alice kernel: hwpstate0: result P1-state on cpu2 May 17 22:28:32 Alice kernel: hwpstate0: setting P1-state on cpu3 May 17 22:28:32 Alice kernel: hwpstate0: result P1-state on cpu3 May 17 22:28:32 Alice kernel: hwpstate0: setting P1-state on cpu4 May 17 22:28:32 Alice kernel: hwpstate0: result P1-state on cpu4 May 17 22:28:32 Alice kernel: hwpstate0: setting P1-state on cpu5 May 17 22:28:32 Alice kernel: hwpstate0: result P1-state on cpu5 May 17 22:28:32 Alice kernel: hwpstate0: setting P1-state on cpu6 May 17 22:28:32 Alice kernel: hwpstate0: result P1-state on cpu6 May 17 22:28:32 Alice kernel: hwpstate0: setting P1-state on cpu7 May 17 22:28:32 Alice kernel: hwpstate0: result P1-state on cpu7 Sean ref this machine: http://forums.pcbsd.org/showthread.php?t=16733 I briefly looked at the dmesg. You have a Family 15h processor (Bulldozer with Turbo Core) and I believe it isn't supported (yet). It won't be too hard to implement, though. Jung-uk Kim -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+2dlkACgkQmlay1b9qnVOhzwCfRi7ZqdpQ8yH/N3IHqCFl/586 XdoAnRLeenDvgQKvB6BIjyMsoskXcSNs =hGYz -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Resume broken in 8.3-PRERELEASE
On Friday 02 March 2012 03:50 am, Alexey Dokuchaev wrote:
On Thu, Mar 01, 2012 at 04:55:03PM -0500, Jung-uk Kim wrote:
It does not make a difference for me (i.e., usb suspend/resume
still broken) but I think I found a typo:
--- sys/dev/usb/controller/usb_controller.c (revision 232365)
+++ sys/dev/usb/controller/usb_controller.c (working copy)
@@ -407,7 +407,7 @@ usb_bus_suspend(struct usb_proc_msg *pm)
USB_BUS_UNLOCK(bus);
- bus_generic_shutdown(bus-bdev);
+ bus_generic_suspend(bus-bdev);
usbd_enum_lock(udev);
Same thing here, does not seem to improve anything. It might
suspend, resume (with keyboard working), then die on next suspend
completely. Or it may die on the first suspend (without suspending
-- fans are spinning, screen is black and no response to anything
except hard power-off), this actually happens more often.
Try the attached patch. At least, it fixed my problem.
./danfe
P.S. Also, doing ps in debugger shows that acpiconf(8) is
running in the userland upon resume (and hang). Not sure if it
helps or not though.
It usually means a device driver couldn't resume (and hang).
Jung-uk Kim
Index: sys/dev/usb/controller/usb_controller.c
===
--- sys/dev/usb/controller/usb_controller.c (revision 232401)
+++ sys/dev/usb/controller/usb_controller.c (working copy)
@@ -89,10 +89,15 @@ TUNABLE_INT(hw.usb.no_boot_wait, usb_no_boot_wa
SYSCTL_INT(_hw_usb, OID_AUTO, no_boot_wait, CTLFLAG_RDTUN, usb_no_boot_wait,
0,
No USB device enumerate waiting at boot.);
+static int usb_no_suspend_wait = 0;
+TUNABLE_INT(hw.usb.no_suspend_wait, usb_no_suspend_wait);
+SYSCTL_INT(_hw_usb, OID_AUTO, no_suspend_wait, CTLFLAG_RW|CTLFLAG_TUN,
+usb_no_suspend_wait, 0, No USB device waiting at system suspend.);
+
static int usb_no_shutdown_wait = 0;
TUNABLE_INT(hw.usb.no_shutdown_wait, usb_no_shutdown_wait);
-SYSCTL_INT(_hw_usb, OID_AUTO, no_shutdown_wait, CTLFLAG_RW|CTLFLAG_TUN,
usb_no_shutdown_wait, 0,
-No USB device waiting at system shutdown.);
+SYSCTL_INT(_hw_usb, OID_AUTO, no_shutdown_wait, CTLFLAG_RW|CTLFLAG_TUN,
+usb_no_shutdown_wait, 0, No USB device waiting at system shutdown.);
static devclass_t usb_devclass;
@@ -240,6 +245,11 @@ usb_suspend(device_t dev)
USB_BUS_LOCK(bus);
usb_proc_msignal(bus-explore_proc,
bus-suspend_msg[0], bus-suspend_msg[1]);
+ if (usb_no_suspend_wait == 0) {
+ /* wait for suspend callback to be executed */
+ usb_proc_mwait(bus-explore_proc,
+ bus-suspend_msg[0], bus-suspend_msg[1]);
+ }
USB_BUS_UNLOCK(bus);
return (0);
@@ -407,7 +417,7 @@ usb_bus_suspend(struct usb_proc_msg *pm)
USB_BUS_UNLOCK(bus);
- bus_generic_shutdown(bus-bdev);
+ bus_generic_suspend(bus-bdev);
usbd_enum_lock(udev);
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Resume broken in 8.3-PRERELEASE
On Thursday 01 March 2012 01:53 pm, Hans Petter Selasky wrote: On Thursday 01 March 2012 18:11:25 Alexey Dokuchaev wrote: On Mon, Feb 27, 2012 at 10:22:38PM +0700, Alexey Dokuchaev wrote: On Mon, Feb 27, 2012 at 09:28:15PM +0700, Alexey Dokuchaev wrote: I was mistaken, the latest kernel with working resume is from Jan 4 00:00 UTC, kernel from Jan 4 01:00 UTC does not allow my laptop to come back from zzz(8) successfully. It seems that offending change is rev. 1.9.2.5 of sys/nfsclient/nfs_krpc.c by rmacklem@ (SVN rev 229450). I've redone my bisecting, now suspending/resuming around at least ten times in console with zzz(8). I must apologize to rmacklem@, his commit has nothing to do with it. Apparently, the culprit is SVN rev 229370 on 2012-01-03 09:15:54Z by hselasky@, which (ironically enough) supposed to bring better support for USB controller suspend and resume. Kernel csuped and built before this date resumes just fine for me. However, the problem might lay deeper: disabling all USB modules (I traditionally run slim kernels with everything down to io/mem offloaded into modules) does not fix the hang, see below. Selectively disabling UHCI or EHCI does not make any difference either. Debugging of this issue is, however, complicated by the fact that doing call doadump results in Dumping 68M: message (similar problem was reported[1] by glebius@ back in 2004), and then nothing happens except for IDE led light-up and frozen debugger, which makes post-mortem analysis with kgdb(1) impossible. Setting up serial console (since it's a laptop, the only possibility for me right now is to use some noname USB adapter via uftdi(4)) works, but kernel GDB does not like it. Perhaps I'm just not passing 0x80 flag correctly, but hint.uftdi.0.flags=0x80 does not work. Is GDB backend impossible with USB serial adapters, or I am just doing it wrong? What strikes me most is that even with plain kbdmux(4) or atkdb(4) I still cannot resume, even on previous (before r229370) kernels (the earliest I've tried is from Jan 1 00:00 UTC). Any debugging hints or patches to try are highly appreciated. Thus far, the latest kernel where resume works (with USB stuff enabled) is from Jan 3 19:15 UTC. Hans Petter, do you have any ideas about it? Hi, The USB controllers should be reset after resume. Suspend is currently ASYNC. This might be one problem. Resume is also ASYNC, because we cannot block in the device_resume() callback. Make sure no serial port adapters have open devices and are blocking suspend and resume. What is output from usbconfig as root, before and after suspend/resume ? It does not make a difference for me (i.e., usb suspend/resume still broken) but I think I found a typo: Index: sys/dev/usb/controller/usb_controller.c === --- sys/dev/usb/controller/usb_controller.c (revision 232365) +++ sys/dev/usb/controller/usb_controller.c (working copy) @@ -407,7 +407,7 @@ usb_bus_suspend(struct usb_proc_msg *pm) USB_BUS_UNLOCK(bus); - bus_generic_shutdown(bus-bdev); + bus_generic_suspend(bus-bdev); usbd_enum_lock(udev); Jung-uk Kim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Resume broken in 8.3-PRERELEASE
On Monday 27 February 2012 11:47 am, Alexey Dokuchaev wrote: On Mon, Feb 27, 2012 at 10:47:49AM -0500, Rick Macklem wrote: Yes, I can't think of how r229450 would affect resume. All it does is clear the high order bit in an error reply from an NFS server, since that bit should never be set in an NFS error reply and, if set, it results in an mbuf list being free'd twice. True, although even if it helps triggering the real underlying bug, it's still weird. The bit is erroneously set by amd sometimes. If you are using amd, that might be related to the resume problem? No, I don't; I've deliberately disabled almost everything. ps: I suspect you saw it, but there was a recent thread related to known suspend/resume issues and discussed how they might be fixed in the future. Sorry, I don't remember which list or the exact subject line. Yes, I know what are you talking about. However, I don't recall if any one was experiencing the same symptoms as I do. Can you please try head and/or stable/9? FYI, Linux people found that some BIOSes can corrupt low 64KB between suspend/resume, which may cause strangeness like this. I worked around it in head (r231781) and stable/9 (r232088). Thanks, Jung-uk Kim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: pthread_cond_timedwait() broken in 9-stable? (from JAN 10)
is the problem? kernel TSC driver? generic gettimeofday() code? pthreads cond code? the application? I am running the fio test on my notebook which is using TSC-low, it is on 9.0-RC3, I can not reproduce the problem for minutes, then I interrupt it with ctrl-c: http://people.freebsd.org/~davidxu/tsc_pthread/dmesg.txt http://people.freebsd.org/~davidxu/tsc_pthread/tc.txt http://people.freebsd.org/~davidxu/tsc_pthread/fio.txt Your CPU is single-package, dual-core, and SMT-enabled. All cores should be in perfect sync. Jung-uk Kim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: pthread_cond_timedwait() broken in 9-stable? [possible answer]
On Thursday 16 February 2012 08:55 pm, Julian Elischer wrote: kern.timecounter.tick: 1 kern.timecounter.choice: TSC-low(1000) i8254(0) HPET(950) ACPI-fast(900) dummy(-100) kern.timecounter.hardware: ACPI-fast kern.timecounter.stepwarnings: 0 switching the machine from TSC_low to ACPI-fast fixes the problem. in 8.x it used to default to ACPI but I used to switch it to TSC to get better performance. I wonder why TSC-low is now bad to use.. maybe the TSCs are not as well sychronised as they were in 8.x? Can you please show us verbose dmesg output? FYI, TSC and TSC-low are not very different. TSC-low is just lower resolution version of TSC for SMP. Only difference is, we have automated your timecounter choice, i.e., if TSCs seem reasonably well-synchronized, select it by default but give lower resolution. In other words, if your TSC timecounter was never going backwards previously, TSC-low timecounter won't, guaranteed. So, the root cause should be somewhere else. Jung-uk Kim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: linux-f10-flashplugin
On Thursday 29 September 2011 04:06 pm, Alexander Leidinger wrote: On Thu, 29 Sep 2011 12:50:01 -0700 Ted Faber fa...@isi.edu wrote: On Thu, Sep 29, 2011 at 02:41:39PM -0400, Michael Butler wrote: On 09/29/11 13:57, Norbert Augenstein wrote: On Wed, Sep 28, 2011 at 10:08:25PM +0400, S.N.Grigoriev wrote: 28.09.2011, 21:10, Conrad J. Sabatierconr...@cox.net: On Wed, 28 Sep 2011 11:50:08 -0500 Conrad J. Sabatierconr...@cox.net wrote: I see that as well as: (process:5430): Gtk-WARNING **: Locale not supported by C library. Using the fallback 'C' locale. (npviewer.bin:5430): GLib-WARNING **: getpwuid_r(): failed due to unknown user id (2139) (npviewer.bin:5430): Gtk-WARNING **: cannot open display: :0.0 *** NSPlugin Wrapper *** ERROR: failed to initialize plugin-side RPC client connection NOTE: child process received `Goodbye', closing down I haven't explored the getpwuid_r thing. Can you all please confirm that you run the most recent FreeBSD version (of your branch), as in with the recent security fixes? There are reports that one of them may have caused what you see. Linux does not have sun_len field for Unix domain socket and it does not care when sa_family is AF_UNIX. One example from nspluginwrapper itself: nspluginwrapper-1.4.4/src/rpc.c: 709: #ifdef HAVE_SOCKADDR_UN_SUN_LEN 710: connection-socket_addr.sun_len = connection-socket_addr_len; 711: #endif We can hack up nspluginwrapper and rebuild Linux binary but Linuxulator has to correct it now, I guess. Jung-uk Kim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: powernow regression in 8-STABLE
On Saturday 23 July 2011 04:21 am, Callum Gibson wrote: On 22Jul11 17:57, Jung-uk Kim wrote: }Please try the attached patch. If it doesn't work, I need to see }acpidump -dt output. Sorry, no difference. Given jhb's response is there any point pursuing this further? Seems to be a known issue with legacy usb that perhaps can't be fixed. In any case, acpidump output here: http://members.optusnet.com.au/callumgibson/acpidump.out.gz I agree that the legacy USB issue must be fixed but your BIOS is more broken than I originally thought. powernow expects a static table (via acpi_perf) but _PSS is dynamically constructed at runtime. I don't think we can support this case easily, sorry. Jung-uk Kim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: powernow regression in 8-STABLE
On Saturday 23 July 2011 04:47 am, Jeremy Chadwick wrote:
On Sat, Jul 23, 2011 at 06:13:04PM +1000, Callum Gibson wrote:
On 22Jul11 08:16, John Baldwin wrote:
}The problem is that we calibrate the TSC using this algorithm:
}
} - grab the TSC
} - spin on the ISA timer waiting for it to run for a second
} - grab the TSC
}
}The issue is that the SMI# fires at the same time we want to be
execuiting }step 3, and step 3 is deferred while the SMI# handler
runs. As a result, the }TSC delta ends up being 1 second + time
of an SMI# to poll USB. We have a }hack fix for this at work
that originally came from Attilio Rao. This is a }patch for it
relative to 8. It disables interrupt generation for the ISA
}timer while we calibrate the TSC (which disables the SMI#
temporarily):
Thanks, John. The hack works as intended, but I guess it's not a
real solution which is why you haven't committed it?
This sort of thing is going to have to get dealt with officially
sooner or later, hack-fix or elegant solution either way[1].
More and more systems are using native USB keyboards, and most
system BIOSes I've seen (from multiple vendors, specifically
Supermicro, Lenovo, Asus, Dell, HP, and Gigabyte[2]) are defaulting
to having these options enabled (and rightfully so).
If the hack-fix has repercussions, it would be helpful to know what
those are or how those might manifest themselves. Otherwise, has
anyone taken a look at how Linux addresses this problem? To my
knowledge GRUB and similar bootstraps do not have a native USB
stack, so I'm left wondering how they deal with this.
[1]: I'm in no way saying Hey! Fix this! {contributes nothing},
I'm simply pointing out that we're at a point where we really don't
have much of a choice. The more I read technical explanations from
John the more hate x86 architecture. ;-)
[2]: On a couple Gigabyte boards I have the default values for said
option is enabled (for both keyboard and mouse).
It is really annoying problem and it has to be fixed *properly*.
Previously, we dealt with similar SMI# problem per platform, e.g.,
http://svnweb.freebsd.org/base?view=revisionrevision=174557
This quirk table matches 6 platforms now:
if (strncmp(sysenv, MacBook1,1, 10) == 0 ||
strncmp(sysenv, MacBook3,1, 10) == 0 ||
strncmp(sysenv, MacBookPro1,1, 13) == 0 ||
strncmp(sysenv, MacBookPro1,2, 13) == 0 ||
strncmp(sysenv, MacBookPro3,1, 13) == 0 ||
strncmp(sysenv, Macmini1,1, 10) == 0) {
if (bootverbose)
printf(Disabling LEGACY_USB_EN bit on
Intel ICH.\n);
outl(ICH_SMI_EN, inl(ICH_SMI_EN) ~0x8);
}
...
We definitely need to generalize it as soon as possible.
Jung-uk Kim
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: powernow regression in 8-STABLE
On Friday 22 July 2011 07:13 am, Callum Gibson wrote:
On 21Jul11 17:53, Jung-uk Kim wrote:
}
}
http://members.optusnet.com.au/callumgibson/boot_verboser_nousb.out
} and dev.cpu.0.freq reappears! Spooky. Is that a solution or a }
workaround? I noticed this disables usb keyboard support at the }
boot menus.
}
}It is a workaround. Please try the attached patch.
Sorry, no improvement that I can see. See verbose output:
http://members.optusnet.com.au/callumgibson/boot_verboser2.out
Please try the attached patch. If it doesn't work, I need to see
acpidump -dt output.
Jung-uk Kim
Index: sys/kern/kern_cpu.c
===
--- sys/kern/kern_cpu.c (revision 224271)
+++ sys/kern/kern_cpu.c (working copy)
@@ -145,9 +145,7 @@ static int
cpufreq_attach(device_t dev)
{
struct cpufreq_softc *sc;
- struct pcpu *pc;
device_t parent;
- uint64_t rate;
int numdevs;
CF_DEBUG(initializing %s\n, device_get_nameunit(dev));
@@ -157,18 +155,7 @@ cpufreq_attach(device_t dev)
sysctl_ctx_init(sc-sysctl_ctx);
TAILQ_INIT(sc-all_levels);
CF_MTX_INIT(sc-lock);
- sc-curr_level.total_set.freq = CPUFREQ_VAL_UNKNOWN;
SLIST_INIT(sc-saved_freq);
- /* Try to get nominal CPU freq to use it as maximum later if needed */
- sc-max_mhz = cpu_get_nominal_mhz(dev);
- /* If that fails, try to measure the current rate */
- if (sc-max_mhz = 0) {
- pc = cpu_get_pcpu(dev);
- if (cpu_est_clockrate(pc-pc_cpuid, rate) == 0)
- sc-max_mhz = rate / 100;
- else
- sc-max_mhz = CPUFREQ_VAL_UNKNOWN;
- }
/*
* Only initialize one set of sysctls for all CPUs. In the future,
@@ -500,6 +487,7 @@ cf_get_method(device_t dev, struct cf_level *level
goto out;
}
}
+ CF_DEBUG(get freq failed, estimated freq %d\n, (int)rate);
error = ENXIO;
out:
@@ -551,17 +539,23 @@ cf_levels_method(device_t dev, struct cf_level *le
* provide settings for informational purposes only.
*/
error = CPUFREQ_DRV_TYPE(devs[i], type);
- if (error || (type CPUFREQ_FLAG_INFO_ONLY)) {
- if (error == 0) {
- CF_DEBUG(skipping info-only driver %s\n,
- device_get_nameunit(devs[i]));
- }
+ if (error)
continue;
- }
set_count = MAX_SETTINGS;
error = CPUFREQ_DRV_SETTINGS(devs[i], sets, set_count);
if (error || set_count == 0)
continue;
+ if ((type CPUFREQ_TYPE_MASK) == CPUFREQ_TYPE_ABSOLUTE
+ sc-max_mhz sets[0].freq) {
+ CF_DEBUG(setting max freq %d from %s\n,
+ sets[0].freq, device_get_nameunit(devs[i]));
+ sc-max_mhz = sets[0].freq;
+ }
+ if ((type CPUFREQ_FLAG_INFO_ONLY) != 0) {
+ CF_DEBUG(skipping info-only driver %s\n,
+ device_get_nameunit(devs[i]));
+ continue;
+ }
/* Add the settings to our absolute/relative lists. */
switch (type CPUFREQ_TYPE_MASK) {
@@ -867,8 +861,9 @@ cpufreq_dup_set(struct cpufreq_softc *sc, struct c
static int
cpufreq_curr_sysctl(SYSCTL_HANDLER_ARGS)
{
+ struct cf_level level;
+ struct cf_level *levels;
struct cpufreq_softc *sc;
- struct cf_level *levels;
int count, devcount, error, freq, i, n;
device_t *devs;
@@ -876,10 +871,10 @@ cpufreq_curr_sysctl(SYSCTL_HANDLER_ARGS)
sc = oidp-oid_arg1;
levels = sc-levels_buf;
- error = CPUFREQ_GET(sc-dev, levels[0]);
+ error = CPUFREQ_GET(sc-dev, level);
if (error)
goto out;
- freq = levels[0].total_set.freq;
+ freq = level.total_set.freq;
error = sysctl_handle_int(oidp, freq, 0, req);
if (error != 0 || req-newptr == NULL)
goto out;
@@ -1000,8 +995,11 @@ out:
int
cpufreq_register(device_t dev)
{
+ struct cf_setting set;
+ struct cf_setting *sets;
struct cpufreq_softc *sc;
device_t cf_dev, cpu_dev;
+ int error, freq, max, set_count, type;
/* Add a sysctl to get each driver's settings separately. */
SYSCTL_ADD_PROC(device_get_sysctl_ctx(dev),
@@ -1009,14 +1007,34 @@ cpufreq_register(device_t dev)
OID_AUTO, freq_settings, CTLTYPE_STRING | CTLFLAG_RD, dev, 0,
cpufreq_settings_sysctl, A, CPU frequency driver settings);
+ /* Get settings from the device and find current and maximum
frequencies */
+ freq = max
Re: powernow regression in 8-STABLE
On Wednesday 20 July 2011 10:28 pm, Callum Gibson wrote: On 20Jul11 19:28, Jung-uk Kim wrote: }From your dmesg output, I see that the processor speed was not }calibrated properly. ML-40's max. core freq. is 2,200 MHz according }to its specification but it was probed at 2,282 MHz, which is too }high. I think that's the problem. Can you please try the attached }patch? Yes, I have seen core freq wobble around for most of the time I've owned it, but usually close to 2200. This morning (with my reverted powernow.c) I had: dev.cpu.0.freq_levels: 3080/35000 2800/29000 2520/24000 2240/2 1120/9000 which I don't believe I've seen before. Anyway... With your new patch applied (and powernow.c changed back to r222148) I get exact freq levels: dev.cpu.0.freq_levels: 2200/35000 2000/29000 1800/24000 1600/2 800/9000 That's better. :-) However, dev.cpu.0.freq OID is still missing from sysctl output. As another data point, with your new patch applied, but the old powernow.c, (which I booted into mistakenly first time), I did have dev.cpu.0.freq, but the freq levels weren't exact. Here is a new verbose boot output with a cleaned and built kernel, 8-STABLE as at time=1311028656 and your patch applied: http://members.optusnet.com.au/callumgibson/verboseboot2.out Can you please do set debug.cpufreq.verbose=1 from loader prompt and show me the dmesg output? I want to see intial settings. You can reset it from command line with sysctl debug.cpufreq.verbose=0 later. Thanks, Jung-uk Kim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: powernow regression in 8-STABLE
On Thursday 21 July 2011 04:56 pm, Callum Gibson wrote:
On 21Jul11 12:07, Jung-uk Kim wrote:
}Can you please do set debug.cpufreq.verbose=1 from loader prompt
and }show me the dmesg output? I want to see intial settings. You
can }reset it from command line with sysctl
debug.cpufreq.verbose=0 }later.
http://members.optusnet.com.au/callumgibson/boot_verboser.out
Also, as suggested by jhb@, with legacy usb disabled:
http://members.optusnet.com.au/callumgibson/boot_verboser_nousb.out
and dev.cpu.0.freq reappears! Spooky. Is that a solution or a
workaround? I noticed this disables usb keyboard support at the
boot menus.
It is a workaround. Please try the attached patch.
Jung-uk Kim
Index: sys/kern/kern_cpu.c
===
--- sys/kern/kern_cpu.c (revision 224245)
+++ sys/kern/kern_cpu.c (working copy)
@@ -157,17 +157,18 @@ cpufreq_attach(device_t dev)
sysctl_ctx_init(sc-sysctl_ctx);
TAILQ_INIT(sc-all_levels);
CF_MTX_INIT(sc-lock);
- sc-curr_level.total_set.freq = CPUFREQ_VAL_UNKNOWN;
SLIST_INIT(sc-saved_freq);
/* Try to get nominal CPU freq to use it as maximum later if needed */
- sc-max_mhz = cpu_get_nominal_mhz(dev);
- /* If that fails, try to measure the current rate */
- if (sc-max_mhz = 0) {
- pc = cpu_get_pcpu(dev);
- if (cpu_est_clockrate(pc-pc_cpuid, rate) == 0)
- sc-max_mhz = rate / 100;
- else
- sc-max_mhz = CPUFREQ_VAL_UNKNOWN;
+ if (sc-max_mhz == CPUFREQ_VAL_UNKNOWN) {
+ sc-max_mhz = cpu_get_nominal_mhz(dev);
+ /* If that fails, try to measure the current rate */
+ if (sc-max_mhz = 0) {
+ pc = cpu_get_pcpu(dev);
+ if (cpu_est_clockrate(pc-pc_cpuid, rate) == 0)
+ sc-max_mhz = rate / 100;
+ else
+ sc-max_mhz = CPUFREQ_VAL_UNKNOWN;
+ }
}
/*
@@ -1000,8 +1001,11 @@ out:
int
cpufreq_register(device_t dev)
{
+ struct cf_setting set;
+ struct cf_setting *sets;
struct cpufreq_softc *sc;
device_t cf_dev, cpu_dev;
+ int error, freq, max, set_count, type;
/* Add a sysctl to get each driver's settings separately. */
SYSCTL_ADD_PROC(device_get_sysctl_ctx(dev),
@@ -1009,14 +1013,34 @@ cpufreq_register(device_t dev)
OID_AUTO, freq_settings, CTLTYPE_STRING | CTLFLAG_RD, dev, 0,
cpufreq_settings_sysctl, A, CPU frequency driver settings);
+ /* Get settings from the device and find current and maximum
frequencies */
+ freq = max = CPUFREQ_VAL_UNKNOWN;
+ if (CPUFREQ_DRV_TYPE(dev, type) == 0
+ (type CPUFREQ_TYPE_MASK) == CPUFREQ_TYPE_ABSOLUTE) {
+ if (CPUFREQ_DRV_GET(dev, set) == 0)
+ freq = set.freq;
+ set_count = MAX_SETTINGS;
+ sets = malloc(set_count * sizeof(*sets), M_TEMP, M_NOWAIT);
+ if (sets != NULL) {
+ if (CPUFREQ_DRV_SETTINGS(dev, sets, set_count) == 0
+ set_count 0)
+ max = sets[0].freq;
+ free(sets, M_TEMP);
+ }
+ }
+
/*
* Add only one cpufreq device to each CPU. Currently, all CPUs
* must offer the same levels and be switched at the same time.
*/
cpu_dev = device_get_parent(dev);
- if ((cf_dev = device_find_child(cpu_dev, cpufreq, -1))) {
+ cf_dev = device_find_child(cpu_dev, cpufreq, -1);
+ if (cf_dev != NULL) {
sc = device_get_softc(cf_dev);
- sc-max_mhz = CPUFREQ_VAL_UNKNOWN;
+ if (sc-curr_level.total_set.freq == CPUFREQ_VAL_UNKNOWN)
+ sc-curr_level.total_set.freq = freq;
+ if (sc-max_mhz == CPUFREQ_VAL_UNKNOWN)
+ sc-max_mhz = max;
return (0);
}
@@ -1025,8 +1049,13 @@ cpufreq_register(device_t dev)
if (cf_dev == NULL)
return (ENOMEM);
device_quiet(cf_dev);
-
- return (device_probe_and_attach(cf_dev));
+ error = device_probe(cf_dev);
+ if (error != 0)
+ return (error);
+ sc = device_get_softc(cf_dev);
+ sc-curr_level.total_set.freq = freq;
+ sc-max_mhz = max;
+ return (device_attach(cf_dev));
}
int
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: powernow regression in 8-STABLE
On Tuesday 19 July 2011 07:20 am, Callum Gibson wrote:
Hi,
I've just noticed and tracked down a regression in
x86/cpufreq/powernow.c (on amd64) which was first mentioned here:
http://lists.freebsd.org/pipermail/freebsd-current/2011-March/02350
9.html
although no followup seems to have occurred.
The above thread is irrelevant. It was an Intel processor.
Symptoms are that powerd stops working because the dev.cpu.0.freq
OID is no longer gettable nor settable.
This seems to have been caused by the following revision:
http://svnweb.freebsd.org/base?view=revisionrevision=222148
which was in turn an MFC of r221102, so I guess the problem exists
on -current as well, although I can't confirm that since I don't
run it.
Reverting the change fixes the problem and powerd will work again.
Also other utilities, such as xacpim, work properly.
I'm running a ML-40 Turion laptop (HP Compaq nx6125).
From your dmesg output, I see that the processor speed was not
calibrated properly. ML-40's max. core freq. is 2,200 MHz according
to its specification but it was probed at 2,282 MHz, which is too
high. I think that's the problem. Can you please try the attached
patch?
Jung-uk Kim
Index: sys/kern/kern_cpu.c
===
--- sys/kern/kern_cpu.c (revision 224231)
+++ sys/kern/kern_cpu.c (working copy)
@@ -159,16 +159,21 @@ cpufreq_attach(device_t dev)
CF_MTX_INIT(sc-lock);
sc-curr_level.total_set.freq = CPUFREQ_VAL_UNKNOWN;
SLIST_INIT(sc-saved_freq);
- /* Try to get nominal CPU freq to use it as maximum later if needed */
- sc-max_mhz = cpu_get_nominal_mhz(dev);
- /* If that fails, try to measure the current rate */
- if (sc-max_mhz = 0) {
- pc = cpu_get_pcpu(dev);
- if (cpu_est_clockrate(pc-pc_cpuid, rate) == 0)
- sc-max_mhz = rate / 100;
- else
- sc-max_mhz = CPUFREQ_VAL_UNKNOWN;
+ if (sc-max_mhz == CPUFREQ_VAL_UNKNOWN) {
+ /* Try to get nominal CPU freq to use it as maximum later. */
+ sc-max_mhz = cpu_get_nominal_mhz(dev);
+ /* If that fails, try to measure the current rate */
+ if (sc-max_mhz = 0) {
+ pc = cpu_get_pcpu(dev);
+ if (cpu_est_clockrate(pc-pc_cpuid, rate) == 0)
+ sc-max_mhz = rate / 100;
+ else
+ sc-max_mhz = CPUFREQ_VAL_UNKNOWN;
+ }
}
+ if (sc-max_mhz == CPUFREQ_VAL_UNKNOWN)
+ CF_DEBUG(unknown max frequency for %s\n,
+ device_get_nameunit(dev));
/*
* Only initialize one set of sysctls for all CPUs. In the future,
@@ -1001,7 +1006,9 @@ int
cpufreq_register(device_t dev)
{
struct cpufreq_softc *sc;
+ struct cf_setting *sets;
device_t cf_dev, cpu_dev;
+ int error, max, set_count, type;
/* Add a sysctl to get each driver's settings separately. */
SYSCTL_ADD_PROC(device_get_sysctl_ctx(dev),
@@ -1009,14 +1016,29 @@ cpufreq_register(device_t dev)
OID_AUTO, freq_settings, CTLTYPE_STRING | CTLFLAG_RD, dev, 0,
cpufreq_settings_sysctl, A, CPU frequency driver settings);
+ /* Get settings from the device and find maximum if possible. */
+ max = CPUFREQ_VAL_UNKNOWN;
+ if (CPUFREQ_DRV_TYPE(dev, type) == 0
+ (type CPUFREQ_TYPE_MASK) == CPUFREQ_TYPE_ABSOLUTE) {
+ set_count = MAX_SETTINGS;
+ sets = malloc(set_count * sizeof(*sets), M_TEMP, M_NOWAIT);
+ if (sets != NULL) {
+ if (CPUFREQ_DRV_SETTINGS(dev, sets, set_count) == 0
+ set_count 0)
+ max = sets[0].freq;
+ free(sets, M_TEMP);
+ }
+ }
+
/*
* Add only one cpufreq device to each CPU. Currently, all CPUs
* must offer the same levels and be switched at the same time.
*/
cpu_dev = device_get_parent(dev);
- if ((cf_dev = device_find_child(cpu_dev, cpufreq, -1))) {
+ cf_dev = device_find_child(cpu_dev, cpufreq, -1);
+ if (cf_dev != NULL) {
sc = device_get_softc(cf_dev);
- sc-max_mhz = CPUFREQ_VAL_UNKNOWN;
+ sc-max_mhz = max;
return (0);
}
@@ -1025,8 +1047,12 @@ cpufreq_register(device_t dev)
if (cf_dev == NULL)
return (ENOMEM);
device_quiet(cf_dev);
-
- return (device_probe_and_attach(cf_dev));
+ error = device_probe(cf_dev);
+ if (error != 0)
+ return (error);
+ sc = device_get_softc(cf_dev);
+ sc-max_mhz = max;
+ return (device_attach(cf_dev));
}
int
___
freebsd-stable
Re: powernow regression in 8-STABLE
On Tuesday 19 July 2011 07:20 am, Callum Gibson wrote: Hi, I've just noticed and tracked down a regression in x86/cpufreq/powernow.c (on amd64) which was first mentioned here: http://lists.freebsd.org/pipermail/freebsd-current/2011-March/02350 9.html although no followup seems to have occurred. Symptoms are that powerd stops working because the dev.cpu.0.freq OID is no longer gettable nor settable. This seems to have been caused by the following revision: http://svnweb.freebsd.org/base?view=revisionrevision=222148 which was in turn an MFC of r221102, so I guess the problem exists on -current as well, although I can't confirm that since I don't run it. Reverting the change fixes the problem and powerd will work again. Also other utilities, such as xacpim, work properly. I'm running a ML-40 Turion laptop (HP Compaq nx6125). HP again... Can you please show me verbose boot messages? Thanks, Jung-uk Kim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Is machdep.cpu_idle_hlt deprecated?
On Monday 02 May 2011 10:48 am, Bruce Cran wrote: On Sat, 30 Apr 2011 21:20:28 -0700 Jeremy Chadwick free...@jdc.parodius.com wrote: Anyone know if machdep.cpu_idle_hlt still exists? Taken from acpi(4) on RELENG_8: It looks like it might have been replaced by machdep.idle: machdep.idle: currently selected idle function machdep.idle_available: list of available idle functions machdep.idle: acpi machdep.idle_available: spin, hlt, acpi, It seems machdep.cpu_idle_hlt was deprecated long ago with this commit by jeff (CC'ed): http://svnweb.freebsd.org/base?view=revisionrevision=178471 Jung-uk Kim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD 8.1 regression in x86bios.c
On Friday 25 February 2011 11:59 pm, Craig Boston wrote:
Hi all,
My laptop (Toshiba Portege R100) stopped working with an early boot
hang at some point between 8.0 and 8.1. After it broke last year I
had ended up just reverting to an earlier kernel, but finally found
the time to do a binary search and narrow it down.
The offending commit is:
http://svn.freebsd.org/viewvc/base?view=revisionrevision=205647
http://svn.freebsd.org/viewvc/base?view=revisionrevision=205647
Fix stupid typos. Some VESA BIOSes directly call BIOS interrupt
handlers within the VBE interrupt handler. Unfortunately it was
causing real mode page faults because we were fetching instructions
from bogus addresses. Pass me the pointyhat, please.
PR: kern/144654
MFC after:3 days
With this commit in place, the system hangs almost immediately on
boot, right after probing kdbmux. With debug.x86bios.{call,int}
enabled from the loader, the final lines before the hang are:
avail memory = 1299705856 (1239 MB)
kbd1 at kbdmux0
Calling int 0x10 (ax=0x4f00 bx=0x cx=0x dx=0x es=0x9e00
di=0x)
Exiting int 0x10 (ax=0x004f bx=0x cx=0x dx=0x es=0x9e00
di=0x)
Calling int 0x10 (ax=0x4f01 bx=0x cx=0x0144 dx=0x es=0x0200
di=0x)
Then a hard hang. With the 2 lines in x86bios.c reverted, the
system boots fine (even on a fresh 8.2 build with just that commit
backed out). The debug output from a successful boot looks like
this:
kbd1 at kbdmux0
Calling int 0x10 (ax=0x4f00 bx=0x cx=0x dx=0x es=0x9e00
di=0x)
Exiting int 0x10 (ax=0x004f bx=0x cx=0x dx=0x es=0x9e00
di=0x)
Calling int 0x10 (ax=0x4f01 bx=0x cx=0x0144 dx=0x es=0x0200
di=0x)
Exiting int 0x10 (ax=0xb13e bx=0x2065 cx=0x9e32 dx=0x1023 es=0x0200
di=0x0028)
Calling int 0x10 (ax=0x4f01 bx=0x cx=0x0143 dx=0x es=0x9c00
di=0x)
Exiting int 0x10 (ax=0xb13e bx=0x1065 cx=0x9e32 dx=0x1023 es=0x9c00
di=0x0028)
Calling int 0x10 (ax=0x4f01 bx=0x cx=0x0141 dx=0x es=0x0200
di=0x)
Exiting int 0x10 (ax=0xb13e bx=0x0865 cx=0x9e32 dx=0x1023 es=0x0200
di=0x0028)
(many more lines)
In any event, I'm not sure if this is a true bug, or just a broken
BIOS, but either way I thought you might want to know about it.
See the exit status of the working cases. Bogus status (%ax ==
0xb13e) was returned, which means the VBE calls failed and aborted.
So, yes, I guess it is one of those broken VESA BIOSes. :-(
Jung-uk Kim
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD 8.1 regression in x86bios.c
On Monday 28 February 2011 12:33 pm, Jung-uk Kim wrote:
On Friday 25 February 2011 11:59 pm, Craig Boston wrote:
Hi all,
My laptop (Toshiba Portege R100) stopped working with an early
boot hang at some point between 8.0 and 8.1. After it broke last
year I had ended up just reverting to an earlier kernel, but
finally found the time to do a binary search and narrow it down.
The offending commit is:
http://svn.freebsd.org/viewvc/base?view=revisionrevision=205647
http://svn.freebsd.org/viewvc/base?view=revisionrevision=205647
Fix stupid typos. Some VESA BIOSes directly call BIOS interrupt
handlers within the VBE interrupt handler. Unfortunately it was
causing real mode page faults because we were fetching
instructions from bogus addresses. Pass me the pointyhat, please.
PR: kern/144654
MFC after: 3 days
With this commit in place, the system hangs almost immediately on
boot, right after probing kdbmux. With debug.x86bios.{call,int}
enabled from the loader, the final lines before the hang are:
avail memory = 1299705856 (1239 MB)
kbd1 at kbdmux0
Calling int 0x10 (ax=0x4f00 bx=0x cx=0x dx=0x
es=0x9e00 di=0x)
Exiting int 0x10 (ax=0x004f bx=0x cx=0x dx=0x
es=0x9e00 di=0x)
Calling int 0x10 (ax=0x4f01 bx=0x cx=0x0144 dx=0x
es=0x0200 di=0x)
Then a hard hang. With the 2 lines in x86bios.c reverted, the
system boots fine (even on a fresh 8.2 build with just that
commit backed out). The debug output from a successful boot looks
like this:
kbd1 at kbdmux0
Calling int 0x10 (ax=0x4f00 bx=0x cx=0x dx=0x
es=0x9e00 di=0x)
Exiting int 0x10 (ax=0x004f bx=0x cx=0x dx=0x
es=0x9e00 di=0x)
Calling int 0x10 (ax=0x4f01 bx=0x cx=0x0144 dx=0x
es=0x0200 di=0x)
Exiting int 0x10 (ax=0xb13e bx=0x2065 cx=0x9e32 dx=0x1023
es=0x0200 di=0x0028)
Calling int 0x10 (ax=0x4f01 bx=0x cx=0x0143 dx=0x
es=0x9c00 di=0x)
Exiting int 0x10 (ax=0xb13e bx=0x1065 cx=0x9e32 dx=0x1023
es=0x9c00 di=0x0028)
Calling int 0x10 (ax=0x4f01 bx=0x cx=0x0141 dx=0x
es=0x0200 di=0x)
Exiting int 0x10 (ax=0xb13e bx=0x0865 cx=0x9e32 dx=0x1023
es=0x0200 di=0x0028)
(many more lines)
In any event, I'm not sure if this is a true bug, or just a
broken BIOS, but either way I thought you might want to know
about it.
See the exit status of the working cases. Bogus status (%ax ==
0xb13e) was returned, which means the VBE calls failed and aborted.
So, yes, I guess it is one of those broken VESA BIOSes. :-(
Please try the attached patch and let me know if it makes any
difference.
Thanks,
Jung-uk Kim
Index: sys/compat/x86bios/x86bios.c
===
--- sys/compat/x86bios/x86bios.c(revision 219101)
+++ sys/compat/x86bios/x86bios.c(working copy)
@@ -291,25 +291,6 @@ x86bios_emu_outl(struct x86emu *emu, uint16_t port
outl(port, val);
}
-static void
-x86bios_emu_get_intr(struct x86emu *emu, int intno)
-{
- uint16_t *sp;
- uint32_t iv;
-
- emu-x86.R_SP -= 6;
-
- sp = (uint16_t *)((vm_offset_t)x86bios_seg + emu-x86.R_SP);
- sp[0] = htole16(emu-x86.R_IP);
- sp[1] = htole16(emu-x86.R_CS);
- sp[2] = htole16(emu-x86.R_FLG);
-
- iv = x86bios_get_intr(intno);
- emu-x86.R_IP = iv 0x;
- emu-x86.R_CS = (iv 16) 0x;
- emu-x86.R_FLG = ~(F_IF | F_TF);
-}
-
void *
x86bios_alloc(uint32_t *offset, size_t size)
{
@@ -567,7 +548,6 @@ x86bios_unmap_mem(void)
static void
x86bios_init(void *arg __unused)
{
- int i;
mtx_init(x86bios_lock, x86bios lock, NULL, MTX_SPIN);
@@ -598,9 +578,6 @@ x86bios_init(void *arg __unused)
x86bios_emu.emu_outb = x86bios_emu_outb;
x86bios_emu.emu_outw = x86bios_emu_outw;
x86bios_emu.emu_outl = x86bios_emu_outl;
-
- for (i = 0; i 256; i++)
- x86bios_emu._x86emu_intrTab[i] = x86bios_emu_get_intr;
}
static void
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD 7 installs where FreeBSD 8 wont due to CD
On Monday 06 December 2010 06:46 pm, Pete French wrote: So, I just gave the 8.1 CD a try - which didnt take nearly as long as anticipated. End result is that it also fails to insall. Pr filed as http://www.freebsd.org/cgi/query-pr.cgi?pr=152874 Am wndering if this could be due to the change in the USB stack somehow though - I have a feeling that iLO presents the drive as a USB drive, and that there is already an IDE drive physicaly in the machine. This problem may be a reverse problem of this PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=138789 In other words, your virtual CD-ROM reads correct TOC from mounted image but block size is wrong? Maybe old umass(4) corrects this case heuristicly but the new USB stack doesn't? Just thinking out loud... Jung-uk Kim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: [Call for Tests] PAT issue on Apple hardware
On Sunday 21 November 2010 06:16 pm, army.of.root wrote: On 10\11\19 19:54, Jung-uk Kim wrote: On Tuesday 16 November 2010 03:30 pm, Jung-uk Kim wrote: On Monday 15 November 2010 08:36 pm, Jung-uk Kim wrote: Often times I hear complaints like my Mac hangs after upgrading to 8.1 or snapshot CD hangs on my brand new Mac. I know some of these complaints started happening when we switched to new PAT layout. It is so puzzling because it never happened on non-Apple hardware, AFAIK. I really like to fix this problem but I cannot afford a Mac. :-P If you are one of those lucky people, please test the attached patch and report your hardware model and any improvement or regression. Also, I added a new tunable vm.pmap.pat_works so that you can turn it off from loader (i.e., set vm.pmap.pat_works=0) and restore old behaviour without recompiling a new kernel. I revised this patch to make it more robust. http://people.freebsd.org/~jkim/pat-current.diff Also, I prepared a patch for stable/8. If you have recent Apple hardware and it hangs with 8.1 or stable/8, please test this patch. http://people.freebsd.org/~jkim/pat-stable.diff Anyone? I don't want to commit it blindly. :-( Jung-uk Kim works for me too! Hi, I patched the current 8.1-STABLE snapshot CD's kernel and baked it back into the iso. Before the patch, the kernel would hang, now the livefs cd boots fine on my MacBookPro5,5 (2009 13 alu). Thank you so much ! - I love it. I attached a dmesg. - Please ask if you need more information, I'd be happy to help. Keep up the awesome work :) I'll commit the patch to -current shortly. Thanks for testing! Jung-uk Kim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 8.1-RELEASE: snd_hda works as module only, suspend/resume leaves display off
On Sunday 21 November 2010 05:37 am, Stefan Walter wrote: [Resent because I forgot to really cc jkim...sorry!] Ian Smith, 17.11.10, 04:20h CET: On Tue, 16 Nov 2010, Bruce Cran wrote: On Tue, 16 Nov 2010 21:46:44 +0100 Lars Engels lars.eng...@0x20.net wrote: Download compile the code (gcc -o chvt chvt.c). Add $path/$to/chvt 1 to /etc/rc.suspend and $path/$to/chvt 9 to /etc/rc.resume, so that your machine automatically changes to ttyv0 before going to sleep and changes back to X after waking up. The acpi code already does this: if you run acpiconf from within X you'll see ttyv0 appear, the system turns off and when resuming ttyv0 appears before X11. In my case, I don't see ttyv0 appear before suspend - neither from within X nor from another tty. But when suspending from another tty, I see ttyv0 briefly after resume before it switches back to the one I started acpiconf from, so I guess the automatic switching works at least between ttys. Most cases, it happens too fast and users don't notice transition. When starting acpiconf from within X, I hear three beeps at intervals of about one second before the system suspends. As I wrote before, when the system resumes the screen turns on but remains black, the keyboard doesn't seem to do anything and I can only press the power button again to shut the system down completely. There have been cases where I've seen the console right before its powered down with lots of messages like this one (typed from memory): info: [drm] wait idle failed status If you are using hw.acpi.reset_video=1, please load vesa.ko instead. hw.acpi.reset_video is an evil hack. ;-) I don't know why X.org complains, though. Perhaps this might be one of those machines (I have two) that respond positively to setting sysctl hw.syscons.sc_no_suspend_vtswitch=1 ? When I do that, the only difference I've noticed is that I don't hear the three beeps mentioned above. Can anyone tell me if there have been changes to the ACPI code in 8-STABLE since 8.1-RELEASE that might influence the suspend/resume behaviour in this case? (There has been an MFC recently, but I have no idea if that might change anything for me - cc'd jkim because he seems to know much about this stuff.) Yes, I did several MFCs after 8.1-RELEASE, especially syscons(4), not ACPI. Jung-uk Kim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: [Call for Tests] PAT issue on Apple hardware
On Tuesday 16 November 2010 03:30 pm, Jung-uk Kim wrote: On Monday 15 November 2010 08:36 pm, Jung-uk Kim wrote: Often times I hear complaints like my Mac hangs after upgrading to 8.1 or snapshot CD hangs on my brand new Mac. I know some of these complaints started happening when we switched to new PAT layout. It is so puzzling because it never happened on non-Apple hardware, AFAIK. I really like to fix this problem but I cannot afford a Mac. :-P If you are one of those lucky people, please test the attached patch and report your hardware model and any improvement or regression. Also, I added a new tunable vm.pmap.pat_works so that you can turn it off from loader (i.e., set vm.pmap.pat_works=0) and restore old behaviour without recompiling a new kernel. I revised this patch to make it more robust. http://people.freebsd.org/~jkim/pat-current.diff Also, I prepared a patch for stable/8. If you have recent Apple hardware and it hangs with 8.1 or stable/8, please test this patch. http://people.freebsd.org/~jkim/pat-stable.diff Anyone? I don't want to commit it blindly. :-( Jung-uk Kim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: acpi(ca) mfc for 8.2
On Wednesday 17 November 2010 05:04 pm, Alexandre Sunny Kovalenko
wrote:
On Wed, 2010-11-17 at 20:43 +0200, Andriy Gapon wrote:
I want to do MFC of ACPICA imports to stable/8 before 8.2
release. This would obviously include commits that fix mismerges
or remove obsolete code. Plus some other small enhancements/fixes
in our ACPI code.
This is what I currently have:
svn status: http://people.freebsd.org/~avg/acpi-stable-8.txt
svn diff: http://people.freebsd.org/~avg/acpi-stable-8.diff
svn log ...:http://people.freebsd.org/~avg/acpi-stable-8.log
Please note that the svn diff above can not be used with
patch(1), because of some svn peculiarities related to files in
vendor area.
Here's a plain diff that should be more useful:
http://people.freebsd.org/~avg/acpi-stable-8.plain.diff
I will appreciate any testing and reviews.
Mobile users who track stable/8 would be the primary candidates,
I guess :-) Thanks a lot!
On my system:
FreeBSD RabbitsDen.RabbitsLawn.verizon.net 8.1-STABLE FreeBSD
8.1-STABLE #0 r215086: Wed Nov 10 11:07:30 EST 2010
r...@rabbitsden.rabbitslawn.verizon.net:/usr/obj/usr/src/sys/TPX60
i386
running on ThinkPad X60, I get proliferation of
acpi_tz0: error fetching current temperature -- AE_NOT_FOUND
messages after applying the patch.
Verbose dmesg from before and after cold boots are available
at:
http://members.verizon.net/~akovalenko/ACPI/dmesg.before.bz2
http://members.verizon.net/~akovalenko/ACPI/dmesg.after.bz2
respectively.
Now, on this machine tz0 is not a real thermal zone but some kind
of implement to initiate system shutdown for some case I never had
enough time or inclination to track through ASL. Real thermal zone
is tz1.
hw.acpi.thermal.min_runtime: 0
hw.acpi.thermal.polling_rate: 10
hw.acpi.thermal.user_override: 1
hw.acpi.thermal.tz0.temperature: 45.0C
hw.acpi.thermal.tz0.active: -1
hw.acpi.thermal.tz0.passive_cooling: 0
hw.acpi.thermal.tz0.thermal_flags: 0
hw.acpi.thermal.tz0._PSV: -1
hw.acpi.thermal.tz0._HOT: -1
hw.acpi.thermal.tz0._CRT: 127.0C
hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1
hw.acpi.thermal.tz0._TC1: -1
hw.acpi.thermal.tz0._TC2: -1
hw.acpi.thermal.tz0._TSP: -1
hw.acpi.thermal.tz1.temperature: 43.0C
hw.acpi.thermal.tz1.active: -1
hw.acpi.thermal.tz1.passive_cooling: 1
hw.acpi.thermal.tz1.thermal_flags: 0
hw.acpi.thermal.tz1._PSV: 75.0C
hw.acpi.thermal.tz1._HOT: -1
hw.acpi.thermal.tz1._CRT: 97.0C
hw.acpi.thermal.tz1._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1
hw.acpi.thermal.tz1._TC1: 5
hw.acpi.thermal.tz1._TC2: 4
hw.acpi.thermal.tz1._TSP: 600
If I can provide any additional information or test any patches,
please, let me know.
Ouch... Can you please try the attached patch?
Thanks,
Jung-uk Kim
Index: sys/dev/acpica/acpi_thermal.c
===
--- sys/dev/acpica/acpi_thermal.c (revision 215429)
+++ sys/dev/acpica/acpi_thermal.c (working copy)
@@ -181,14 +181,16 @@ static intacpi_tz_cooling_unit =
-1;
static int
acpi_tz_probe(device_t dev)
{
-intresult;
+ char *name;
-if (acpi_get_type(dev) == ACPI_TYPE_THERMAL !acpi_disabled(thermal)) {
- device_set_desc(dev, Thermal Zone);
- result = -10;
-} else
- result = ENXIO;
-return (result);
+ if (!acpi_disabled(thermal)) {
+ name = acpi_name(acpi_get_handle(dev));
+ if (name != NULL strcmp(name, \\_TZ_) == 0) {
+ device_set_desc(dev, Thermal Zone);
+ return (-10);
+ }
+ }
+ return (ENXIO);
}
static int
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: acpi(ca) mfc for 8.2
On Wednesday 17 November 2010 05:41 pm, Jung-uk Kim wrote: On Wednesday 17 November 2010 05:04 pm, Alexandre Sunny Kovalenko wrote: On Wed, 2010-11-17 at 20:43 +0200, Andriy Gapon wrote: I want to do MFC of ACPICA imports to stable/8 before 8.2 release. This would obviously include commits that fix mismerges or remove obsolete code. Plus some other small enhancements/fixes in our ACPI code. This is what I currently have: svn status: http://people.freebsd.org/~avg/acpi-stable-8.txt svn diff: http://people.freebsd.org/~avg/acpi-stable-8.diff svn log ...: http://people.freebsd.org/~avg/acpi-stable-8.log Please note that the svn diff above can not be used with patch(1), because of some svn peculiarities related to files in vendor area. Here's a plain diff that should be more useful: http://people.freebsd.org/~avg/acpi-stable-8.plain.diff I will appreciate any testing and reviews. Mobile users who track stable/8 would be the primary candidates, I guess :-) Thanks a lot! On my system: FreeBSD RabbitsDen.RabbitsLawn.verizon.net 8.1-STABLE FreeBSD 8.1-STABLE #0 r215086: Wed Nov 10 11:07:30 EST 2010 r...@rabbitsden.rabbitslawn.verizon.net:/usr/obj/usr/src/sys/TPX6 0 i386 running on ThinkPad X60, I get proliferation of acpi_tz0: error fetching current temperature -- AE_NOT_FOUND messages after applying the patch. Verbose dmesg from before and after cold boots are available at: http://members.verizon.net/~akovalenko/ACPI/dmesg.before.bz2 http://members.verizon.net/~akovalenko/ACPI/dmesg.after.bz2 respectively. Now, on this machine tz0 is not a real thermal zone but some kind of implement to initiate system shutdown for some case I never had enough time or inclination to track through ASL. Real thermal zone is tz1. hw.acpi.thermal.min_runtime: 0 hw.acpi.thermal.polling_rate: 10 hw.acpi.thermal.user_override: 1 hw.acpi.thermal.tz0.temperature: 45.0C hw.acpi.thermal.tz0.active: -1 hw.acpi.thermal.tz0.passive_cooling: 0 hw.acpi.thermal.tz0.thermal_flags: 0 hw.acpi.thermal.tz0._PSV: -1 hw.acpi.thermal.tz0._HOT: -1 hw.acpi.thermal.tz0._CRT: 127.0C hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 hw.acpi.thermal.tz0._TC1: -1 hw.acpi.thermal.tz0._TC2: -1 hw.acpi.thermal.tz0._TSP: -1 hw.acpi.thermal.tz1.temperature: 43.0C hw.acpi.thermal.tz1.active: -1 hw.acpi.thermal.tz1.passive_cooling: 1 hw.acpi.thermal.tz1.thermal_flags: 0 hw.acpi.thermal.tz1._PSV: 75.0C hw.acpi.thermal.tz1._HOT: -1 hw.acpi.thermal.tz1._CRT: 97.0C hw.acpi.thermal.tz1._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 hw.acpi.thermal.tz1._TC1: 5 hw.acpi.thermal.tz1._TC2: 4 hw.acpi.thermal.tz1._TSP: 600 If I can provide any additional information or test any patches, please, let me know. Ouch... Can you please try the attached patch? Please ignore this patch. I need little bit more thinking. Sorry, Jung-uk Kim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: acpi(ca) mfc for 8.2
On Wednesday 17 November 2010 05:48 pm, Jung-uk Kim wrote: On Wednesday 17 November 2010 05:41 pm, Jung-uk Kim wrote: On Wednesday 17 November 2010 05:04 pm, Alexandre Sunny Kovalenko wrote: On Wed, 2010-11-17 at 20:43 +0200, Andriy Gapon wrote: I want to do MFC of ACPICA imports to stable/8 before 8.2 release. This would obviously include commits that fix mismerges or remove obsolete code. Plus some other small enhancements/fixes in our ACPI code. This is what I currently have: svn status: http://people.freebsd.org/~avg/acpi-stable-8.txt svn diff: http://people.freebsd.org/~avg/acpi-stable-8.diff svn log ...:http://people.freebsd.org/~avg/acpi-stable-8.log Please note that the svn diff above can not be used with patch(1), because of some svn peculiarities related to files in vendor area. Here's a plain diff that should be more useful: http://people.freebsd.org/~avg/acpi-stable-8.plain.diff I will appreciate any testing and reviews. Mobile users who track stable/8 would be the primary candidates, I guess :-) Thanks a lot! On my system: FreeBSD RabbitsDen.RabbitsLawn.verizon.net 8.1-STABLE FreeBSD 8.1-STABLE #0 r215086: Wed Nov 10 11:07:30 EST 2010 r...@rabbitsden.rabbitslawn.verizon.net:/usr/obj/usr/src/sys/TP X6 0 i386 running on ThinkPad X60, I get proliferation of acpi_tz0: error fetching current temperature -- AE_NOT_FOUND messages after applying the patch. Verbose dmesg from before and after cold boots are available at: http://members.verizon.net/~akovalenko/ACPI/dmesg.before.bz2 http://members.verizon.net/~akovalenko/ACPI/dmesg.after.bz2 respectively. Now, on this machine tz0 is not a real thermal zone but some kind of implement to initiate system shutdown for some case I never had enough time or inclination to track through ASL. Real thermal zone is tz1. hw.acpi.thermal.min_runtime: 0 hw.acpi.thermal.polling_rate: 10 hw.acpi.thermal.user_override: 1 hw.acpi.thermal.tz0.temperature: 45.0C hw.acpi.thermal.tz0.active: -1 hw.acpi.thermal.tz0.passive_cooling: 0 hw.acpi.thermal.tz0.thermal_flags: 0 hw.acpi.thermal.tz0._PSV: -1 hw.acpi.thermal.tz0._HOT: -1 hw.acpi.thermal.tz0._CRT: 127.0C hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 hw.acpi.thermal.tz0._TC1: -1 hw.acpi.thermal.tz0._TC2: -1 hw.acpi.thermal.tz0._TSP: -1 hw.acpi.thermal.tz1.temperature: 43.0C hw.acpi.thermal.tz1.active: -1 hw.acpi.thermal.tz1.passive_cooling: 1 hw.acpi.thermal.tz1.thermal_flags: 0 hw.acpi.thermal.tz1._PSV: 75.0C hw.acpi.thermal.tz1._HOT: -1 hw.acpi.thermal.tz1._CRT: 97.0C hw.acpi.thermal.tz1._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 hw.acpi.thermal.tz1._TC1: 5 hw.acpi.thermal.tz1._TC2: 4 hw.acpi.thermal.tz1._TSP: 600 If I can provide any additional information or test any patches, please, let me know. Ouch... Can you please try the attached patch? Please ignore this patch. I need little bit more thinking. I think I know what's going on. Andriy, it seems this change is missing from your patchset (maybe more): http://svn.freebsd.org/viewvc/base/head/sys/contrib/dev/acpica/utilities/utglobal.c?r1=210976r2=213806 Jung-uk Kim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: [Call for Tests] PAT issue on Apple hardware
On Monday 15 November 2010 08:36 pm, Jung-uk Kim wrote: Often times I hear complaints like my Mac hangs after upgrading to 8.1 or snapshot CD hangs on my brand new Mac. I know some of these complaints started happening when we switched to new PAT layout. It is so puzzling because it never happened on non-Apple hardware, AFAIK. I really like to fix this problem but I cannot afford a Mac. :-P If you are one of those lucky people, please test the attached patch and report your hardware model and any improvement or regression. Also, I added a new tunable vm.pmap.pat_works so that you can turn it off from loader (i.e., set vm.pmap.pat_works=0) and restore old behaviour without recompiling a new kernel. I revised this patch to make it more robust. http://people.freebsd.org/~jkim/pat-current.diff Also, I prepared a patch for stable/8. If you have recent Apple hardware and it hangs with 8.1 or stable/8, please test this patch. http://people.freebsd.org/~jkim/pat-stable.diff Thanks! Jung-uk Kim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Console options for legacy-free mini-itx server?
On Sunday 14 November 2010 11:55 pm, Andrew Reilly wrote: Oh: the other thing about this system: I can't warm-start it, have to power down and then manually hit the power-on button. Attempting to reboot leaves the console sitting at something like Stopping other CPUs forever. I assume that this is a BIOS config problem, but haven't found the right control knob yet. I've tried turning hyperthreading on and off: no difference. Reading the kernel code around that message suggests that rebooting involves getting the keyboard controller to send an NMI, and I wonder if the legacy-free no-keyboard state of my system is having an effect on that, too? You may try sysctl hw.acpi.handle_reboot=1. If it works, just add it in /etc/sysctl.conf. FYI, it is automatically set since r213755 and MFC'd to stable/8 as r215006. Jung-uk Kimr213755 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Console options for legacy-free mini-itx server?
On Tuesday 16 November 2010 06:55 pm, Andrew Reilly wrote: On Tue, Nov 16, 2010 at 06:36:16PM -0500, Jung-uk Kim wrote: On Sunday 14 November 2010 11:55 pm, Andrew Reilly wrote: Oh: the other thing about this system: I can't warm-start it, have to power down and then manually hit the power-on button. Attempting to reboot leaves the console sitting at something like Stopping other CPUs forever. I assume that this is a BIOS config problem, but haven't found the right control knob yet. I've tried turning hyperthreading on and off: no difference. Reading the kernel code around that message suggests that rebooting involves getting the keyboard controller to send an NMI, and I wonder if the legacy-free no-keyboard state of my system is having an effect on that, too? You may try sysctl hw.acpi.handle_reboot=1. If it works, just add it in /etc/sysctl.conf. FYI, it is automatically set since r213755 and MFC'd to stable/8 as r215006. I've just checked, and my system has that sysctl knob set to 1 already. I don't know how long that has been the case, though: perhaps it has only been since my last boot anyway? I will give reboot another try when I am next in the same room as the machine... I guess you already have r215006, then. :-) If it appeared automagically, that means your system supports the ACPI reset register. If you still have reboot issues, please let me know. I still track -stable with csup, because I believed that to be the officially preferred method. I believe so. Is it OK to track directly with svn, now? Me, not sure. More specifically, how can one correlate svn revision numbers against a csup-extracted source tree? Unfortunately I don't see any easy way to find correlation ATM. :-( Jung-uk Kim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: MacBookPro7,1 and FreeBSD 8.1
[Move the thread to freebsd-sta...@] On Friday 12 November 2010 12:57 pm, Veniamin Gvozdikov wrote: Hi everybody. I have the macbook and I tryed install FreeBSD 8.1. But I have froze loading. I have it's: with acpi (default loading) http://img203.imageshack.us/img203/2556/dscn2822u.jpg disable acpi http://img152.imageshack.us/img152/1796/dscn2823.jpg verbose mode (option 5 at the boot menu) http://img822.imageshack.us/img822/8069/dscn2825gm.jpg It seems it is yet another mysterious and notorious memory mapped IO hangs after PAT change case of Apple hardware. If that's the case, FreeBSD 7.3 or older should work, I think. Then, you can upgrade it from source *after* adding your Mac model in sys/amd64/amd64/pmap.c such as this: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/amd64/amd64/pmap.c.diff?r1=1.710;r2=1.711 If it works, please let us know. Jung-uk Kim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Problem running 8.1R on KVM with AMD hosts
On Thursday 30 September 2010 02:57 pm, Luke Marsden wrote: Hi FreeBSD-stable, 1. Please, build your kernel with debug symbols. 2. Show kgdb output I could not convince the kernel to dump (it was looping forever but not panicing), but I have managed to compiled a kernel with debugging symbols and DDB which immediately drops into the debugger when the problem occurs, see screenshot at: http://lukemarsden.net/kvm-panic.png It seems MCA capability is advertised by the CPUID translator but writing to the MSRs causes GPF. In other words, it seems like a CPU emulator bug. A simple workaround is 'set hw.mca.enabled=0' from the loader prompt. If it works, add hw.mca.enabled=0 in /boot/loader.conf to make it permanent. MCA does not make any sense in emulation any way. Jung-uk Kim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: resume slow on Thinkpad T42 FreeBSD 8-STABLE
On Monday 27 September 2010 02:55 pm, Vitaly Magerya wrote: Ian Smith wrote: [...] During the 60s resume stall period, iff I'd suspended from a VTY, I found I could slowly (like maybe 3 seconds per character echoed) type a command, and some commands - possibly those cached? as there's no HD access - would run after another few seconds. In this way I discovered that 'date' commands reported the time some seconds after the resume (perhaps hours ago, or yesterday) until the stall ended, disk light flashed and normality resumed, sometimes with calcru: time went backwards .. messages, most often for devd. Yes, same here. I must add that some peripherals do not work normally after the resume: - the mouse doesn't work until I restart moused manually --- 8 --- SNIP!!! --- 8 --- If the mouse is connected to PS/2 port, the following device flags may help. psm(4): bit 13 HOOKRESUME The built-in PS/2 pointing device of some laptop computers is somehow not operable immediately after the system `resumes' from the power saving mode, though it will eventually become available. There are reports that stimulating the device by performing I/O will help waking up the device quickly. This flag will enable a piece of code in the psm driver to hook the `resume' event and exercise some harmless I/O operations on the device. bit 14 INITAFTERSUSPEND This flag adds more drastic action for the above problem. It will cause the psm driver to reset and re-initialize the pointing device after the `resume' event. It has no effect unless the HOOKRESUME flag is set as well. I always use hint.psm.0.flags=0x6000 in /boot/loader.conf, i.e., turn on both HOOKRESUME and INITAFTERSUSPEND, to work around similar problem on different laptop. Can you please report other problems in the appropriate ML? em - freebsd-net@ usb - freebsd-usb@ acpi_ec - freebsd-acpi@ BTW, USB stack issue is known problem AFAIK. Jung-uk Kim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 8.1-PRERELEASE: CPU packages not detected correctly
On Friday 27 August 2010 03:36 pm, Jung-uk Kim wrote: [3] AMD is working on an SMT-capable CPU (code-named Bulldozer) and my patch won't work on them. If anyone has a Bulldozer sample, please look into it. I checked AMD website today and found out a new CPUID Spec. Rev. 2.34 was just released: http://support.amd.com/us/Embedded_TechDocs/25481.pdf They have added CPUID 0x801d and 0x801e to detect topology, it seems. Also, CPUID 0x8001 %ecx bit 22 (TopologyExtensions) tells you whether the above CPUID functions are supported. Interesting... Jung-uk Kim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 8.1-PRERELEASE: CPU packages not detected correctly
On Friday 27 August 2010 01:33 pm, Andriy Gapon wrote: on 19/08/2010 20:26 Jung-uk Kim said the following: One thing I am not sure is whether those CPUID instructions are executed on *real* CPUs or translated in HVM. On top of that, I am not even sure they will be executed on *correct* cores. I bet they won't. Hmm, I have an impression that we try to detect the topology by doing stuff only on BSP and that's why we handle properly only uniform topologies. So that would make your point about correct cores moot. Am I mistaken? No, you're correct. Here goes little background information. Originally, Jeff tried to implement Intel's algorithm[1] as described here, if my understanding is correct: http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/ Unfortunately, this algorithm needed to execute CPUID instruction on every core and aggregate them later. Thus, he had to compromise and made it simpler, I believe[2]. However, this compromise had some side effects and my patch was an attempt to correct them (sorry, I forgot the details). It was never committed because Jeff said I will look it over in more detail soon at the time. Then, I had to return the CPU, which was an engineering sample[3] and now in production. That's how my patch has been neglected for long time and just re-discovered from trashcan of rejected patches, thanks to this thread. ;-) Now, back to my original question. My point was, we should never trust any CPUIDs on emulated CPU if they are translated. What should happen if you have four physical cores and you assign just one for VirtualBox, for example? What should we announce if you are emulating two cores on UP host? How do we know whether it is the real BSP or not? Is it really bound to a CPU? Is CPUID leaf 11 emulated properly? If not, is it an emulator bug or a guest OS bug? Do we really care about physical topology in these cases? IMHO, the answer is no, we don't, and we should say all cores are independent. If anyone really cares and wants prettier printing, we may say N virtual cores, though. I hope it makes sense. Jung-uk Kim [1] I believe he referenced an older revision, though. [2] It was committed as r191648: http://svn.freebsd.org/viewvc/base?view=revisionrevision=191648 Also, this commit is related to kern/145385: http://www.freebsd.org/cgi/query-pr.cgi?pr=145385 [3] AMD is working on an SMT-capable CPU (code-named Bulldozer) and my patch won't work on them. If anyone has a Bulldozer sample, please look into it. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 8.1-PRERELEASE: CPU packages not detected correctly
On Friday 27 August 2010 03:47 pm, Andriy Gapon wrote: on 27/08/2010 22:36 Jung-uk Kim said the following: Now, back to my original question. My point was, we should never trust any CPUIDs on emulated CPU if they are translated. What should happen if you have four physical cores and you assign just one for VirtualBox, for example? What should we announce if you are emulating two cores on UP host? How do we know whether it is the real BSP or not? Is it really bound to a CPU? Is CPUID leaf 11 emulated properly? If not, is it an emulator bug or a guest OS bug? Do we really care about physical topology in these cases? IMHO, the answer is no, we don't, and we should say all cores are independent. If anyone really cares and wants prettier printing, we may say N virtual cores, though. Thanks a lot for the rest of the info that I snipped, very interesting and useful! To this issue - I'd say let the developers of virtual machines worry that their machines look like real hardware, not us. More specifically, in this thread we saw that current FreeBSD code (without the patch) and Intel's code detect the same topology and that topology looks reasonable for the person who started the thread. With the patch though, detected topology looks different. So I'd rather not worry about the general case of virtual machines right now. Let's first see more evidence of whether we should trust them or not. I quickly looked over Xen sources. It seems the CPUID instruction is translated by this code: http://lxr.xensource.com/lxr/source/tools/libxc/xc_cpuid_x86.c For HVM case, this is how the CPUID_HTT_CORES is set: 185 case 0x0001: 186 /* 187 * EBX[23:16] is Maximum Logical Processors Per Package. 188 * Update to reflect vLAPIC_ID = vCPU_ID * 2. 189 */ 190 regs[1] = (regs[1] 0xu) | ((regs[1] 0x007fu) 1); But CPUID 0x0b is not handled and falls here: 265 default: 266 regs[0] = regs[1] = regs[2] = regs[3] = 0; 267 break; I am not a Xen developer, so please don't shoot me. ;-) Jung-uk Kim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 8.1-PRERELEASE: CPU packages not detected correctly
On Friday 27 August 2010 05:25 pm, Andriy Gapon wrote: on 27/08/2010 23:18 pluknet said the following: First, sorry for late replay, and thanks Andriy for kicking me ;) Something really weird there . topo_probe_0xb() falls early on 1st iteration back to topo_probe_0x4(). topo_probe_0x4() returns incorrect data as well. topo_probe: cpu_high = b topo_probe: cpu_vendor_id = 8086 topo_probe_0xb: i = 0, p[1] = 0 topo_probe_0x4: cpu_procinfo = 200800 topo_probe_0x4: cpu_logical = 32 topo_probe_0x4: i = 0, type = 1 topo_probe_0x4: i = 0, level = 1 topo_probe_0x4: i = 0, logical = 1 topo_probe_0x4: i = 0, cores = 16 topo_probe_0x4: i = 1, type = 2 topo_probe_0x4: i = 1, level = 1 topo_probe_0x4: i = 1, logical = 1 topo_probe_0x4: i = 1, cores = 16 topo_probe_0x4: i = 2, type = 3 topo_probe_0x4: i = 2, level = 2 topo_probe_0x4: i = 2, logical = 1 topo_probe_0x4: i = 2, cores = 16 topo_probe#1: mp_ncpus = 3 topo_probe#1: cpu_cores = 1 topo_probe#1: cpu_logical = 32 topo_probe#1: hyperthreading_cpus = 32 topo_probe#2: mp_ncpus = 3 topo_probe#2: cpu_cores = 1 topo_probe#2: cpu_logical = 32 topo_probe#2: hyperthreading_cpus = 32 My interpretation: 1. Current (unpatched) code reports correct results either by a chance or because Jeff knows some magic patterns. cpu_high (CPUID_Leaf_Max in Intel's lingo) is 0xb, but CPUID.(EAX=11, ECX=0):EBX == 0, which means that we should fallback to 0x4 method. But the code doesn't do that and instead simply sets cpu_logical to 1 and cpu_cores stays zero, which is later translated to mp_ncpus, which happens to match the reality. 2. Intel reports correct results, because it properly probes the topology. It binds to each of the logical processors available and checks their APIC IDs against masks and builds topology info. 3. Patched code works incorrectly, because essentially it only calculates masks for CPU (and cache, for some reason) topology building. Instead of checking IDs against those masks, the code assumes numbers of cores and threads are at their maximum values allowed by the masks[*]. But that is not true and the numbers do not add up and we get that strange incorrect result. Yes, your interpretation is correct, I believe. Things like that probably do not happen with real hardware much, but they could. AFAIK, it never happened on a real hardware. The only way to deal with this is by following the correct procedure instead of making assumptions based on BSP. But that may be hard. Feel free to rewrite the patch. I never intended to commit the patch, any way. If I ever did, it was a year ago. :-) [*] E.g. that page says: CPUID.1:EBX[23:16] represents the maximum number of addressable IDs (initial APIC ID) that can be assigned to logical processors in a physical package. The value may not be the same as the number of logical processors that are present in the hardware of a physical package. The value of (1 + (CPUID.(EAX=4, ECX=0):EAX[31:26] )) represents the maximum number of addressable IDs (Core_ID) that can be used to enumerate different processor cores in a physical package. The value also can be different than the actual number of processor cores that are present in the hardware of a physical package. Yes, I already know that. Jung-uk Kim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 8.1-PRERELEASE: CPU packages not detected correctly
On Friday 27 August 2010 04:19 pm, Andriy Gapon wrote: I still don't get your point. My point is that if the Intel's code gets the topology right, then the hardware is emulated properly and the problem is with the patch. What is your point? :) My point is right topology means nothing in this context if CPU affinity of guest OS does not reflect hypervisor's point of view. Jung-uk Kim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 8.1-PRERELEASE: CPU packages not detected correctly
On Friday 27 August 2010 06:02 pm, Andriy Gapon wrote: on 28/08/2010 00:43 Jung-uk Kim said the following: Things like that probably do not happen with real hardware much, but they could. AFAIK, it never happened on a real hardware. The only way to deal with this is by following the correct procedure instead of making assumptions based on BSP. But that may be hard. Feel free to rewrite the patch. I never intended to commit the patch, any way. If I ever did, it was a year ago. :-) :-) BTW, it may be not that hard. It seems that 0x4 topology building involves knowing the masks and we already have that data (just interpreted differently), and APIC IDs of the CPUs and it seems that we also have that. We don't need to bind to CPUs to learn their IDs, we can just iterate over cpu_apic_ids[]. The only problem is that currently topo_probe() is called before assign_cpu_ids() which populates cpu_apic_ids. assign_cpu_ids depends on topo_probe to know hyperthreading_cpus value. So, either cpu_apic_ids could be split out or alternatively we could use cpu_info[] similarly to how it's done in topo_probe_0xb (skipping !cpu_present and cpu_disabled entries). If you are really up to this, it has to be a two-pass process. Even then, the dmesg won't be pretty because the topology can only be announced after all APs have been started. I mean, nobody's going to like to see a message like this from dmesg output: ... ACPI APIC Table: FOOBAR FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 --- 8 --- Snip several hundred lines! --- 8 --- SMP: AP CPU #1 Launched! FreeBSD/SMP: 1 package(s) x 2 core(s) Root mount waiting for: usbus5 usbus2 Root mount waiting for: usbus5 usbus2 ... In fact, I implemented something like that while I was writing the patch but I discarded it for an obvious reason. ;-) Also, don't forget jhb's work based on ACPI affinity tables. Jung-uk Kim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 8.1-PRERELEASE: CPU packages not detected correctly
On Friday 27 August 2010 06:46 pm, Andriy Gapon wrote: on 28/08/2010 01:33 Jung-uk Kim said the following: Also, don't forget jhb's work based on ACPI affinity tables. Not sure how they are applicable here. Only SRAT is implemented ATM but SLIT should provide CPU affinity information without messing with CPUID. In fact, I'd prefer that over messing with Intel's CPUID hacks, which gets messier whenever they release a new core. ;-) Jung-uk Kim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 8.1-PRERELEASE: CPU packages not detected correctly
On Thursday 19 August 2010 12:56 pm, pluknet wrote: On 19 August 2010 20:39, Andriy Gapon a...@icyb.net.ua wrote: on 10/08/2010 19:55 pluknet said the following: On 16 July 2010 19:47, Jung-uk Kim j...@freebsd.org wrote: The patch should apply fine on both sys/amd64/amd64/mp_machdep.c and sys/i386/i386/mp_machdep.c. http://people.freebsd.org/~jkim/mp_machdep2.diff Hi. Just checked on Xen HVM with 3 cores. 1) 8.1 unmodified: FreeBSD/SMP: Multiprocessor System Detected: 3 CPUs FreeBSD/SMP: 1 package(s) x 3 core(s) 2) 8.1 + patch FreeBSD/SMP: Multiprocessor System Detected: 3 CPUs FreeBSD/SMP: 0 package(s) x 1 core(s) x 32 HTT threads WARNING: Non-uniform processors. WARNING: Using suboptimal topology. Can you debug, e.g. with printfs, what exactly goes wrong? I wonder if in this case code follows some unusual/unexpected path. Sorry, I'm a bit busy right now. I hope to debug this somewhere in the next week. BTW, could you please also provide CPU name/model/features as detected by the kernel? Sure. CPU: Intel(R) Xeon(R) CPU E5520 @ 2.27GHz (2763.12-MHz 686-class CPU) Origin = GenuineIntel Id = 0x106a5 Family = 6 Model = 1a Stepping = 5 Features=0x1781fbbfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8,APIC,SEP,MTRR,PG E,MCA,CMOV,PAT,MMX,FXSR,SSE,SSE2,HTT Features2=0x80982201SSE3,SSSE3,CX16,SSE4.1,SSE4.2,POPCNT,b31 TSC: P-state invariant real memory = 4194304000 (4000 MB) avail memory = 3932786688 (3750 MB) ACPI APIC Table: Xen HVM FreeBSD/SMP: Multiprocessor System Detected: 3 CPUs FreeBSD/SMP: 0 package(s) x 1 core(s) x 32 HTT threads cpu0 (BSP): APIC ID: 0 cpu1 (AP/HT): APIC ID: 2 cpu2 (AP/HT): APIC ID: 4 Just a thought. # HTT might somehow correlate with current maxcpus limit (32). One thing I am not sure is whether those CPUID instructions are executed on *real* CPUs or translated in HVM. On top of that, I am not even sure they will be executed on *correct* cores. I bet they won't. If that's the case, we should add exception for virtualized environment as we did for default HZ. Jung-uk Kim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 8.1-PRERELEASE: CPU packages not detected correctly
On Thursday 19 August 2010 03:30 pm, pluknet wrote: On 19 August 2010 21:26, Jung-uk Kim j...@freebsd.org wrote: On Thursday 19 August 2010 12:56 pm, pluknet wrote: On 19 August 2010 20:39, Andriy Gapon a...@icyb.net.ua wrote: on 10/08/2010 19:55 pluknet said the following: On 16 July 2010 19:47, Jung-uk Kim j...@freebsd.org wrote: The patch should apply fine on both sys/amd64/amd64/mp_machdep.c and sys/i386/i386/mp_machdep.c. http://people.freebsd.org/~jkim/mp_machdep2.diff Hi. Just checked on Xen HVM with 3 cores. 1) 8.1 unmodified: FreeBSD/SMP: Multiprocessor System Detected: 3 CPUs FreeBSD/SMP: 1 package(s) x 3 core(s) 2) 8.1 + patch FreeBSD/SMP: Multiprocessor System Detected: 3 CPUs FreeBSD/SMP: 0 package(s) x 1 core(s) x 32 HTT threads WARNING: Non-uniform processors. WARNING: Using suboptimal topology. Can you debug, e.g. with printfs, what exactly goes wrong? I wonder if in this case code follows some unusual/unexpected path. Sorry, I'm a bit busy right now. I hope to debug this somewhere in the next week. BTW, could you please also provide CPU name/model/features as detected by the kernel? Sure. CPU: Intel(R) Xeon(R) CPU � � � � � E5520 �@ 2.27GHz (2763.12-MHz 686-class CPU) Origin = GenuineIntel �Id = 0x106a5 �Family = 6 Model = 1a �Stepping = 5 Features=0x1781fbbfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8,APIC,SEP,MTRR ,PG E,MCA,CMOV,PAT,MMX,FXSR,SSE,SSE2,HTT Features2=0x80982201SSE3,SSSE3,CX16,SSE4.1,SSE4.2,POPCNT,b31 TSC: P-state invariant real memory �= 4194304000 (4000 MB) avail memory = 3932786688 (3750 MB) ACPI APIC Table: Xen HVM FreeBSD/SMP: Multiprocessor System Detected: 3 CPUs FreeBSD/SMP: 0 package(s) x 1 core(s) x 32 HTT threads �cpu0 (BSP): APIC ID: �0 �cpu1 (AP/HT): APIC ID: �2 �cpu2 (AP/HT): APIC ID: �4 Just a thought. �# HTT might somehow correlate with current maxcpus limit (32). One thing I am not sure is whether those CPUID instructions are executed on *real* CPUs or translated in HVM. I may add only that b31 of Features2 presents only in Xen HVM environment, and its role is afaik to indicate a Xen guest mode. There is no any mention of this bit in the latest Intel doc (ie it's reserved/unused). Ah, that means the HVM is actually translating the instruction, not running directly on the CPU. That means, we cannot use any CPUID instructions for topology detection in HVM. And I bet all MSRs will be translated as well. It is not just HVM, but also any emulations and virtualizations in general. Actually, CPU topology detection does nothing in these environments because hypervisor or whatever will do memory translations and stuff unless some hints are given by guest or ballooning is done for virtual devices and resources. Usually, this kind of problem is handled by VM-specific device drivers, e.g., VirtualBox Guest Additions, VMware Tools, etc. In theory, Xen domU should do much better job than these tools because it is specifically modified to handle these problems without losing performance. Also, at least NetBSD has a special handling of this bit. See commit log for CPUID2_RAZ in sys/arch/x86/include/specialreg.h, 1.37 FWIW RAZ states for reserved and zero or so. Hmm... Interesting. But we should never rely on an undocumented bit to identify HVM or whatever. Thanks for the info, Jung-uk Kim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ts_to_ct flood on 8.1-STABLE
On Friday 13 August 2010 06:50 pm, Andrew J. Caines wrote: Jeremy, Thanks for the quick response. The source/responsible code for the printing is in function clock_ts_to_ct() in: src/sys/kern/subr_clock.c I took a look at the code in an attempt to divine the reason for the frequent messages, without success. Any idea why I see so many? I'm not aware of any special timing related configuration. I do run ntpd, of course. In examples I've found, others seem to get just the one ts_to_ct message. 52 #define ct_debug bootverbose Are your systems booting verbosely? By default, yes. I'd like to keep it that way without having to hack the source. Is there another option? If you are really annoyed by the messages, you may increase 'machdep.rtc_save_period' sysctl value to something larger. Default is 1,800 seconds or 30 minutes. Also, you can completely disable it by setting it to zero or 'machdep.disable_rtc_set' to non-zero value but I would not recommend it. Still, it doesn't explain why you are seeing the message more often, however. :-( Jung-uk Kim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Strange video mode output with VESA
On Friday 16 July 2010 07:18 pm, Jung-uk Kim wrote: On Friday 16 July 2010 03:22 pm, Jung-uk Kim wrote: On Friday 16 July 2010 03:00 pm, David DEMELIER wrote: 2010/6/19 paradox ddkp...@yahoo.com: On Wednesday 02 June 2010 04:25 pm, David DEMELIER wrote: Hi there, I was so happy to see that VESA is available for amd64, but unfortunately it does not work really well for me. Take a look at this picture : http://img717.imageshack.us/img717/7311/dsc00399h.jpg My laptop is a 15,6 so the best resolution is 1366x768, I tried this : vidcontrol MODE_496. As you can see on the picture all : the lines are completely everywhere, if I mouse the cursor they move away (I'm not drunk!). I have SC_PIXEL_MODE in my kernel config. The console terminal is okay until I don't excess 1280x960x32 video mode. Do you have any idea to fix this ? It is kinda known problem. �If the mode has larger bytes per scan line than the minimum, few characters per line are lost when the screen is scrolled up or down, i.e., framebuffer copies of whole screen. �When you move the mouse onto the line, entire line is redrawn and restored. �That's what you are seeing. �Ed might have a better idea how to fix it (CC'ed). Jung-uk Kim this is incorrent calculate the scan lines in the vesa driver Jung-uk Kim should to fix it But Jung-uk Kim said Ed' should fix it so we are in an infinite loop :- No, I didn't say that. What I meant was Ed may be a better qualified person to fix syscons vs. terminal emulator interaction issues. :-( Can you please try the attached patch? FYI, I just went ahead and committed a (slightly better) patch on head as r210248. It will be MFC'ed soon. Jung-uk Kim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 8.1-PRERELEASE: CPU packages not detected correctly
On Thursday 15 July 2010 09:34 pm, David Xu wrote: Jung-uk Kim wrote: On Wednesday 14 July 2010 05:40 pm, Jung-uk Kim wrote: On Wednesday 14 July 2010 01:31 pm, Andriy Gapon wrote: on 14/07/2010 17:14 Oliver Fromme said the following: In a machine installed yesterday, 8.1-PRERELEASE doesn't seem to detect the number of CPU packages vs. cores per package correctly: | FreeBSD 8.1-PRERELEASE-20100713 #0: Tue Jul 13 19:51:18 UTC | 2010 [...] | CPU: Intel(R) Xeon(R) CPU L5408 @ 2.13GHz | (2133.42-MHz K8-class CPU) Origin = GenuineIntel Id = | 0x1067a Family = 6 Model = 17 Stepping = 10 | Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC |, SE | P,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE |, SSE 2,SS,HTT,TM,PBE | Features2=0x40ce3bdSSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE |3 ,C X16,xTPR,PDCM,DCA,SSE4.1,XSAVE AMD | Features=0x2800SYSCALL,LM | AMD Features2=0x1LAHF | TSC: P-state invariant | real memory = 34359738368 (32768 MB) | avail memory = 33151377408 (31615 MB) | ACPI APIC Table: IBMSERBLADE | FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs | FreeBSD/SMP: 1 package(s) x 8 core(s) | cpu0 (BSP): APIC ID: 0 | cpu1 (AP): APIC ID: 1 | cpu2 (AP): APIC ID: 2 | cpu3 (AP): APIC ID: 3 | cpu4 (AP): APIC ID: 4 | cpu5 (AP): APIC ID: 5 | cpu6 (AP): APIC ID: 6 | cpu7 (AP): APIC ID: 7 | ioapic1 Version 2.0 irqs 24-47 on motherboard | ioapic0 Version 2.0 irqs 0-23 on motherboard I'm pretty sure that this is a 2 x 4 machine (2 CPU packages with 4 cores per package), not 1 x 8. That's what the BIOS displays during POST. I'm not sure if this is just a cosmetic issue, or if this is a critical thing ... I could imagine that performance might be sub-optimal if the CPU topology isn't detected correctly, but I'm not sure if FreeBSD can take advantage of the topology. Could you please try to do the following? 1. Fetch topo-12212009.tar from the top of this page: http://software.intel.com/en-us/articles/intel-64-architecture- pr oc essor-topology-enumeration/ 2. Untar it and apply this patch to the code: http://people.freebsd.org/~avg/cpu-topology.diff 3. Compile it by running sh mk_64.sh (supposing you have amd64 system installed) 4. Run cpu_topology64.out and report back its output. It's funny that I actually wrote a convenience script (and cleaned up today): http://people.freebsd.org/~jkim/cpu_topology-12212009.sh BTW, current topology detection code is not optimal for some Intel processors if my memory serves. Surprisingly, I found a patch I wrote last year from /tmp of my desktop and it is still applied cleanly. 8-) Just in case, it is available from here: http://people.freebsd.org/~jkim/mp_machdep.diff It is applicable to both sys/amd64/amd64/mp_machdep.c and sys/i386/i386/mp_machdep.c. I have to warn you, though, it hasn't been used for more than a year, so it may not work at all. ;-) Jung-uk Kim Do you have patch for i386 branch ? I want to test. The patch should apply fine on both sys/amd64/amd64/mp_machdep.c and sys/i386/i386/mp_machdep.c. http://people.freebsd.org/~jkim/mp_machdep2.diff On my Pentium-D machine: $ sysctl kern.sched.topology_spec kern.sched.topology_spec: groups group level=1 cache-level=0 cpu count=2 mask=0x30, 1/cpu flags/flags children group level=3 cache-level=2 cpu count=2 mask=0x30, 1/cpu flags/flags /group /children /group /groups it seems the kernel thinks that the Pentuim-D is sharing L2 cache, but in fact, the design of the Pentium Ds was simply two P4 cores sitting side by side. They do not share anything and they basically work independently. cpu_topo() in mp_machdep.c is not that smart to distinguish whether two cores in one package is sharing L2 cache or not: /* * Only HTT no multi-core. */ if (cpu_logical 1 cpu_cores == 1) return (smp_topo_1level(CG_SHARE_L1, cpu_logical, cg_flags)); /* * Only multi-core no HTT. */ if (cpu_cores 1 cpu_logical == 1) return (smp_topo_1level(CG_SHARE_L2, cpu_cores, cg_flags)); /* * Both HTT and multi-core. */ return (smp_topo_2level(CG_SHARE_L2, cpu_cores, CG_SHARE_L1, cpu_logical, cg_flags)); In other words, if one package contains multiple cores, it is *assumed* sharing L2 cache. The same is true for HTT/SMT case (i.e., assumed sharing L1 cache). It does not care about L3 cache at all. Yes, we need some improvement in this area. Jung-uk Kim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 8.1-PRERELEASE: CPU packages not detected correctly
On Friday 16 July 2010 03:55 am, Jeremy Chadwick wrote: On Thu, Jul 15, 2010 at 10:01:48PM +0200, Oliver Fromme wrote: Jung-uk Kim wrote: On Thursday 15 July 2010 01:56 pm, Andriy Gapon wrote: on 15/07/2010 19:57 Oliver Fromme said the following: I patched topo_probe() so it calls topo_probe_0x4() after topo_probe_0xb() if cpu_cores is still 0. I think this is a better fallback procedure. With this patch, cpu_cores gets the value 4 which is the correct one, finally: [...] I think that your addition achieves this effect, perhaps just not as explicitly as I would preferred. Jung-uk, what do you think? Yes, you're right. Please try new patch: http://people.freebsd.org/~jkim/mp_machdep2.diff Thank you! I will have access to that particular machine on Monday again, so testing the new patch will have to wait until Monday. But from looking at your patch it should have the same result as my simpler patch, so it should work fine. I have a general question for everyone involved in this thread (which is highly educational/interesting -- thank you for all the info!): Does the problem reported affect actual performance/behaviour of FreeBSD kernel-wise at all, or is it just a cosmetical issue with regards to showing how many cores/threads there are? Theoretically there is behavioral changes from scheduler. jeff@ should be able to tell you more about this. Jung-uk Kim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Strange video mode output with VESA
On Friday 16 July 2010 03:00 pm, David DEMELIER wrote: 2010/6/19 paradox ddkp...@yahoo.com: On Wednesday 02 June 2010 04:25 pm, David DEMELIER wrote: Hi there, I was so happy to see that VESA is available for amd64, but unfortunately it does not work really well for me. Take a look at this picture : http://img717.imageshack.us/img717/7311/dsc00399h.jpg My laptop is a 15,6 so the best resolution is 1366x768, I tried this : vidcontrol MODE_496. As you can see on the picture all the : lines are completely everywhere, if I mouse the cursor they move away (I'm not drunk!). I have SC_PIXEL_MODE in my kernel config. The console terminal is okay until I don't excess 1280x960x32 video mode. Do you have any idea to fix this ? It is kinda known problem. ��If the mode has larger bytes per scan line than the minimum, few characters per line are lost when the screen is scrolled up or down, i.e., framebuffer copies of whole screen. ��When you move the mouse onto the line, entire line is redrawn and restored. ��That's what you are seeing. ��Ed might have a better idea how to fix it (CC'ed). Jung-uk Kim this is incorrent calculate the scan lines in the vesa driver Jung-uk Kim should to fix it But Jung-uk Kim said Ed' should fix it so we are in an infinite loop :- No, I didn't say that. What I meant was Ed may be a better qualified person to fix syscons vs. terminal emulator interaction issues. :-( Jung-uk Kim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Strange video mode output with VESA
On Friday 16 July 2010 03:22 pm, Jung-uk Kim wrote:
On Friday 16 July 2010 03:00 pm, David DEMELIER wrote:
2010/6/19 paradox ddkp...@yahoo.com:
On Wednesday 02 June 2010 04:25 pm, David DEMELIER wrote:
Hi there,
I was so happy to see that VESA is available for amd64, but
unfortunately it does not work really well for me. Take a
look at this picture :
http://img717.imageshack.us/img717/7311/dsc00399h.jpg
My laptop is a 15,6 so the best resolution is 1366x768, I
tried this
: vidcontrol MODE_496. As you can see on the picture all the
: lines are
completely everywhere, if I mouse the cursor they move away
(I'm not drunk!).
I have SC_PIXEL_MODE in my kernel config.
The console terminal is okay until I don't excess 1280x960x32
video mode.
Do you have any idea to fix this ?
It is kinda known problem. 占쏙옙If the mode has larger bytes per
scan line than the minimum, few characters per line are lost
when the screen is scrolled up or down, i.e., framebuffer
copies of whole screen. 占쏙옙When you move the mouse onto the
line, entire line is redrawn and restored. 占쏙옙That's what you
are seeing. 占쏙옙Ed might have a better idea how to fix it
(CC'ed).
Jung-uk Kim
this is incorrent calculate the scan lines in the vesa driver
Jung-uk Kim should to fix it
But Jung-uk Kim said Ed' should fix it so we are in an infinite
loop :-
No, I didn't say that. What I meant was Ed may be a better
qualified person to fix syscons vs. terminal emulator interaction
issues. :-(
Can you please try the attached patch?
--- sys/dev/syscons/scvgarndr.c 2010-03-24 11:40:18.0 -0400
+++ sys/dev/syscons/scvgarndr.c 2010-07-16 19:05:12.0 -0400
@@ -728,12 +728,15 @@
vm_offset_t e;
u_char *f;
u_short col1, col2, color;
- int line_width, pixel_size;
+ int line_width, off_width;
+ int font_size, pixel_size;
int i, j, k;
int a;
line_width = scp-sc-adp-va_line_width;
pixel_size = scp-sc-adp-va_info.vi_pixel_size;
+ off_width = line_width - scp-xpixel * pixel_size;
+ font_size = scp-font_size;
d = VIDEO_MEMORY_POS(scp, from, 8 * pixel_size);
@@ -752,9 +755,9 @@
}
e = d;
- f = (scp-font[sc_vtb_getc(scp-vtb, i) * scp-font_size]);
+ f = (scp-font[sc_vtb_getc(scp-vtb, i) * font_size]);
- for (j = 0; j scp-font_size; ++j, ++f) {
+ for (j = 0; j font_size; ++j, ++f) {
for (k = 0; k 8; ++k) {
color = *f (1 (7 - k)) ? col1 : col2;
vga_drawpxl(e + pixel_size * k, color);
@@ -766,8 +769,8 @@
d += 8 * pixel_size;
if ((i % scp-xsize) == scp-xsize - 1)
- d += scp-xoff * 16 * pixel_size +
-(scp-font_size - 1) * line_width;
+ d += off_width + scp-xoff * pixel_size * font_size +
+ (font_size - 1) * line_width;
}
}
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 8.1-PRERELEASE: CPU packages not detected correctly
On Thursday 15 July 2010 01:56 pm, Andriy Gapon wrote:
on 15/07/2010 19:57 Oliver Fromme said the following:
In topo_probe(), cpu_high is 0xd, so topo_probe_0xb() is
called. But the cpuid 0xb instruction doesn't seem to
return useful data: All values are zero already in the
first level, so cpu_cores remains 0.
Back in topo_probe(), there is a fallback if cpu_cores is
stil 0: It assigns mp_ncpu to cpu_cores, so it gets 8
which is wrong.
I patched topo_probe() so it calls topo_probe_0x4() after
topo_probe_0xb() if cpu_cores is still 0. I think this
is a better fallback procedure. With this patch, cpu_cores
gets the value 4 which is the correct one, finally:
FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs
FreeBSD/SMP: 2 package(s) x 4 core(s)
Thank you for debugging this issue!
Not sure if this is the best patch that there can be, but its
direction is definitely correct.
As the Intel document says (translated to our x86 mp_machdep.c
terms): if cpu_high = 0xb then we should execute cpuid_count(0xb,
0, p) and examine EBX value (p[1]), only if it's non-zero should we
proceed with topo_probe_0xb(), otherwise we should fall back to
topo_probe_0x4, etc.
I think that your addition achieves this effect, perhaps just not
as explicitly as I would preferred.
Jung-uk, what do you think?
Yes, you're right. Please try new patch:
http://people.freebsd.org/~jkim/mp_machdep2.diff
Thanks,
Jung-uk Kim
This is the patch, it's against jkim's patched version:
@@ -265,7 +268,7 @@
else if (cpu_vendor_id == CPU_VENDOR_INTEL) {
if (cpu_high = 0xb)
topo_probe_0xb();
- else if (cpu_high = 0x4)
+ if (cpu_high = 0x4 cpu_cores == 0)
topo_probe_0x4();
}
if (cpu_cores == 0)
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 8.1-PRERELEASE: CPU packages not detected correctly
On Thursday 15 July 2010 03:07 pm, Jung-uk Kim wrote: On Thursday 15 July 2010 01:56 pm, Andriy Gapon wrote: on 15/07/2010 19:57 Oliver Fromme said the following: In topo_probe(), cpu_high is 0xd, so topo_probe_0xb() is called. But the cpuid 0xb instruction doesn't seem to return useful data: All values are zero already in the first level, so cpu_cores remains 0. Back in topo_probe(), there is a fallback if cpu_cores is stil 0: It assigns mp_ncpu to cpu_cores, so it gets 8 which is wrong. I patched topo_probe() so it calls topo_probe_0x4() after topo_probe_0xb() if cpu_cores is still 0. I think this is a better fallback procedure. With this patch, cpu_cores gets the value 4 which is the correct one, finally: FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs FreeBSD/SMP: 2 package(s) x 4 core(s) Thank you for debugging this issue! Not sure if this is the best patch that there can be, but its direction is definitely correct. As the Intel document says (translated to our x86 mp_machdep.c terms): if cpu_high = 0xb then we should execute cpuid_count(0xb, 0, p) and examine EBX value (p[1]), only if it's non-zero should we proceed with topo_probe_0xb(), otherwise we should fall back to topo_probe_0x4, etc. I think that your addition achieves this effect, perhaps just not as explicitly as I would preferred. Jung-uk, what do you think? Yes, you're right. Please try new patch: http://people.freebsd.org/~jkim/mp_machdep2.diff I uploaded the patch again, it's compile-tested this now. Sorry, if anyone has downloaded it few minutes ago. Jung-uk Kim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 8.1-PRERELEASE: CPU packages not detected correctly
On Wednesday 14 July 2010 01:31 pm, Andriy Gapon wrote: on 14/07/2010 17:14 Oliver Fromme said the following: In a machine installed yesterday, 8.1-PRERELEASE doesn't seem to detect the number of CPU packages vs. cores per package correctly: | FreeBSD 8.1-PRERELEASE-20100713 #0: Tue Jul 13 19:51:18 UTC | 2010 [...] | CPU: Intel(R) Xeon(R) CPU L5408 @ 2.13GHz | (2133.42-MHz K8-class CPU) Origin = GenuineIntel Id = | 0x1067a Family = 6 Model = 17 Stepping = 10 | Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SE |P,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE |2,SS,HTT,TM,PBE | Features2=0x40ce3bdSSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,C |X16,xTPR,PDCM,DCA,SSE4.1,XSAVE AMD | Features=0x2800SYSCALL,LM | AMD Features2=0x1LAHF | TSC: P-state invariant | real memory = 34359738368 (32768 MB) | avail memory = 33151377408 (31615 MB) | ACPI APIC Table: IBMSERBLADE | FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs | FreeBSD/SMP: 1 package(s) x 8 core(s) | cpu0 (BSP): APIC ID: 0 | cpu1 (AP): APIC ID: 1 | cpu2 (AP): APIC ID: 2 | cpu3 (AP): APIC ID: 3 | cpu4 (AP): APIC ID: 4 | cpu5 (AP): APIC ID: 5 | cpu6 (AP): APIC ID: 6 | cpu7 (AP): APIC ID: 7 | ioapic1 Version 2.0 irqs 24-47 on motherboard | ioapic0 Version 2.0 irqs 0-23 on motherboard I'm pretty sure that this is a 2 x 4 machine (2 CPU packages with 4 cores per package), not 1 x 8. That's what the BIOS displays during POST. I'm not sure if this is just a cosmetic issue, or if this is a critical thing ... I could imagine that performance might be sub-optimal if the CPU topology isn't detected correctly, but I'm not sure if FreeBSD can take advantage of the topology. Could you please try to do the following? 1. Fetch topo-12212009.tar from the top of this page: http://software.intel.com/en-us/articles/intel-64-architecture-proc essor-topology-enumeration/ 2. Untar it and apply this patch to the code: http://people.freebsd.org/~avg/cpu-topology.diff 3. Compile it by running sh mk_64.sh (supposing you have amd64 system installed) 4. Run cpu_topology64.out and report back its output. It's funny that I actually wrote a convenience script (and cleaned up today): http://people.freebsd.org/~jkim/cpu_topology-12212009.sh BTW, current topology detection code is not optimal for some Intel processors if my memory serves. Jung-uk Kim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 8.1-PRERELEASE: CPU packages not detected correctly
On Wednesday 14 July 2010 05:40 pm, Jung-uk Kim wrote: On Wednesday 14 July 2010 01:31 pm, Andriy Gapon wrote: on 14/07/2010 17:14 Oliver Fromme said the following: In a machine installed yesterday, 8.1-PRERELEASE doesn't seem to detect the number of CPU packages vs. cores per package correctly: | FreeBSD 8.1-PRERELEASE-20100713 #0: Tue Jul 13 19:51:18 UTC | 2010 [...] | CPU: Intel(R) Xeon(R) CPU L5408 @ 2.13GHz | (2133.42-MHz K8-class CPU) Origin = GenuineIntel Id = | 0x1067a Family = 6 Model = 17 Stepping = 10 | Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC, |SE | P,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE, |SSE 2,SS,HTT,TM,PBE | Features2=0x40ce3bdSSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3 |,C X16,xTPR,PDCM,DCA,SSE4.1,XSAVE AMD | Features=0x2800SYSCALL,LM | AMD Features2=0x1LAHF | TSC: P-state invariant | real memory = 34359738368 (32768 MB) | avail memory = 33151377408 (31615 MB) | ACPI APIC Table: IBMSERBLADE | FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs | FreeBSD/SMP: 1 package(s) x 8 core(s) | cpu0 (BSP): APIC ID: 0 | cpu1 (AP): APIC ID: 1 | cpu2 (AP): APIC ID: 2 | cpu3 (AP): APIC ID: 3 | cpu4 (AP): APIC ID: 4 | cpu5 (AP): APIC ID: 5 | cpu6 (AP): APIC ID: 6 | cpu7 (AP): APIC ID: 7 | ioapic1 Version 2.0 irqs 24-47 on motherboard | ioapic0 Version 2.0 irqs 0-23 on motherboard I'm pretty sure that this is a 2 x 4 machine (2 CPU packages with 4 cores per package), not 1 x 8. That's what the BIOS displays during POST. I'm not sure if this is just a cosmetic issue, or if this is a critical thing ... I could imagine that performance might be sub-optimal if the CPU topology isn't detected correctly, but I'm not sure if FreeBSD can take advantage of the topology. Could you please try to do the following? 1. Fetch topo-12212009.tar from the top of this page: http://software.intel.com/en-us/articles/intel-64-architecture-pr oc essor-topology-enumeration/ 2. Untar it and apply this patch to the code: http://people.freebsd.org/~avg/cpu-topology.diff 3. Compile it by running sh mk_64.sh (supposing you have amd64 system installed) 4. Run cpu_topology64.out and report back its output. It's funny that I actually wrote a convenience script (and cleaned up today): http://people.freebsd.org/~jkim/cpu_topology-12212009.sh BTW, current topology detection code is not optimal for some Intel processors if my memory serves. Surprisingly, I found a patch I wrote last year from /tmp of my desktop and it is still applied cleanly. 8-) Just in case, it is available from here: http://people.freebsd.org/~jkim/mp_machdep.diff It is applicable to both sys/amd64/amd64/mp_machdep.c and sys/i386/i386/mp_machdep.c. I have to warn you, though, it hasn't been used for more than a year, so it may not work at all. ;-) Jung-uk Kim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD 8.1-PRERELEASE: WARNING ioctl sign-extension ioctl ffffffff8004667e
On Tuesday 29 June 2010 12:46 pm, Mario Sergio Fujikawa Ferreira wrote: Quoting Jung-uk Kim j...@freebsd.org: On Monday 28 June 2010 02:01 pm, Jung-uk Kim wrote: Please drop the attached patch in ports/devel/boost-libs/files, rebuild all dependencies, and try your deluge ports again[1]. Please ignore the previous patch and try this one. Sorry, there was a typo. :-( I updated boost-libs with your patch which fixed the issue. I no longer have the ioctl warning. :) 1) I rebuilt the libtorrent-rasterbar-14 then libtorrent-rasterbar-14-python. 2) Tried deluge, there were warnings still. 3) Then, rebuilt deluge. 4) Tried deluge, warnings were gone. I still have the lang/python26 patches you sent earlier. So I have both the python and boost-libs patches on my system. Do you want to me to do any further testing? No, that should be good enough. Thanks for testing my patches! Jung-uk Kim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD 8.1-PRERELEASE: WARNING ioctl sign-extension ioctl ffffffff8004667e
On Saturday 26 June 2010 05:09 am, Mario Sergio Fujikawa Ferreira
wrote:
On 25/06/2010 18:58, Jung-uk Kim wrote:
On Friday 25 June 2010 04:54 am, Mario Sergio Fujikawa Ferreira
wrote:
On Wed, Jun 23, 2010 at 05:08:38PM -0400, Jung-uk Kim wrote:
Date: Wed, 23 Jun 2010 17:08:38 -0400
From: Jung-uk Kimj...@freebsd.org
To: freebsd-stable@FreeBSD.org
Cc: d...@delphij.net, Mario Sergio Fujikawa Ferreira
li...@freebsd.org Subject: Re: FreeBSD 8.1-PRERELEASE:
WARNING ioctl sign-extension ioctl 8004667e
User-Agent: KMail/1.6.2
On Wednesday 23 June 2010 03:38 pm, Jung-uk Kim wrote:
On Wednesday 23 June 2010 03:10 pm, Jung-uk Kim wrote:
On Wednesday 23 June 2010 03:01 pm, Jung-uk Kim wrote:
On Wednesday 23 June 2010 02:41 pm, Xin LI wrote:
On 2010/06/23 11:37, Jung-uk Kim wrote:
On Wednesday 23 June 2010 02:12 pm, Xin LI wrote:
Hi,
On 2010/06/22 19:58, Mario Sergio Fujikawa Ferreira
wrote:
Hi,
I am getting more than 4 thousand of the following
messages a day:
WARNING pid 24509 (python2.6): ioctl sign-extension
ioctl 8004667e
[...]
I think we may need to check the code and patch it.
Basically this means that python (or some .so modules)
passed an int or unsigned int as parameter 'cmd', we
need to change it to unsigned long.
The warning itself should be harmless to my best of
knowledge, one can probably remove the printf in
kernel source code as a workaround.
By the way it seems to be a POSIX violation and we
didn't seem to really use so wide cmd, but I have not
yet verified everything myself.
Long time ago, I had a similar problem with termios
TIOCGWINSZ and we patched the port like this:
http://www.freebsd.org/cgi/cvsweb.cgi/ports/lang/python
/fil es /A tt
ic/patch-Modules%3A%3Afcntlmodule.c?rev=1.1;content-typ
e=te xt %2 Fpl ain
I believe it was upstream patched at the time but I
won't be surprised if something similar was
reintroduced. It happens when a Python internal
integer type is converted to a native unsigned long.
Well, only *BSD have cmd a long value so it's likely that
it would be reintroduced.
Yes, that's what I mean.
I have checked the 4.4BSD archive and understood that our
ioctl's cmd parameter was made long around 1991 or 1992s
but didn't see what it actually buy us...
Like it or not, it is too late to revert. :-(
From Python 2.6.5:
static PyObject *
fcntl_ioctl(PyObject *self, PyObject *args)
{
#define IOCTL_BUFSZ 1024
int fd;
/* In PyArg_ParseTuple below, we use the unsigned
non-checked 'I' format for the 'code' parameter because
Python turns 0x800 into either a large positive number
(PyLong or PyInt on 64-bit platforms) or a negative number on
others (32-bit PyInt) whereas the system expects it to be a
32bit bit field value regardless of it being passed as an int
or unsigned long on various platforms. See the
termios.TIOCSWINSZ constant across platforms for an example
of thise.
If any of the 64bit platforms ever decide to use more
than 32bits in their unsigned long ioctl codes this will
break and need special casing based on the platform being
built on. */
unsigned int code;
...
It is still a kludge and it won't be fixed. :-(
Please drop the attached patch in ports/lang/python26/files
and test. Note I am not a Python guy, so please don't shoot
me. ;-)
I found that Python guys added 'k' format since 2.3, which
converts a Python integer to unsigned long. Please ignore the
previous patch and try the attached patch instead.
Unfortunately it didn't work.
1) Added patch to lang/python26
2) Recompiled lang/python26
3) cd /var/db/ports portupgrade -f python* py26* deluge*
Restarted deluge afterwards. The message is still there:
Jun 25 05:49:38 exxodus kernel: WARNING pid 38635 (python2.6):
ioctl sign-extension ioctl 8004667e
It may be a deeper problen, then. :-(
First of all, I cannot reproduce the problem because deluged
dumps core on my box and I gave it up. Just staring at the code,
it seems they rely on a bundled libtorrent for Python binding and
the libtorrent relies on Boost, in turn. Then, the actual
non-blocking socket implementation is done with Boost ASIO[1].
It is possible that there are more complicated problems between
these and the Python binding. In fact, I can see a lot of these:
int name() const
{
return FIONBIO;
}
...
if (!ec command.name() == static_castint(FIONBIO))
...
socket_ops::ioctl(impl.socket_, command.name(), ...)
...
They are just assuming it is an int type, I guess.
Sigh, what a mess...
Given that your python patch is a step on the right direction, I
would propose that it be further tested and then committed if
possible.
[1] Boost and its Python binding from ports seems to be a newer
Re: FreeBSD 8.1-PRERELEASE: WARNING ioctl sign-extension ioctl ffffffff8004667e
On Monday 28 June 2010 02:01 pm, Jung-uk Kim wrote:
Please drop the attached patch in ports/devel/boost-libs/files,
rebuild all dependencies, and try your deluge ports again[1].
Please ignore the previous patch and try this one. Sorry, there was a
typo. :-(
Jung-uk Kim
--- boost/asio/detail/io_control.hpp.orig 2010-01-04 04:36:00.0
-0500
+++ boost/asio/detail/io_control.hpp2010-06-25 18:38:28.0 -0400
@@ -46,7 +46,7 @@ public:
}
// Get the name of the IO control command.
- int name() const
+ ioctl_cmd_type name() const
{
return FIONBIO;
}
@@ -96,7 +96,7 @@ public:
}
// Get the name of the IO control command.
- int name() const
+ ioctl_cmd_type name() const
{
return FIONREAD;
}
--- boost/asio/detail/reactive_descriptor_service.hpp.orig 2010-06-25
18:24:52.0 -0400
+++ boost/asio/detail/reactive_descriptor_service.hpp 2010-06-25
18:56:32.0 -0400
@@ -223,7 +223,7 @@ public:
// descriptor is put into the state that has been requested by the user. If
// the ioctl syscall was successful then we need to update the flags to
// match.
-if (!ec command.name() == static_castint(FIONBIO))
+if (!ec command.name() == static_castioctl_cmd_type(FIONBIO))
{
if (*static_castioctl_arg_type*(command.data()))
{
--- boost/asio/detail/reactive_socket_service.hpp.orig 2010-04-07
04:44:41.0 -0400
+++ boost/asio/detail/reactive_socket_service.hpp 2010-06-25
18:55:06.0 -0400
@@ -453,7 +453,7 @@ public:
// already in the correct state. This ensures that the underlying socket
// is put into the state that has been requested by the user. If the ioctl
// syscall was successful then we need to update the flags to match.
-if (!ec command.name() == static_castint(FIONBIO))
+if (!ec command.name() == static_castioctl_cmd_type(FIONBIO))
{
if (*static_castioctl_arg_type*(command.data()))
{
--- boost/asio/detail/win_iocp_socket_service.hpp.orig 2010-03-29
21:20:37.0 -0400
+++ boost/asio/detail/win_iocp_socket_service.hpp 2010-06-25
18:55:49.0 -0400
@@ -564,7 +564,7 @@ public:
socket_ops::ioctl(impl.socket_, command.name(),
static_castioctl_arg_type*(command.data()), ec);
-if (!ec command.name() == static_castint(FIONBIO))
+if (!ec command.name() == static_castioctl_cmd_type(FIONBIO))
{
if (*static_castioctl_arg_type*(command.data()))
impl.flags_ |= implementation_type::user_set_non_blocking;
--- boost/asio/detail/descriptor_ops.hpp.orig 2010-01-04 04:36:00.0
-0500
+++ boost/asio/detail/descriptor_ops.hpp2010-06-25 18:37:37.0
-0400
@@ -110,7 +110,7 @@ inline int gather_write(int d, const buf
return result;
}
-inline int ioctl(int d, long cmd, ioctl_arg_type* arg,
+inline int ioctl(int d, ioctl_cmd_type cmd, ioctl_arg_type* arg,
boost::system::error_code ec)
{
clear_error(ec);
--- boost/asio/detail/socket_ops.hpp.orig 2010-01-04 06:55:09.0
-0500
+++ boost/asio/detail/socket_ops.hpp2010-06-25 18:39:55.0 -0400
@@ -596,7 +596,7 @@ inline int getsockname(socket_type s, so
return result;
}
-inline int ioctl(socket_type s, long cmd, ioctl_arg_type* arg,
+inline int ioctl(socket_type s, ioctl_cmd_type cmd, ioctl_arg_type* arg,
boost::system::error_code ec)
{
clear_error(ec);
--- boost/asio/detail/socket_types.hpp.orig 2010-03-21 05:39:26.0
-0400
+++ boost/asio/detail/socket_types.hpp 2010-06-25 18:48:43.0 -0400
@@ -189,6 +189,12 @@ typedef sockaddr_in6 sockaddr_in6_type;
typedef sockaddr_storage sockaddr_storage_type;
typedef sockaddr_un sockaddr_un_type;
typedef addrinfo addrinfo_type;
+#if (defined(__MACH__) defined(__APPLE__)) || defined(__DragonFly__) || \
+defined(__FreeBSD__) || defined(__NetBSD__) || defined(__OpenBSD__)
+typedef unsigned long ioctl_cmd_type;
+#else
+typedef int ioctl_cmd_type;
+#endif
typedef int ioctl_arg_type;
typedef uint32_t u_long_type;
typedef uint16_t u_short_type;
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD 8.1-PRERELEASE: WARNING ioctl sign-extension ioctl ffffffff8004667e
On Friday 25 June 2010 04:54 am, Mario Sergio Fujikawa Ferreira wrote:
On Wed, Jun 23, 2010 at 05:08:38PM -0400, Jung-uk Kim wrote:
Date: Wed, 23 Jun 2010 17:08:38 -0400
From: Jung-uk Kim j...@freebsd.org
To: freebsd-stable@FreeBSD.org
Cc: d...@delphij.net, Mario Sergio Fujikawa Ferreira
li...@freebsd.org Subject: Re: FreeBSD 8.1-PRERELEASE: WARNING
ioctl sign-extension ioctl 8004667e
User-Agent: KMail/1.6.2
On Wednesday 23 June 2010 03:38 pm, Jung-uk Kim wrote:
On Wednesday 23 June 2010 03:10 pm, Jung-uk Kim wrote:
On Wednesday 23 June 2010 03:01 pm, Jung-uk Kim wrote:
On Wednesday 23 June 2010 02:41 pm, Xin LI wrote:
On 2010/06/23 11:37, Jung-uk Kim wrote:
On Wednesday 23 June 2010 02:12 pm, Xin LI wrote:
Hi,
On 2010/06/22 19:58, Mario Sergio Fujikawa Ferreira
wrote:
Hi,
I am getting more than 4 thousand of the following
messages a day:
WARNING pid 24509 (python2.6): ioctl sign-extension
ioctl 8004667e
[...]
I think we may need to check the code and patch it.
Basically this means that python (or some .so modules)
passed an int or unsigned int as parameter 'cmd', we
need to change it to unsigned long.
The warning itself should be harmless to my best of
knowledge, one can probably remove the printf in
kernel source code as a workaround.
By the way it seems to be a POSIX violation and we
didn't seem to really use so wide cmd, but I have not
yet verified everything myself.
Long time ago, I had a similar problem with termios
TIOCGWINSZ and we patched the port like this:
http://www.freebsd.org/cgi/cvsweb.cgi/ports/lang/python
/fil es /A tt
ic/patch-Modules%3A%3Afcntlmodule.c?rev=1.1;content-typ
e=te xt %2 Fpl ain
I believe it was upstream patched at the time but I
won't be surprised if something similar was
reintroduced. It happens when a Python internal
integer type is converted to a native unsigned long.
Well, only *BSD have cmd a long value so it's likely that
it would be reintroduced.
Yes, that's what I mean.
I have checked the 4.4BSD archive and understood that our
ioctl's cmd parameter was made long around 1991 or 1992s
but didn't see what it actually buy us...
Like it or not, it is too late to revert. :-(
From Python 2.6.5:
static PyObject *
fcntl_ioctl(PyObject *self, PyObject *args)
{
#define IOCTL_BUFSZ 1024
int fd;
/* In PyArg_ParseTuple below, we use the unsigned
non-checked 'I' format for the 'code' parameter because
Python turns 0x800 into either a large positive number
(PyLong or PyInt on 64-bit platforms) or a negative number on
others (32-bit PyInt) whereas the system expects it to be a
32bit bit field value regardless of it being passed as an int
or unsigned long on various platforms. See the
termios.TIOCSWINSZ constant across platforms for an example
of thise.
If any of the 64bit platforms ever decide to use more
than 32bits in their unsigned long ioctl codes this will
break and need special casing based on the platform being
built on. */
unsigned int code;
...
It is still a kludge and it won't be fixed. :-(
Please drop the attached patch in ports/lang/python26/files and
test. Note I am not a Python guy, so please don't shoot me. ;-)
I found that Python guys added 'k' format since 2.3, which
converts a Python integer to unsigned long. Please ignore the
previous patch and try the attached patch instead.
Unfortunately it didn't work.
1) Added patch to lang/python26
2) Recompiled lang/python26
3) cd /var/db/ports portupgrade -f python* py26* deluge*
Restarted deluge afterwards. The message is still there:
Jun 25 05:49:38 exxodus kernel: WARNING pid 38635 (python2.6):
ioctl sign-extension ioctl 8004667e
It may be a deeper problen, then. :-(
First of all, I cannot reproduce the problem because deluged dumps
core on my box and I gave it up. Just staring at the code, it seems
they rely on a bundled libtorrent for Python binding and the
libtorrent relies on Boost, in turn. Then, the actual non-blocking
socket implementation is done with Boost ASIO[1]. It is possible
that there are more complicated problems between these and the Python
binding. In fact, I can see a lot of these:
int name() const
{
return FIONBIO;
}
...
if (!ec command.name() == static_castint(FIONBIO))
...
socket_ops::ioctl(impl.socket_, command.name(), ...)
...
They are just assuming it is an int type, I guess.
Sigh, what a mess...
Jung-uk Kim
[1] Boost and its Python binding from ports seems
Re: FreeBSD 8.1-PRERELEASE: WARNING ioctl sign-extension ioctl ffffffff8004667e
On Wednesday 23 June 2010 02:12 pm, Xin LI wrote: Hi, On 2010/06/22 19:58, Mario Sergio Fujikawa Ferreira wrote: Hi, I am getting more than 4 thousand of the following messages a day: WARNING pid 24509 (python2.6): ioctl sign-extension ioctl 8004667e [...] I think we may need to check the code and patch it. Basically this means that python (or some .so modules) passed an int or unsigned int as parameter 'cmd', we need to change it to unsigned long. The warning itself should be harmless to my best of knowledge, one can probably remove the printf in kernel source code as a workaround. By the way it seems to be a POSIX violation and we didn't seem to really use so wide cmd, but I have not yet verified everything myself. Long time ago, I had a similar problem with termios TIOCGWINSZ and we patched the port like this: http://www.freebsd.org/cgi/cvsweb.cgi/ports/lang/python/files/Attic/patch-Modules%3A%3Afcntlmodule.c?rev=1.1;content-type=text%2Fplain I believe it was upstream patched at the time but I won't be surprised if something similar was reintroduced. It happens when a Python internal integer type is converted to a native unsigned long. FYI... Jung-uk Kim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD 8.1-PRERELEASE: WARNING ioctl sign-extension ioctl ffffffff8004667e
On Wednesday 23 June 2010 02:41 pm, Xin LI wrote: On 2010/06/23 11:37, Jung-uk Kim wrote: On Wednesday 23 June 2010 02:12 pm, Xin LI wrote: Hi, On 2010/06/22 19:58, Mario Sergio Fujikawa Ferreira wrote: Hi, I am getting more than 4 thousand of the following messages a day: WARNING pid 24509 (python2.6): ioctl sign-extension ioctl 8004667e [...] I think we may need to check the code and patch it. Basically this means that python (or some .so modules) passed an int or unsigned int as parameter 'cmd', we need to change it to unsigned long. The warning itself should be harmless to my best of knowledge, one can probably remove the printf in kernel source code as a workaround. By the way it seems to be a POSIX violation and we didn't seem to really use so wide cmd, but I have not yet verified everything myself. Long time ago, I had a similar problem with termios TIOCGWINSZ and we patched the port like this: http://www.freebsd.org/cgi/cvsweb.cgi/ports/lang/python/files/Att ic/patch-Modules%3A%3Afcntlmodule.c?rev=1.1;content-type=text%2Fpl ain I believe it was upstream patched at the time but I won't be surprised if something similar was reintroduced. It happens when a Python internal integer type is converted to a native unsigned long. Well, only *BSD have cmd a long value so it's likely that it would be reintroduced. Yes, that's what I mean. I have checked the 4.4BSD archive and understood that our ioctl's cmd parameter was made long around 1991 or 1992s but didn't see what it actually buy us... Like it or not, it is too late to revert. :-( Jung-uk Kim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD 8.1-PRERELEASE: WARNING ioctl sign-extension ioctl ffffffff8004667e
On Wednesday 23 June 2010 03:01 pm, Jung-uk Kim wrote:
On Wednesday 23 June 2010 02:41 pm, Xin LI wrote:
On 2010/06/23 11:37, Jung-uk Kim wrote:
On Wednesday 23 June 2010 02:12 pm, Xin LI wrote:
Hi,
On 2010/06/22 19:58, Mario Sergio Fujikawa Ferreira wrote:
Hi,
I am getting more than 4 thousand of the following messages
a day:
WARNING pid 24509 (python2.6): ioctl sign-extension ioctl
8004667e
[...]
I think we may need to check the code and patch it. Basically
this means that python (or some .so modules) passed an int or
unsigned int as parameter 'cmd', we need to change it to
unsigned long.
The warning itself should be harmless to my best of knowledge,
one can probably remove the printf in kernel source code as a
workaround.
By the way it seems to be a POSIX violation and we didn't seem
to really use so wide cmd, but I have not yet verified
everything myself.
Long time ago, I had a similar problem with termios TIOCGWINSZ
and we patched the port like this:
http://www.freebsd.org/cgi/cvsweb.cgi/ports/lang/python/files/A
tt
ic/patch-Modules%3A%3Afcntlmodule.c?rev=1.1;content-type=text%2
Fpl ain
I believe it was upstream patched at the time but I won't be
surprised if something similar was reintroduced. It happens
when a Python internal integer type is converted to a native
unsigned long.
Well, only *BSD have cmd a long value so it's likely that it
would be reintroduced.
Yes, that's what I mean.
I have checked the 4.4BSD archive and understood that our ioctl's
cmd parameter was made long around 1991 or 1992s but didn't see
what it actually buy us...
Like it or not, it is too late to revert. :-(
From Python 2.6.5:
static PyObject *
fcntl_ioctl(PyObject *self, PyObject *args)
{
#define IOCTL_BUFSZ 1024
int fd;
/* In PyArg_ParseTuple below, we use the unsigned non-checked 'I'
format for the 'code' parameter because Python turns 0x800
into either a large positive number (PyLong or PyInt on 64-bit
platforms) or a negative number on others (32-bit PyInt)
whereas the system expects it to be a 32bit bit field value
regardless of it being passed as an int or unsigned long on
various platforms. See the termios.TIOCSWINSZ constant across
platforms for an example of thise.
If any of the 64bit platforms ever decide to use more than 32bits
in their unsigned long ioctl codes this will break and need
special casing based on the platform being built on.
*/
unsigned int code;
...
It is still a kludge and it won't be fixed. :-(
Jung-uk Kim
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD 8.1-PRERELEASE: WARNING ioctl sign-extension ioctl ffffffff8004667e
On Wednesday 23 June 2010 03:16 pm, Xin LI wrote: On 2010/06/23 12:10, Jung-uk Kim wrote: It is still a kludge and it won't be fixed. :-( Another thought - what about just hiding the printf under #ifdef DIAGNOSTIC... I don't really see any reason why we must print it out if we truncate it every time... Yes, I agree. Jung-uk Kim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD 8.1-PRERELEASE: WARNING ioctl sign-extension ioctl ffffffff8004667e
On Wednesday 23 June 2010 03:10 pm, Jung-uk Kim wrote:
On Wednesday 23 June 2010 03:01 pm, Jung-uk Kim wrote:
On Wednesday 23 June 2010 02:41 pm, Xin LI wrote:
On 2010/06/23 11:37, Jung-uk Kim wrote:
On Wednesday 23 June 2010 02:12 pm, Xin LI wrote:
Hi,
On 2010/06/22 19:58, Mario Sergio Fujikawa Ferreira wrote:
Hi,
I am getting more than 4 thousand of the following
messages a day:
WARNING pid 24509 (python2.6): ioctl sign-extension ioctl
8004667e
[...]
I think we may need to check the code and patch it.
Basically this means that python (or some .so modules)
passed an int or unsigned int as parameter 'cmd', we need to
change it to unsigned long.
The warning itself should be harmless to my best of
knowledge, one can probably remove the printf in kernel
source code as a workaround.
By the way it seems to be a POSIX violation and we didn't
seem to really use so wide cmd, but I have not yet verified
everything myself.
Long time ago, I had a similar problem with termios
TIOCGWINSZ and we patched the port like this:
http://www.freebsd.org/cgi/cvsweb.cgi/ports/lang/python/files
/A tt
ic/patch-Modules%3A%3Afcntlmodule.c?rev=1.1;content-type=text
%2 Fpl ain
I believe it was upstream patched at the time but I won't be
surprised if something similar was reintroduced. It happens
when a Python internal integer type is converted to a native
unsigned long.
Well, only *BSD have cmd a long value so it's likely that it
would be reintroduced.
Yes, that's what I mean.
I have checked the 4.4BSD archive and understood that our
ioctl's cmd parameter was made long around 1991 or 1992s but
didn't see what it actually buy us...
Like it or not, it is too late to revert. :-(
From Python 2.6.5:
static PyObject *
fcntl_ioctl(PyObject *self, PyObject *args)
{
#define IOCTL_BUFSZ 1024
int fd;
/* In PyArg_ParseTuple below, we use the unsigned non-checked 'I'
format for the 'code' parameter because Python turns 0x800
into either a large positive number (PyLong or PyInt on 64-bit
platforms) or a negative number on others (32-bit PyInt)
whereas the system expects it to be a 32bit bit field value
regardless of it being passed as an int or unsigned long on
various platforms. See the termios.TIOCSWINSZ constant across
platforms for an example of thise.
If any of the 64bit platforms ever decide to use more than
32bits in their unsigned long ioctl codes this will break and need
special casing based on the platform being built on.
*/
unsigned int code;
...
It is still a kludge and it won't be fixed. :-(
Please drop the attached patch in ports/lang/python26/files and test.
Note I am not a Python guy, so please don't shoot me. ;-)
Thanks,
Jung-uk Kim
--- Modules/fcntlmodule.c.orig 2009-05-24 11:41:43.0 -0400
+++ Modules/fcntlmodule.c 2010-06-23 15:27:42.0 -0400
@@ -110,7 +110,12 @@
in their unsigned long ioctl codes this will break and need
special casing based on the platform being built on.
*/
+#if defined(__APPLE__) || defined(__FreeBSD__) || defined(__NetBSD__) || \
+defined(__OpenBSD__)
+ unsigned long code;
+#else
unsigned int code;
+#endif
int arg;
int ret;
char *str;
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD 8.1-PRERELEASE: WARNING ioctl sign-extension ioctl ffffffff8004667e
On Wednesday 23 June 2010 03:38 pm, Jung-uk Kim wrote:
On Wednesday 23 June 2010 03:10 pm, Jung-uk Kim wrote:
On Wednesday 23 June 2010 03:01 pm, Jung-uk Kim wrote:
On Wednesday 23 June 2010 02:41 pm, Xin LI wrote:
On 2010/06/23 11:37, Jung-uk Kim wrote:
On Wednesday 23 June 2010 02:12 pm, Xin LI wrote:
Hi,
On 2010/06/22 19:58, Mario Sergio Fujikawa Ferreira wrote:
Hi,
I am getting more than 4 thousand of the following
messages a day:
WARNING pid 24509 (python2.6): ioctl sign-extension ioctl
8004667e
[...]
I think we may need to check the code and patch it.
Basically this means that python (or some .so modules)
passed an int or unsigned int as parameter 'cmd', we need
to change it to unsigned long.
The warning itself should be harmless to my best of
knowledge, one can probably remove the printf in kernel
source code as a workaround.
By the way it seems to be a POSIX violation and we didn't
seem to really use so wide cmd, but I have not yet
verified everything myself.
Long time ago, I had a similar problem with termios
TIOCGWINSZ and we patched the port like this:
http://www.freebsd.org/cgi/cvsweb.cgi/ports/lang/python/fil
es /A tt
ic/patch-Modules%3A%3Afcntlmodule.c?rev=1.1;content-type=te
xt %2 Fpl ain
I believe it was upstream patched at the time but I won't
be surprised if something similar was reintroduced. It
happens when a Python internal integer type is converted to
a native unsigned long.
Well, only *BSD have cmd a long value so it's likely that it
would be reintroduced.
Yes, that's what I mean.
I have checked the 4.4BSD archive and understood that our
ioctl's cmd parameter was made long around 1991 or 1992s but
didn't see what it actually buy us...
Like it or not, it is too late to revert. :-(
From Python 2.6.5:
static PyObject *
fcntl_ioctl(PyObject *self, PyObject *args)
{
#define IOCTL_BUFSZ 1024
int fd;
/* In PyArg_ParseTuple below, we use the unsigned non-checked
'I' format for the 'code' parameter because Python turns
0x800 into either a large positive number (PyLong or PyInt on
64-bit platforms) or a negative number on others (32-bit PyInt)
whereas the system expects it to be a 32bit bit field value
regardless of it being passed as an int or unsigned long on
various platforms. See the termios.TIOCSWINSZ constant across
platforms for an example of thise.
If any of the 64bit platforms ever decide to use more than
32bits in their unsigned long ioctl codes this will break and
need special casing based on the platform being built on.
*/
unsigned int code;
...
It is still a kludge and it won't be fixed. :-(
Please drop the attached patch in ports/lang/python26/files and
test. Note I am not a Python guy, so please don't shoot me. ;-)
I found that Python guys added 'k' format since 2.3, which converts a
Python integer to unsigned long. Please ignore the previous patch
and try the attached patch instead.
Cheers,
Jung-uk Kim
--- Modules/fcntlmodule.c.orig 2009-05-24 11:41:43.0 -0400
+++ Modules/fcntlmodule.c 2010-06-23 16:56:10.0 -0400
@@ -97,6 +97,13 @@
{
#define IOCTL_BUFSZ 1024
int fd;
+#if defined(__APPLE__) || defined(__FreeBSD__) || defined(__NetBSD__) || \
+defined(__OpenBSD__)
+#define IOCTL_ULONG 1
+#endif
+#ifdef IOCTL_ULONG
+ unsigned long code;
+#else
/* In PyArg_ParseTuple below, we use the unsigned non-checked 'I'
format for the 'code' parameter because Python turns 0x800
into either a large positive number (PyLong or PyInt on 64-bit
@@ -105,12 +112,9 @@
regardless of it being passed as an int or unsigned long on
various platforms. See the termios.TIOCSWINSZ constant across
platforms for an example of thise.
-
- If any of the 64bit platforms ever decide to use more than 32bits
- in their unsigned long ioctl codes this will break and need
- special casing based on the platform being built on.
*/
unsigned int code;
+#endif
int arg;
int ret;
char *str;
@@ -118,7 +122,11 @@
int mutate_arg = 1;
char buf[IOCTL_BUFSZ+1]; /* argument plus NUL byte */
+#ifdef IOCTL_ULONG
+ if (PyArg_ParseTuple(args, Okw#|i:ioctl,
+#else
if (PyArg_ParseTuple(args, OIw#|i:ioctl,
+#endif
conv_descriptor, fd, code,
str, len, mutate_arg)) {
char *arg;
@@ -169,7 +177,11 @@
}
PyErr_Clear();
+#ifdef IOCTL_ULONG
+ if (PyArg_ParseTuple(args, Oks#:ioctl,
+#else
if (PyArg_ParseTuple(args, OIs#:ioctl,
+#endif
conv_descriptor, fd, code, str
Re: Strange video mode output with VESA
On Wednesday 02 June 2010 04:25 pm, David DEMELIER wrote: Hi there, I was so happy to see that VESA is available for amd64, but unfortunately it does not work really well for me. Take a look at this picture : http://img717.imageshack.us/img717/7311/dsc00399h.jpg My laptop is a 15,6 so the best resolution is 1366x768, I tried this : vidcontrol MODE_496. As you can see on the picture all the lines : are completely everywhere, if I mouse the cursor they move away (I'm not drunk!). I have SC_PIXEL_MODE in my kernel config. The console terminal is okay until I don't excess 1280x960x32 video mode. Do you have any idea to fix this ? It is kinda known problem. If the mode has larger bytes per scan line than the minimum, few characters per line are lost when the screen is scrolled up or down, i.e., framebuffer copies of whole screen. When you move the mouse onto the line, entire line is redrawn and restored. That's what you are seeing. Ed might have a better idea how to fix it (CC'ed). Jung-uk Kim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Floppy drive not detected after 8.0-RELEASE-8.1-PRERELEASE
On Friday 28 May 2010 03:35 pm, Scott Allendorf wrote: Andriy Gapon wrote: on 28/05/2010 19:32 Scott Allendorf said the following: I recently upgraded to 8.1-PRERELEASE (amd64) on a Dell Optiplex 960 running 8.0-RELEASE. After the upgrade, my floppy drive was no longer detected. After a binary search, the following commit appears to be responsible: http://svn.freebsd.org/viewvc/base?view=revisionrevision=203544 Can you check if reverting of MFC of the following helps (it's a part of that big ACPI MFC)? r200554 | jkim | 2009-12-15 00:28:32 +0200 (Tue, 15 Dec 2009) | 3 lines Remove _FDE quirk handling as these quirks are automatically repaired by ACPICA layer since ACPICA 20091214. Thank you for your quick reply to my message. Reverting this change (src/sys/dev/fdc/fdc_acpi.c from 1.13.2.2 to 1.13.2.1) appears to have fixed the issue. The floppy drive is now detected and it is functional. There do not appear to be any side effects. Can you please show me acpidump -dt output? Thanks, Jung-uk Kim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Floppy drive not detected after 8.0-RELEASE-8.1-PRERELEASE
On Friday 28 May 2010 03:35 pm, Scott Allendorf wrote:
Andriy Gapon wrote:
on 28/05/2010 19:32 Scott Allendorf said the following:
I recently upgraded to 8.1-PRERELEASE (amd64) on a Dell Optiplex
960 running 8.0-RELEASE. After the upgrade, my floppy drive was
no longer detected. After a binary search, the following commit
appears to be responsible:
http://svn.freebsd.org/viewvc/base?view=revisionrevision=203544
Can you check if reverting of MFC of the following helps (it's a
part of that big ACPI MFC)?
r200554 | jkim | 2009-12-15 00:28:32 +0200 (Tue, 15 Dec 2009) | 3
lines Remove _FDE quirk handling as these quirks are
automatically repaired by ACPICA layer since ACPICA 20091214.
Thank you for your quick reply to my message.
Reverting this change (src/sys/dev/fdc/fdc_acpi.c from 1.13.2.2 to
1.13.2.1) appears to have fixed the issue. The floppy drive is now
detected and it is functional. There do not appear to be any side
effects.
Please try the attached patch. Sorry, it was stupid. :-(
Jung-uk Kim
--- sys/dev/fdc/fdc_acpi.c (revision 208626)
+++ sys/dev/fdc/fdc_acpi.c (working copy)
@@ -96,6 +96,7 @@ fdc_acpi_attach(device_t dev)
{
struct fdc_data *sc;
ACPI_BUFFER buf;
+ ACPI_OBJECT *obj;
device_t bus;
int error;
@@ -131,7 +132,8 @@ fdc_acpi_attach(device_t dev)
}
/* Add fd child devices as specified. */
- error = fdc_acpi_probe_children(bus, dev, buf.Pointer);
+ obj = buf.Pointer;
+ error = fdc_acpi_probe_children(bus, dev, obj-Buffer.Pointer);
out:
if (buf.Pointer)
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: openjdk6 browser plugin
On Saturday 05 December 2009 04:12 am, S.N.Grigoriev wrote: 04.12.09, 14:54, Jung-uk Kim j...@freebsd.org wrote: On Friday 04 December 2009 02:33 pm, S.N.Grigoriev wrote: Hi list, I've installed openjdk6 from ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-8-stabl e/jav a. Does this package contain a browser java plugin? I can't find it. Any tips are appreciated. No, OpenJDK does not have a browser plugin. If Java plugin is all you need, you can use java/diablo-jre16. Are there diablo* packages for 8.0R anywhere? There are for 6.x 7.x on the FreeBSD Foundation site, but not for 8.x. I believe diable-* for 7.x is working okay with 8.x. However, you need misc/compat7x, too. So, you just have to build diable-* from ports to get proper dependencies. Jung-uk Kim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: openjdk6 browser plugin
On Monday 07 December 2009 12:18 pm, Jung-uk Kim wrote: On Saturday 05 December 2009 04:12 am, S.N.Grigoriev wrote: 04.12.09, 14:54, Jung-uk Kim j...@freebsd.org wrote: On Friday 04 December 2009 02:33 pm, S.N.Grigoriev wrote: Hi list, I've installed openjdk6 from ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-8-sta bl e/jav a. Does this package contain a browser java plugin? I can't find it. Any tips are appreciated. No, OpenJDK does not have a browser plugin. If Java plugin is all you need, you can use java/diablo-jre16. Are there diablo* packages for 8.0R anywhere? There are for 6.x 7.x on the FreeBSD Foundation site, but not for 8.x. I believe diable-* for 7.x is working okay with 8.x. However, you need misc/compat7x, too. So, you just have to build diable-* from ports to get proper dependencies. Doh, I cannot type today. I meant diablo-*, not diable-*, of course. Jung-uk Kim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Could you please fix this ?
On Thursday 03 December 2009 09:27 pm, Leonardo Santagostini wrote:
Sorry, but ive not backed up this file, instead of this, i will
copy the entire function (in fact its very short)
cpi_pcib_pci_attach(device_t dev)
{
struct acpi_pcib_softc *sc;
ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
if (device_get_unit(dev)==2){
pci_write_config(dev, PCIR_COMMAND, PCIM_CMD_MEMEN |
PCIM_CMD_PORTEN, 1);
pci_enable_busmaster(dev);
pci_write_config(dev, PCIR_IOBASEL_1, 0xf0, 1);
pci_write_config(dev, PCIR_MEMBASE_1, 0xf020, 2);
pci_write_config(dev, PCIR_MEMLIMIT_1, 0xf020, 2);
pci_write_config(dev, PCIR_PMBASEL_1, 0xfff1, 2);
}
if (device_get_unit(dev)==3){
pci_write_config(dev, PCIR_COMMAND, PCIM_CMD_MEMEN |
PCIM_CMD_PORTEN, 1);
pci_enable_busmaster(dev);
pci_write_config(dev, PCIR_IOBASEL_1, 0xf0, 1);
pci_write_config(dev, PCIR_MEMBASE_1, 0xf030, 2);
pci_write_config(dev, PCIR_MEMLIMIT_1, 0xf030, 2);
pci_write_config(dev, PCIR_PMBASEL_1, 0xfff1, 2);
}
pcib_attach_common(dev);
sc = device_get_softc(dev);
sc-ap_handle = acpi_get_handle(dev);
return (acpi_pcib_attach(dev, sc-ap_prt,
sc-ap_pcibsc.secbus)); }
As mav@ pointed out yesterday, this hack is very specific to this
hardware. As jhb@ pointed out some time ago, this problem will be
properly addressed by his multipass device probing mechanism.
Sorry, there's nothing we can commit ATM.
Jung-uk Kim
Kind Regards
Leonardo Santagostini
2009/12/3 Giorgos Keramidas keram...@freebsd.org:
On Thu, 3 Dec 2009 01:57:50 +, Leonardo Santagostini
lsantagost...@gmail.com wrote:
Hello everybody,
I was facing one big problem, i have a notebook, which is an
Acer Aspire 5920. If you like i can send to you my messages
file.
Which is:
Intel(R) Core(TM)2 Duo CPU T5550 @ 1.83GHz (1833.48-MHz
686-class CPU) Intel(R) PRO/Wireless 3945ABG
Broadcom NetLink Gigabit Ethernet Controller
2 Gigs RAM
160 Gigs SATA
The point was:
With ACPI disabled, i managed to boot but without WIFI; and with
ACPI enabled, the boot process hanged up all times.
I fixed this adding
if (device_get_unit(dev)==2){
pci_write_config(dev, PCIR_COMMAND, PCIM_CMD_MEMEN |
PCIM_CMD_PORTEN, 1); pci_enable_busmaster(dev);
pci_write_config(dev, PCIR_IOBASEL_1, 0xf0, 1);
pci_write_config(dev, PCIR_MEMBASE_1, 0xf020, 2);
pci_write_config(dev, PCIR_MEMLIMIT_1, 0xf020, 2);
pci_write_config(dev, PCIR_PMBASEL_1, 0xfff1, 2);
}
if (device_get_unit(dev)==3){
pci_write_config(dev, PCIR_COMMAND, PCIM_CMD_MEMEN |
PCIM_CMD_PORTEN, 1); pci_enable_busmaster(dev);
pci_write_config(dev, PCIR_IOBASEL_1, 0xf0, 1);
pci_write_config(dev, PCIR_MEMBASE_1, 0xf030, 2);
pci_write_config(dev, PCIR_MEMLIMIT_1, 0xf030, 2);
pci_write_config(dev, PCIR_PMBASEL_1, 0xfff1, 2);
}
to /usr/src/sys/dev/acpica/acpi_pcib_pci.c running on a
8.0-RELEASE
I was able to fix it by my way but many people cant do it, so, i
would really appreciate if you can add this piece of code.
Hi Leonardo.
Jung-uk Kim has done a lot of ACPI-related work, so he will
probably know if the change is ok to commit to stable/8. I've
added him to the thread, so he can let us know what he thinks of
the change. Can you please post a diff that also shows _where_
the changes have to be installed in our current version of
src/sys/dev/acpica/acpi_pcib_pci.c for 8.0-RELEASE?
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: openjdk6 browser plugin
On Friday 04 December 2009 02:33 pm, S.N.Grigoriev wrote: Hi list, I've installed openjdk6 from ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-8-stable/jav a. Does this package contain a browser java plugin? I can't find it. Any tips are appreciated. No, OpenJDK does not have a browser plugin. If Java plugin is all you need, you can use java/diablo-jre16. Jung-uk Kim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: PATA disks/DVD not detected on ATI IXP 700 - cannot boot (dmesg attached)
On Wednesday 30 September 2009 03:19 am, Alexander Motin wrote: Jung-uk Kim wrote: On Monday 28 September 2009 02:21 pm, Alexander Motin wrote: PS: I have tried to disable all that ATI-specific code and found that both legacy PCI ATA and AHCI drivers looks like working fine with IXP700. Do we really need AHCI forcing for IXP700? It enables all six SATA ports as SATA and one PATA channel as PATA in the combined mode by forcing the mode. It is not absolutely necessary but it is better than without it, IMHO. :-) As I have told, with or without this patch I am any way receiving 4 AHCI channels + 2 PATA + 2 legacy SATA if IDE mode set in BIOS. If I enable AHCI mode in BIOS I am receiving 6 AHCI + 2 PATA channels. Looks like Dennis has the same. So 1) I don't see any effect of this hack on my system, at least with HEAD (is it working?), and 2) if we are doing all this magic and force AHCI mode for second controller, IMHO it would be reasonable to enable real AHCI mode to get all 6 SATA channels there. What's puzzling me whole day is that the hack worked for me at the time (I swear!) but now it doesn't. :-( Originally I thought forcing AHCI mode clears combined mode but it doesn't work any more. I even tried clearing combined mode at SMB controller but it didn't work, either. It is possible that newer ACPICA with executable at module level feature did something because its (broken) DSDT reconfigures SATA controller at module level if it is in native or legacy IDE mode. I'll try something again tomorrow and let you know. Jung-uk Kim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: PATA disks/DVD not detected on ATI IXP 700 - cannot boot (dmesg attached)
On Monday 28 September 2009 02:21 pm, Alexander Motin wrote: Here we can see detected: 4 (not 6!) SATA channels on AHCI controller, one PATA channel and 2 SATA channels in legacy emulation (why?). Actually, the same happens if I comment out all that device class magic. Looks like the only thing really required to fix problem with two lost channels is this part of patch: -/* IXP600 IXP700 only have 1 PATA channel */ -if ((ctlr-chip-chipid == ATA_ATI_IXP600) || - (ctlr-chip-chipid == ATA_ATI_IXP700)) +/* IXP600 only have 1 PATA channel */ +if (ctlr-chip-chipid == ATA_ATI_IXP600) Looks like part of changing device class just not working. Today I have bought IXP700 based board and can acknowledge that the same situation I can see with recent HEAD. `pciconf -l` reports to me original PATA device class and only 4 channels reported by AHCI. So jkim@, could you please comment, how should it really work and why it doesn't? My patch fixed two things: a) combined mode and b) the above fix. The combined mode is very unusual. When combined mode is turned on from BIOS, two SATA ports appear as legacy ATA device. Depending on the configurations, device ID changes. :-( To enable this feature, some BIOSes allow flexible (and yet confusing) combinations like this: http://people.freebsd.org/~jkim/sb700-ata.png Also, almost all SB700 BIOSes out there have broken ACPI DSDT which do not set these bits properly. Thus, some ports disappear if we don't force setting the subclass and progif. Note it should be *partially* worked around by the latest ACPICA on -CURRENT, though. PS: I have tried to disable all that ATI-specific code and found that both legacy PCI ATA and AHCI drivers looks like working fine with IXP700. Do we really need AHCI forcing for IXP700? It enables all six SATA ports as SATA and one PATA channel as PATA in the combined mode by forcing the mode. It is not absolutely necessary but it is better than without it, IMHO. :-) Jung-uk Kim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: PATA disks/DVD not detected on ATI IXP 700 - cannot boot (dmesg attached)
On Friday 18 September 2009 11:52 pm, Ted Faber wrote: On Wed, Sep 16, 2009 at 09:13:27AM -0700, Ted Faber wrote: Hi. I'm trying to upgrade a machine to a new motherboard (the ECS A790GXM-AD3 AM3 790GX) my FreeBSD 7-STABLE system (GENERIC kernel, compiled from source on 10 Sept 2009) reaches the point where it's going to mount the root file system and can't find the disk. It drops me into the manual specification of root file system menu, but there are no GEOM-managed disks to choose from. [...] I managed to boot FreeBSD on this motherboard using a USB key. Attached is the dmesg from a verbose boot. Any help would be appreciated. This is a known problem and should be fixed in 8.0. Sorry, I haven't had time to back-port the code. Proabably it's good time to consider testing 8.0-RC1. ;-) Jung-uk Kim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Detecting CPU throttling on over temperature
On Thursday 10 September 2009 09:37 am, Luigi Rizzo wrote: On Thu, Sep 10, 2009 at 03:21:07PM +0200, Kurt Jaeger wrote: Hi! I thought coretemp had be modified in HEAD to support Phenoms but I can't find any evidence of that in SVN so I am not sure what I am thinking.. How about 'k8temp'? /usr/ports/sysutils/k8temp This works, very nice! note though that the numbers you get seem way off reality: bsd7# k8temp CPU 0 Core 0 Sensor 0: 13c CPU 0 Core 0 Sensor 1: 13c CPU 0 Core 1 Sensor 0: 16c CPU 0 Core 1 Sensor 1: 3c (they do increase with CPU load). I bet this is a Family 0Fh Revision G processor. In fact, I (accidently) found the problem and wrote the attached patch for amdtemp(4) last night. :-) Jung-uk Kim --- sys/dev/amdtemp/amdtemp.c.orig 2009-08-20 15:43:50.0 -0400 +++ sys/dev/amdtemp/amdtemp.c 2009-09-09 18:44:26.0 -0400 @@ -360,8 +360,13 @@ amdtemp_gettemp0f(device_t dev, amdsenso } pci_write_config(dev, AMDTEMP_REG0F, cfg, 1); temp = pci_read_config(dev, AMDTEMP_REG0F, 4); - temp = ((temp 16) 0xff) * 10 + AMDTEMP_OFFSET0F; - + + /* Revision G has two more bits. */ + if ((cpu_id CPUID_EXT_MODEL) = 0x6) + temp = ((temp 14) 0x3ff) * 10 / 4 + AMDTEMP_OFFSET; + else + temp = ((temp 16) 0xff) * 10 + AMDTEMP_OFFSET; + return (temp); } ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Garbled output from kgdb?
On Monday 11 May 2009 09:52 am, John Baldwin wrote: On Tuesday 05 May 2009 5:43:01 pm Jung-uk Kim wrote: On Tuesday 05 May 2009 04:09 pm, Jung-uk Kim wrote: On Tuesday 05 May 2009 12:51 pm, Andriy Gapon wrote: BTW, this issue seems to be fixed in Jung-uk's acpi patches for newer acpica imports, but it is not fixed both in stable/7 and head. Yes, it was fixed in my patchsets long ago, which uses spin lock for AcpiOsAcquireLock(). :-) The attached patch is for -STABLE. Note that it is only compile tested on amd64. This looks fine to test. The patch has gratuitous style changes I wouldn't include in a commit though. It should work but I don't plan to commit it any time soon. :-) In fact, the patch was meant to be a rewrite for new ACPI-CA, which actually has a real mutex. Currently, mutex is emulated with semaphore. The problem is semaphore has no concept of ownership while mutex does, i.e., any thread can acquire/release it without checking its ownership or order. FYI, the OSL API (ACPI_MUTEX_TYPE) is finalized in ACPI-CA 20081204. Jung-uk Kim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Garbled output from kgdb?
On Tuesday 05 May 2009 12:51 pm, Andriy Gapon wrote: BTW, this issue seems to be fixed in Jung-uk's acpi patches for newer acpica imports, but it is not fixed both in stable/7 and head. Yes, it was fixed in my patchsets long ago, which uses spin lock for AcpiOsAcquireLock(). :-) Jung-uk Kim on 05/05/2009 19:45 Andriy Gapon said the following: on 01/05/2009 22:01 John Baldwin said the following: The trace actually ends here. There is nothing super bad here but there is a big problem actually in that the idle threads cannot block on a lock, so it is a problem for the ACPI code to be acquiring a mutex here. Perhaps the locks protecting the idle registers need to use spin locks instead. The problem with blocking in the idle thread is that the scheduler assumes (even requires) that the idle thread is _always_ runnable. Very interesting! So it seems that we are not having more of such crashes by a pure luck (low probability)? Looking at the method's signature: ACPI_NATIVE_UINT AcpiOsAcquireLock (ACPI_SPINLOCK Handle) I think that the name of the parameter type is a big hint. Further, looking into ACPICA reference document: Wait for and acquire a spin lock. May be called from interrupt handlers, GPE handlers, and Fixed event handlers. Single threaded OSL implementations should always return AE_OK for this interface. P.S. the comment before AcpiOsAcquireLock function (in stable/7 code) seems to be outdated/bogus too - first of all there is no Flags parameter (it's actualy a return value to be used when lock is released) and, second, having ithreads is no excuse to not care about type of blocking, and the term 'blocking' is used incorrectly too: /* * The Flags parameter seems to state whether or not caller is an ISR * (and thus can't block) but since we have ithreads, we don't worry * about potentially blocking. */ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Garbled output from kgdb?
On Tuesday 05 May 2009 04:23 pm, John Baldwin wrote:
Jung-uk Kim wrote:
On Tuesday 05 May 2009 12:51 pm, Andriy Gapon wrote:
BTW, this issue seems to be fixed in Jung-uk's acpi patches for
newer acpica imports, but it is not fixed both in stable/7 and
head.
Yes, it was fixed in my patchsets long ago, which uses spin lock
for AcpiOsAcquireLock(). :-)
I'm not sure all ACPI locks need to be spin locks, but any locks
used by the idle code must be spin locks.
There are several types of ACPI locks internally and externally. The
AcpiOs{Create,Acquire,Release}Lock() is just one of them, which is a
spin lock and it is mostly used for interrupt handlers, e.g., GPE and
HW. I have to say there were a lot of confusions between ACPI
developers because it was not well-documented. In fact, I personally
had to exchange lengthy e-mails with Intel engineers to understand
the meaning of these myself. Now Intel has documented everything you
need to know about ACPI-CA for OS developers:
http://git.moblin.org/cgit.cgi/acpica/tree/documents
Regardless, are you going to import a newer ACPI-CA and commit your
patches soon? It sounds like several things are fixed in the
outstanding patches by now including both this and the problem with
the Alias() operator.
Unfortunately, I don't have much time to work on it recently. Couple
of developers volunteered to do the actual import work although I
haven't heard from them in a while. :-(
Jung-uk Kim
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Garbled output from kgdb?
On Tuesday 05 May 2009 04:09 pm, Jung-uk Kim wrote:
On Tuesday 05 May 2009 12:51 pm, Andriy Gapon wrote:
BTW, this issue seems to be fixed in Jung-uk's acpi patches for
newer acpica imports, but it is not fixed both in stable/7 and
head.
Yes, it was fixed in my patchsets long ago, which uses spin lock
for AcpiOsAcquireLock(). :-)
The attached patch is for -STABLE. Note that it is only compile
tested on amd64.
Jung-uk Kim
--- sys/dev/acpica/Osd/OsdSynch.c (revision 191834)
+++ sys/dev/acpica/Osd/OsdSynch.c (working copy)
@@ -1,6 +1,7 @@
/*-
* Copyright (c) 2000 Michael Smith
* Copyright (c) 2000 BSDi
+ * Copyright (c) 2007-2009 Jung-uk Kim j...@freebsd.org
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -35,365 +36,313 @@
#include contrib/dev/acpica/acpi.h
#include opt_acpi.h
+#include sys/condvar.h
#include sys/kernel.h
-#include sys/malloc.h
-#include sys/sysctl.h
#include sys/lock.h
+#include sys/malloc.h
#include sys/mutex.h
+#include sys/sx.h
-#define _COMPONENT ACPI_OS_SERVICES
+#define_COMPONENT ACPI_OS_SERVICES
ACPI_MODULE_NAME(SYNCH)
MALLOC_DEFINE(M_ACPISEM, acpisem, ACPI semaphore);
-#define AS_LOCK(as)mtx_lock((as)-as_mtx)
-#define AS_UNLOCK(as) mtx_unlock((as)-as_mtx)
+/* Convert microseconds to hz. */
+static int
+timeout2hz(long timo)
+{
+ struct timeval tv;
+ tv.tv_sec = timo / 100;
+ tv.tv_usec = timo % 100;
+
+ return (tvtohz(tv));
+}
+
+/* Adjust timeout from the previous uptime. */
+static long
+adjust_timeout(long *tmop, struct timeval *tvp)
+{
+ struct timeval now, slept;
+
+ getmicrouptime(now);
+ slept = now;
+ timevalsub(slept, tvp);
+ *tmop -= slept.tv_sec * 100 + slept.tv_usec;
+ *tvp = now;
+
+ return (*tmop);
+}
+
/*
- * Simple counting semaphore implemented using a mutex. (Subsequently used
- * in the OSI code to implement a mutex. Go figure.)
+ * ACPI_SEMAPHORE: a sleepable counting semaphore
*/
struct acpi_semaphore {
-struct mtx as_mtx;
-UINT32 as_units;
-UINT32 as_maxunits;
-UINT32 as_pendings;
-UINT32 as_resetting;
-UINT32 as_timeouts;
+ struct sx as_lock;
+ charas_name[32];
+ struct cv as_cv;
+ UINT32 as_units;
+ UINT32 as_maxunits;
};
-/* Default number of maximum pending threads. */
-#ifndef ACPI_NO_SEMAPHORES
-#ifndef ACPI_SEMAPHORES_MAX_PENDING
-#define ACPI_SEMAPHORES_MAX_PENDING4
-#endif
-
-static int acpi_semaphore_debug = 0;
-TUNABLE_INT(debug.acpi_semaphore_debug, acpi_semaphore_debug);
-SYSCTL_DECL(_debug_acpi);
-SYSCTL_INT(_debug_acpi, OID_AUTO, semaphore_debug, CTLFLAG_RW,
- acpi_semaphore_debug, 0, Enable ACPI semaphore debug messages);
-#endif /* !ACPI_NO_SEMAPHORES */
-
ACPI_STATUS
AcpiOsCreateSemaphore(UINT32 MaxUnits, UINT32 InitialUnits,
ACPI_SEMAPHORE *OutHandle)
{
-#ifndef ACPI_NO_SEMAPHORES
-struct acpi_semaphore *as;
+ struct acpi_semaphore *as;
-ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+ ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
-if (OutHandle == NULL)
- return_ACPI_STATUS (AE_BAD_PARAMETER);
-if (InitialUnits MaxUnits)
- return_ACPI_STATUS (AE_BAD_PARAMETER);
+ if (OutHandle == NULL || InitialUnits MaxUnits)
+ return_ACPI_STATUS (AE_BAD_PARAMETER);
-if ((as = malloc(sizeof(*as), M_ACPISEM, M_NOWAIT | M_ZERO)) == NULL)
- return_ACPI_STATUS (AE_NO_MEMORY);
+ if ((as = malloc(sizeof(*as), M_ACPISEM, M_NOWAIT | M_ZERO)) == NULL)
+ return_ACPI_STATUS (AE_NO_MEMORY);
-mtx_init(as-as_mtx, ACPI semaphore, NULL, MTX_DEF);
-as-as_units = InitialUnits;
-as-as_maxunits = MaxUnits;
-as-as_pendings = as-as_resetting = as-as_timeouts = 0;
+ snprintf(as-as_name, sizeof(as-as_name), ACPI sema (%p), as);
+ sx_init(as-as_lock, as-as_name);
+ cv_init(as-as_cv, as-as_name);
+ as-as_units = InitialUnits;
+ as-as_maxunits = MaxUnits;
-ACPI_DEBUG_PRINT((ACPI_DB_MUTEX,
- created semaphore %p max %d, initial %d\n,
- as, InitialUnits, MaxUnits));
+ ACPI_DEBUG_PRINT((ACPI_DB_MUTEX,
+ created semaphore %p, max %u, initial %u\n,
+ as, InitialUnits, MaxUnits));
-*OutHandle = (ACPI_HANDLE)as;
-#else
-*OutHandle = (ACPI_HANDLE)OutHandle;
-#endif /* !ACPI_NO_SEMAPHORES */
+ *OutHandle = (ACPI_SEMAPHORE)as;
-return_ACPI_STATUS (AE_OK);
+ return_ACPI_STATUS (AE_OK);
}
ACPI_STATUS
AcpiOsDeleteSemaphore(ACPI_SEMAPHORE Handle)
{
-#ifndef ACPI_NO_SEMAPHORES
-struct acpi_semaphore *as = (struct acpi_semaphore *)Handle;
+ struct acpi_semaphore *as = (struct acpi_semaphore *)Handle;
-ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+ ACPI_FUNCTION_TRACE((char *)(uintptr_t
Re: FreeBSD 7.1 Breaks re and rl Network Interface Drivers
On Friday 16 January 2009 11:47 pm, Pyun YongHyeon wrote: On Tue, Jan 13, 2009 at 03:53:59PM +0100, Sascha Holzleiter wrote: Jung-uk Kim wrote: On Monday 12 January 2009 12:21 pm, Sascha Holzleiter wrote: Hi, i see similar problems with a re card: r...@pci0:4:7:0: class=0x02 card=0x816710ec chip=0x816710ec rev=0x10 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'RTL8169/8110 Family Gigabit Ethernet NIC' class = network subclass = ethernet After upgrading to 7.1-RELEASE (and also STABLE) the NIC doesn't seem to receive any frames. I can see the DHCP Requests on the DHCP Server but the DHCPOFFERS are never seen by the client with the re0 device. After setting promiscious mode on the interface (i.e. by tcpdump -ni re0) the interface begins to work fine. I've attached a complete dmesg output, but i think the detection works fine, here the short version: re0: RealTek 8169SC/8110SC Single-chip Gigabit Ethernet port 0x9c00-0x9cff mem 0xdfdff000-0xdfdff0ff irq 20 at device 7.0 on pci4 re0: Chip rev. 0x1800 re0: MAC rev. 0x miibus0: MII bus on re0 rgephy0: RTL8169S/8110S/8211B media interface PHY 1 on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto re0: Ethernet address: 00:1a:92:35:29:fa re0: [FILTER] Please revert SVN r180519 (or CVS r1.95.2.22) and try again: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/re/if_re.c.di ff?r1=1.95.2.21;r2=1.95.2.22 Thanks! This fixed my problem. I now have DHCP and a running network interface again with a 7.1-STABLE and the reverted r180519 changes. If you need to test another version for the changes in r180519 let me know and i'll test them on this machine. It seems that RTL8169SC does not like memory mapping. Instead of using io mapping for all revisions, how about attached patch? I found something interesting. I have another RTL8169SC that works perfectly fine without the patch. The hardware revision is 0x1800. After reading Linux driver (drivers/net/r8169c), I realised they use different masks for hardware revisions. With their logic, non-working chip seems to be 0x9800 (8110SCe) while working chip seems to be 0x1800 (8110SCd) with 0xfc80. FYI... Jung-uk Kim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD 7.1 Breaks re and rl Network Interface Drivers
On Monday 19 January 2009 04:33 pm, Jung-uk Kim wrote: I found something interesting. I have another RTL8169SC that works perfectly fine without the patch. The hardware revision is 0x1800. After reading Linux driver (drivers/net/r8169c), I realised they use different masks for hardware revisions. With their logic, non-working chip seems to be 0x9800 (8110SCe) while working chip seems to be 0x1800 (8110SCd) with 0xfc80. FYI... Now armed with the information, I made it work without reverting memory mapped I/O. :-) http://people.freebsd.org/~jkim/re/re.current2.diff http://people.freebsd.org/~jkim/re/re.stable2.diff Jung-uk Kim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD 7.1 Breaks re and rl Network Interface Drivers
On Tuesday 13 January 2009 10:27 am, Dimitry Andric wrote: Reverting r180519 seems to solve the problem of not being able to send any packets. It does not solve the other problem, which is that the interfaces can take a very long time to come up at boot time, e.g: Setting hostuuid: 3ee65237-8025-11dc-9ab5-003018a6f1a8. Setting hostid: 0xaaedab9a. Mounting local file systems:. Setting hostname: tensor.andric.com. [... pauses for 10 seconds here ...] re0: link state changed to DOWN re1: link state changed to DOWN lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST metric 0 mtu 16384 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 inet 127.0.0.1 netmask 0xff00 re0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=389bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_ UCAST,WOL_MCAST,WOL_MAGIC ether 00:30:18:a6:f1:a8 inet6 fe80::230:18ff:fea6:f1a8%re0 prefixlen 64 tentative scopeid 0x1 inet 87.251.56.140 netmask 0xffc0 broadcast 87.251.56.191 media: Ethernet autoselect (none) status: no carrier re1: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=389bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_ UCAST,WOL_MCAST,WOL_MAGIC ether 00:30:18:a6:f1:a9 inet6 fe80::230:18ff:fea6:f1a9%re1 prefixlen 64 tentative scopeid 0x2 inet 192.168.0.1 netmask 0xff00 broadcast 192.168.0.255 media: Ethernet autoselect (none) status: no carrier [...] (note also the no carrier just after upping those interfaces) [...] Can you try one of the following patches? -CURRENT: http://people.freebsd.org/~jkim/re/re.current.diff -STABLE:http://people.freebsd.org/~jkim/re/re.stable.diff These patches contain all patches suggested by me and yongari and an additional patch, which may (or may not) decrease the initial setup time. Jung-uk Kim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD 7.1 Breaks re and rl Network Interface Drivers
On Monday 12 January 2009 12:21 pm, Sascha Holzleiter wrote: Walter Venable wrote: FreeBSD 7.1 upgrade broke my network access, machine is totally offline (powered-on and I can play inside it at the terminal, but absolutely 0 network access): This happened AFTER make kernel but BEFORE make installworld. I think this implies it's a kernel driver issue. Hi, i see similar problems with a re card: r...@pci0:4:7:0: class=0x02 card=0x816710ec chip=0x816710ec rev=0x10 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'RTL8169/8110 Family Gigabit Ethernet NIC' class = network subclass = ethernet After upgrading to 7.1-RELEASE (and also STABLE) the NIC doesn't seem to receive any frames. I can see the DHCP Requests on the DHCP Server but the DHCPOFFERS are never seen by the client with the re0 device. After setting promiscious mode on the interface (i.e. by tcpdump -ni re0) the interface begins to work fine. I've attached a complete dmesg output, but i think the detection works fine, here the short version: re0: RealTek 8169SC/8110SC Single-chip Gigabit Ethernet port 0x9c00-0x9cff mem 0xdfdff000-0xdfdff0ff irq 20 at device 7.0 on pci4 re0: Chip rev. 0x1800 re0: MAC rev. 0x miibus0: MII bus on re0 rgephy0: RTL8169S/8110S/8211B media interface PHY 1 on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto re0: Ethernet address: 00:1a:92:35:29:fa re0: [FILTER] Please revert SVN r180519 (or CVS r1.95.2.22) and try again: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/re/if_re.c.diff?r1=1.95.2.21;r2=1.95.2.22 Jung-uk Kim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
