Re: ACPI implementation for Aspeed AST2050
I'm sorry, but the question have sense. Using HP 8510p for four years with OpenBSD, I have a great trouble with reading SMBUS (data ready on it) for years. Every release I need to apply a patch after upgrade for reading ACPII data from 8510p in time, to prevent wrong data on SMBUS. Theo replied that the patch will not be implemented in CVS because all ACPI must be rewritten in new manner. But they will do nothing since my last report... All the troubles the same as four years ago. Only the patch can be implemented to read ACPI data on HP 8510p properly during boot, no CVS implemented. So I'm interesting about AST2050 fully supported just now in CVS. Thanks. Denis On 28.03.2015 16:14, Stuart Henderson wrote: On 2015-03-28, Denis Lapshin den...@mindall.org wrote: Hi, Has OpenBSD implemented ACPI for Aspeed AST2050 in current or release? The question doesn't really make sense, ACPI is a method where the manufacturer can supply a set of BIOS tables with instructions about how to route interrupts, control power use etc. It isn't specifically implemented for each vendor, it is a common standard. This IC is present in some Dell branded Tyan products like DCS6005 cloud nodes and some other Tyan MBs. Seems Aspeed its their own product because these ICs can be found on all Tyan server mainboards as I can see. Not just Tyan, a number of vendors use Aspeed controllers. Where they're seen in servers, they usually have BMC, superio (GPIO, UARTs, PWM for fan control etc) and basic graphics support. -- Denis Lapshin mailto: den...@mindall.org
Re: ACPI implementation for Aspeed AST2050
Every release I need to apply a patch after upgrade for reading ACPII data from 8510p in time, to prevent wrong data on SMBUS. Theo replied that the patch will not be implemented in CVS because all ACPI must be rewritten in new manner. But they will do nothing since my last report... I doubt I said anything close to your interpretation.
Re: When should tables be used in pf.conf?
On 28 Mar 2015 at 8:00, Jeff wrote: Hi, We've been using pf.conf and tables for years but have recently embarked on a project to optimize pf.conf. In reading about tables it's not clear when tables are more efficient than individual rules. Is there a definitive point? Is it three entries? six entries? ten entries? If it's not a constant, is there a simple test that we can run to determine if a table is more efficient than individual rules in each case? Thanks! Jeff -- Aside from the documented performance advantage to using tables where multiple hosts are involved (whatever that exact number may be), there is a very important administrative advantage and the reason I often use tables with as few as one or two hosts in them -- you can modify entries in the table *without* having to reload your rule set (i.e. it is much safer and less disruptive). But as far as squeezing a few micro-seconds of performance (if that much) by optimizing pf.conf, I would not worry about that -- the developers are constantly improving the network stack and performance of all of its components, including the packet filter. The primary optimization we, the sysadmins, should focus on is manageability. All your marginal performance gains will be lost if the resulting pf.conf becomes unwieldy and unmanageable.
Re: reason for having return addresses in parameter stack?
On Sun, 29 Mar 2015, Joel Rees wrote: Is there any good reason for interleaving the return addresses with data on the data/parameter stack in C? I know it's the tradition, from back when it was all we could hope for to have one page per process, but that has not been the case for many years, I think. It's easy, efficient, doesn't burn another register for a second stack, and the ISA (instruction set architecture) may have direct support for it. For example, in both i386 and x86_64 the 'call' and 'ret' instructions work with the same stack pointer, %sp, as the various 'push' and 'pop' instructions. If you use %sp for the stack with return addresses so you can use 'call' and 'ret', then what is stack pointer for your arguments/locals stack? On i386, you're crying for registers already; losing another would be bad. Hmm, wasn't there a shipping processor which explicitly have two stacks something like this? I have a vague memory that it may have been itanium, but that could be a hallucination. Adding code to the program preamble to reserve space for another stack with mmap shouldn't be hard at all. Default address separation of about a quarter to a half a gig should be reasonable in 32 bit address space, at any rate. New compiler switches would be needed to tune the separation. I'm pretty sure openbsd has the means to keep a largish no-access region between the stacks. Ugh, knobs are bad if more than a tiny fraction of program have to use them. The call protocol itself should be simpler, although I might expect some debate about which stack to push frame pointers to when pushing frame pointers. The problem, I think, is in convincing the compiler to refrain from moving the frame pointer to the stack pointer on function entry. Maybe. Simpler? I doubt it. To support exception processing and debugger unwinding of calls and displaying variables from them you'll need some way to successively peel call frames off *both* stacks. To those on the list who are intimate with the compiler(s), how difficult would it be to change the function call protocol to push the program counter to a separate stack from the parameters and locals? Heh, you're talking about creating a new ABI. For difficultly level, look at the x32 ABI in Linux. It's an alternative ABI for x86-long-mode, changing relatively few things from the amd64/x86_64 ABI, and it still took a huge effort. You might want to grab a copy of the ELF ABI for a CPU you're interested in, read through it and see what sort of changes would be necessary for supporting a two-stack model. Example code sequences for argument passing, relocations, stack unrolling, registers set on process entry,... Oooh, and then threads come into play, where programs expect to be able to specify a single size for the stack, so maybe you should have the two stacks grow towards each other from opposite ends of the allocated stack memory? Or am I speculating about a different world, still? Tomorrow is a different world, but only slightly so.
Re: SHA256 fingerprints on AnonCVS web page
On 28/03/15 16:22, Christian Weisgerber wrote: Should they be added? Yes, they should, but we may have to wait until 5.7 is released for the mirror maintainers to update their machines. Ah, thanks for the clarification. Was not aware that they were that new. Bernd
reason for having return addresses in parameter stack?
This is a question that has bothered me for more than twenty-five years. Blame it on my being one of those forthies, I guess. Recent posts encourage me to ask again. Is there any good reason for interleaving the return addresses with data on the data/parameter stack in C? I know it's the tradition, from back when it was all we could hope for to have one page per process, but that has not been the case for many years, I think. Adding code to the program preamble to reserve space for another stack with mmap shouldn't be hard at all. Default address separation of about a quarter to a half a gig should be reasonable in 32 bit address space, at any rate. New compiler switches would be needed to tune the separation. I'm pretty sure openbsd has the means to keep a largish no-access region between the stacks. The call protocol itself should be simpler, although I might expect some debate about which stack to push frame pointers to when pushing frame pointers. The problem, I think, is in convincing the compiler to refrain from moving the frame pointer to the stack pointer on function entry. Maybe. To those on the list who are intimate with the compiler(s), how difficult would it be to change the function call protocol to push the program counter to a separate stack from the parameters and locals? Or am I speculating about a different world, still? Joel Rees Computer memory is just fancy paper, CPUs just fancy pens. All is a stream of text flowing from the past into the future.
When should tables be used in pf.conf?
Hi, We've been using pf.conf and tables for years but have recently embarked on a project to optimize pf.conf. In reading about tables it's not clear when tables are more efficient than individual rules. Is there a definitive point? Is it three entries? six entries? ten entries? If it's not a constant, is there a simple test that we can run to determine if a table is more efficient than individual rules in each case? Thanks! Jeff --
Re: ACPI implementation for Aspeed AST2050
On 2015-03-28, Denis Lapshin den...@mindall.org wrote: Hi, Has OpenBSD implemented ACPI for Aspeed AST2050 in current or release? The question doesn't really make sense, ACPI is a method where the manufacturer can supply a set of BIOS tables with instructions about how to route interrupts, control power use etc. It isn't specifically implemented for each vendor, it is a common standard. This IC is present in some Dell branded Tyan products like DCS6005 cloud nodes and some other Tyan MBs. Seems Aspeed its their own product because these ICs can be found on all Tyan server mainboards as I can see. Not just Tyan, a number of vendors use Aspeed controllers. Where they're seen in servers, they usually have BMC, superio (GPIO, UARTs, PWM for fan control etc) and basic graphics support.
Re: SHA256 fingerprints on AnonCVS web page
On 2015-03-28, Bernd Schoeller ber...@fams.de wrote: The authenticity of host 'openbsd.cs.fau.de (131.188.40.91)' can't be established. ECDSA key fingerprint is SHA256:gcWYMCjQHnmA97RT53MGCKp2kZ3pk5TZPFdYTJQl9/w. Unfortunately, the SHA256 fingerprints are not published on http://www.openbsd.org/anoncvs.html so I was not able to verify the host. $ ssh -oFingerprintHash=md5 openbsd.cs.fau.de The authenticity of host 'openbsd.cs.fau.de (2001:638:a000:4140:131:188:40:91)' can't be established. ECDSA key fingerprint is MD5:f0:d1:64:e6:6b:2f:9e:1e:85:aa:75:e3:a0:52:d3:5a. Are you sure you want to continue connecting (yes/no)? Should they be added? Yes, they should, but we may have to wait until 5.7 is released for the mirror maintainers to update their machines. -- Christian naddy Weisgerber na...@mips.inka.de
SHA256 fingerprints on AnonCVS web page
Hi - I just tried to update my ports tree and got the following message, using openbsd.cs.fau.de as AnonCVS host: The authenticity of host 'openbsd.cs.fau.de (131.188.40.91)' can't be established. ECDSA key fingerprint is SHA256:gcWYMCjQHnmA97RT53MGCKp2kZ3pk5TZPFdYTJQl9/w. Unfortunately, the SHA256 fingerprints are not published on http://www.openbsd.org/anoncvs.html so I was not able to verify the host. Should they be added? Regards, Bernd
problems building boost on sparc
Hi, continuing, time permitting, to build subversion on SPARC. Ruby and Python build and installed! I now have a problem with boost: ... configure: creating ./config.status config.status: executing default commands Adjustments to boost configuration have been written to user.hpp. Copy this to boost/config/user.hpp to use as is, or define BOOST_SITE_CONFIG to point to its location. TREAT THIS FILE WITH CARE. Autoconf generated options are not infallible! Building Boost.Build engine with toolset gcc... Failed to build Boost.Build build engine Consult 'bootstrap.log' for more details This is the log content: $ cat ./pobj/boost-1.53.0/boost_1_53_0/bootstrap.log ### ### Using 'gcc' toolset. ### rm -rf bootstrap mkdir bootstrap gcc -o bootstrap/jam0 command.c compile.c constants.c debug.c function.c glob.c hash.c hdrmacro.c headers.c jam.c jambase.c jamgram.c lists.c make.c make1.c object.c option.c output.c parse.c pathunix.c regexp.c rules.c scan.c search.c subst.c timestamp.c variable.c modules.c strings.c filesys.c builtins.c pwd.c class.c native.c md5.c w32_getreg.c modules/set.c modules/path.c modules/regex.c modules/property-set.c modules/sequence.c modules/order.c execunix.c fileunix.c /tmp//ccNOetJC.o(.text+0x4e38): In function `builtin_pad': : warning: strcpy() is almost always misused, please use strlcpy() /tmp//cc25yHy8.o(.text+0x32c): In function `outf_int': : warning: sprintf() is often misused, please use snprintf() ./bootstrap/jam0 -f build.jam --toolset=gcc --toolset-root= clean Bus error (core dumped) I then look for the core file: $ find . -name \*.core ./boost-1.53.0/boost_1_53_0/tools/build/v2/engine/jam0.core If I open the core file in gdb, it doesn't say much: Program terminated with signal 10, Bus error. #0 0x00042dd0 in ?? () (gdb) bt #0 0x00042dd0 in ?? () #1 0x00042dc4 in ?? () Previous frame identical to this frame (corrupt stack?) Anybody else did build boost on sparc? Suggestions? Riccardo
Re: icmp6 get dropped on gif tunnel
On 2015-03-28, Geoff Steckel g...@oat.com wrote: Is there a rule which will guarantee that a packet will be logged no matter what happens to it later in pf processing? match log(matches) might be useful here. The IPv6 packets cross routing domains to get to/from gif0. This may possibly be involved in the problem. I've had a similar setup in the past which worked, but I used route-to/reply-to rather than routing domains.
ACPI implementation for Aspeed AST2050
Hi, Has OpenBSD implemented ACPI for Aspeed AST2050 in current or release? This IC is present in some Dell branded Tyan products like DCS6005 cloud nodes and some other Tyan MBs. Seems Aspeed its their own product because these ICs can be found on all Tyan server mainboards as I can see. Thank you for answer in advance. Denis
