Re: Driver tpm(4) and third party packages for trusted platform modules
In message <20100811203042.ga26...@modermoor.genua.de>, Hans-Joerg Hoexer wrote: >Hi, > >On Wed, Aug 04, 2010 at 07:39:41PM +0900, Takanori Watanabe wrote: >> Update my patch. Split bus attachment from main driver file >> (need to update sys/conf/files), add detach method for convinience, >> and attach softc to cdev.si_drv1 . > >I've updated our diff for 9-current, including your patch. Ok, I've commit them to the head. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Why is TUNABLE_INT discouraged?
2010/8/9 Dag-Erling Smørgrav : > Garrett Cooper writes: >> Why would someone express a tunable in a memory address (not being >> sarcastic... I just don't see why it makes sense right now, but if >> there's a valid reason I'm more than happy to be educated :)..)? > > A few examples: > > hw.acpi.host_mem_start > hw.pci.host_mem_start > hw.physmemstart > > The following are not addresses, but can be > 32 bits on 64-bit machines > and even on some 32-bit machines using PAE / PTE: > > hw.physmem > vm.kmem_size > vm.kmem_size_max > vm.kmem_size_min Ok -- good to know. > It might be a good idea to introduce TUNABLE_POINTER and TUNABLE_SIZE. I would actually argue against doing that because it would only create divergence between sysctl and tunable KPIs... but that's just me. The patch I provided before would converge sysctl and tunables a bit more (and I'd more than happily submit patches for the other missing cases on the sysctl side to get parity with the tunables). If it makes sense to add the sysctls _and_ the tunables for POINTER and SIZE though, I'll provide a patch for both cases in one shot. (BTW, when you say TUNABLE_SIZE, I assume it would be a size_t quantity?) Something might need to be done to the values returned by the tunables though, because they don't respect boundaries, and can overflow right now (which exacerbates the issue with values crammed into smaller datatypes)... Thanks! -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Why is TUNABLE_INT discouraged?
Garrett Cooper writes:
> Dag-Erling Smørgrav writes:
> > It might be a good idea to introduce TUNABLE_POINTER and TUNABLE_SIZE.
> I would actually argue against doing that because it would only create
> divergence between sysctl and tunable KPIs...
Not if we also introduce corresponding SYSCTLs. Note that my idea is to
have these as aliases for the correct primitive types.
> (BTW, when you say TUNABLE_SIZE, I assume it would be a size_t quantity?)
Yes.
> Something might need to be done to the values returned by the tunables
> though, because they don't respect boundaries, and can overflow right
> now (which exacerbates the issue with values crammed into smaller
> datatypes)...
Yes. How about this:
- rename getenv_quad() to getenv_signed() and getenv_unsigned()
- add min / max arguments
- implement getenv_quad() (and all the others) in terms of
getenv_number()
e.g.
int
getenv_uint(const char *name, unsigned int *data)
{
unsigned long long tmp;
int rval;
if ((rval = getenv_unsigned(name, &tmp, 0, UINT_MAX)) == 0)
*data = (unsigned int)tmp;
return (rval);
}
(note that due to the min / max arguments, the complexity of handling
both signed and unsigned values in the same function probably exceeds
the complexity of having two very similar functions)
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: real memory falsely reports 8G, BIOS & avail memory reports 1G
> dmidecode --type memory # /usr/ports/sysutils/dmidecode/ > shows this laptop not returning good output, just > # dmidecode 2.10 > SMBIOS 2.3 present. > > Wrong DMI structures count: 43 announced, only 23 decoded. After cold reboot, though dmesg still weird: real memory = 8572108800 (8175 MB) Physical memory chunk(s): 0x1000 - 0x0009bfff, 634880 bytes (155 pages) 0x00f1a000 - 0x3e19, 1026056192 bytes (250502 pages) avail memory = 1018191872 (971 MB) dmidecode now gives more info (maybe new libs), but dmidecode output still weird, some extracts below, full version at http://berklix.com/~jhs/hardware/laptops/novatech-8355/dmidecode/ I've asked Novatech about a new BIOS for this MiTAC laptop. Handle 0x0013, DMI type 16, 15 bytes Physical Memory Array Use: System Memory Maximum Capacity: 256 MB Error Information Handle: 0x001A Number Of Devices: 2 Handle 0x0017, DMI type 17, 27 bytes Memory Device Array Handle: 0x0013 Total Width: 64 bits Data Width: 64 bits Size: 2047 MB Form Factor: DIMM Set: None Locator: DRAM Slot 0 Bank Locator: Banks 0/1 Type: DRAM Type Detail: EDO Handle 0x0018, DMI type 17, 27 bytes Memory Device Array Handle: 0x0013 Total Width: 64 bits Data Width: 64 bits Size: 2048 MB Form Factor: DIMM Set: None Locator: DRAM Slot 1 Bank Locator: Banks 2/3 Type: DRAM Type Detail: EDO Handle 0x0019, DMI type 17, 27 bytes Memory Device Array Handle: 0x0013 Total Width: 64 bits Data Width: 64 bits Size: 4080 MB Form Factor: DIMM Set: Unknown Locator: DRAM Slot 2 Bank Locator: Banks 4/5 Type: DRAM Type Detail: EDO Handle 0x001B, DMI type 19, 15 bytes Memory Array Mapped Address Starting Address: 0x000 Ending Address: 0x00043FF Range Size: 1048577 kB Handle 0x001C, DMI type 20, 19 bytes Memory Device Mapped Address Starting Address: 0x000 Ending Address: 0x1FF Range Size: 2048 GB Handle 0x001D, DMI type 20, 19 bytes Memory Device Mapped Address Starting Address: 0x200 Ending Address: 0x3FF Range Size: 2048 GB Handle 0x001E, DMI type 20, 19 bytes Memory Device Mapped Address Starting Address: 0x000 Ending Address: 0x3FB Range Size: 4080 GB Cheers, Julian -- Julian Stacey: BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Mail in plain text, Not HTML, quoted-printable & base 64 dumped with spam. Avoid top posting, It cripples itemised cumulative responses. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Support for WD Advanced Format disks
jhell writes: > On stable/8 this is needed to build. Seems the need for linking against > libutil came in revision r211233. Yes, I forgot to commit the Makefile. Thank you for reminding me. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Support for WD Advanced Format disks
On 08/10/2010 13:44, Dag-Erling Smørgrav wrote: > Right now, I have two requests. The first is that people who have > Advanced Format disks run a program I wrote that measures the > performance of aligned and misaligned writes of different sizes. > > % svn co http://svn.freebsd.org/base/user/des/phybs > % cd phybs > % make > % ./phybs -w /dev/adN DES, On stable/8 this is needed to build. Seems the need for linking against libutil came in revision r211233. Index: Makefile === --- Makefile(revision 211244) +++ Makefile(working copy) @@ -4,5 +4,6 @@ CSTD ?= c99 WARNS ?= 6 MAN = # none +LDFLAGS += -lutil .include Regards, -- jhell,v ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Any way to fix '/usr/lib/libstdc++.so.6: version GLIBCXX_3.4.11 required by ... not found'?
Hi! I'm trying to update graphics/lightspark-devel port to the latest version, and it's firefox plugin now doesn't load. The supposed reason for that is that the plugin is build with gcc 4.4+ (as it uses c++0x features), and firefox is built with our default gcc 4.2, thus libstdc++ versions doesn't match -> dlopen fails. LoadPlugin: failed to initialize shared library /usr/local/lib/browser_plugins/lightspark-devel/liblightsparkplugin.so [/usr/lib/libstdc++.so.6: version GLIBCXX_3.4.11 required by /usr/local/lib/browser_plugins/lightspark-devel/liblightsparkplugin.so not found] Is there a way to fix that, maybe some linker magic? -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amd...@amdmi3.ru ..: jabber: amd...@jabber.ruhttp://www.amdmi3.ru ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Any way to fix '/usr/lib/libstdc++.so.6: version GLIBCXX_3.4.11 required by ... not found'?
>I'm trying to update graphics/lightspark-devel port to the latest
>version, and it's firefox plugin now doesn't load. The supposed reason
>for that is that the plugin is build with gcc 4.4+ (as it uses c++0x
>features), and firefox is built with our default gcc 4.2, thus libstdc++
>versions doesn't match -> dlopen fails.
>
>LoadPlugin: failed to initialize shared library
>/usr/local/lib/browser_plugins/lightspark->devel/liblightsparkplugin.so
>[/usr/lib/libstdc++.so.6: version GLIBCXX_3.4.11 required by
>>/usr/local/lib/browser_plugins/lightspark-devel/liblightsparkplugin.so not
>found]
>
>Is there a way to fix that, maybe some linker magic?
I don't know, since we don't have a dlmopen(). Have you tried using
libmap.conf(5) to use the newer libraries in ${LOCALBASE}/lib/gcc44 ,
rather than their base system counterparts, for firefox? Or using
wrappers that set LD_LIBMAP or LD_LIBRARY_PATH, to attain the same
end? The newer libraries are supposed to be mostly
backwards-compatible with the old.
b.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
