headers
Mike Miskulin | 3 Feb 2010 15:20
Picon
Favicon

32 binaries on amd64

Hi - long time slackware user but only netbsd once long ago, please accept my apologies if I've asked a dumb
question but I was not able to google an answer.

I've set up a netbsd amd64 box.  I've found what appears to be some good info on setting up the pkg system for
building 32 bit versions of various packages.  However, I really don't want to be locked into building
every time from source.   Is it possible to use the binaries for i386?  From what I can tell, it seems that it may
be possible but that additional steps are required.  I've pulled a couple of packages.  Some work fine,
others have complained about missing libraries (which appear to exist in 64 bit version but do not in the
emul/netbsd32/lib).  I'm a bit fearful of then attempting to get these and having the system mistakenly
overwrite the 64 bit verions.

Can somebody give me an idea of a) can it be done, b) what additional steps are necessary and c) is it worth the trouble?

Thanks again for your help.

LB
Permalink | Reply | 0 comments |
headers
Nicolas Joly | 5 Feb 2010 10:13
Picon
Picon
Favicon

Re: Saving %gs and %fs over interrupts and syscalls

On Thu, Jan 21, 2010 at 10:01:42PM +0000, David Laight wrote:
> Having fixed the i386 'trap during return to user' I looked at the
> amd64 code - I shouldn't have!
[...]
> The NetBSD kernel only ever saves the %fs and %gs segment registers.
> It doesn't save either of the FS.Base or GS.Base registers that might
> need to be set by userspace.  I don't think anything 'normal' in NetBSD
> tries to set these values, but they are probably used by Linux for
> thread specific data - and NetBSD will probably need to do something similar.

Yep.

> It is possible that things like the JVM are trying to use Linux syscalls
> to set these values - the fact that NetBSD fails to save/restore them
> may be relevant to the failure of the JVM in NetBSD amd64.

This really affects all compat linux programs that calls arch_prctl(2).
Which means about 99% of linux binaries ...

> I think it is necessary to save and restore values of %fs, %gs, FS.Base
> and GS.Base on system calls and interrupts.  This is rather problematical
> but restoring FS.Base after %fs while ensuring that if the kernel
> changes the %fs that a process would restore will also modify the saved
> Fs.Base might work!

That's AFAIK the current problem on Intel CPUs. Restoring the %fs
value nukes the FS.Base ... I tested it by nuking all `movw XX,%fs'
along the way (made the nop), and then basic compat linux programs
started working (but this indeed broke compat linux32).
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jonathan A. Kollasch | 10 Feb 2010 21:50
Gravatar

Re: Are there ACPI watchdog timers?

On Sun, Feb 07, 2010 at 03:56:49PM -0500, Thor Lancelot Simon wrote:
> I don't like the idea of banging directly on device registers if ACPI
> might think it's managing some other part of the device -- or the whole
> thing.
> 
> Most SuperI/O and environmental sensor chips (and combinations thereof)
> these days include watchdog timers.  I want to hook some of these up to
> /dev/watchdog but, if possible, I'd prefer to use the ACPI interface -- if
> there even is one.
> 
> Can someone tell me if there is such a thing, if it's generaly implemented,
> and if so, where it's described?

Looks like there is.

http://www.microsoft.com/whdc/system/sysinternals/watchdog.mspx
http://www.microsoft.com/whdc/system/sysinternals/hw-wdt.mspx

No idea how widely implemented these are, look
for a WDAT or WDRT table in acpidump output.

	Jonathan Kollasch
Permalink | Reply | 0 comments |
headers
Jean-Yves Migeon | 22 Feb 2010 23:35
Picon
Favicon

Re: [PAE support] Types + cosmetic fixes

On 02/22/10 22:13, Christos Zoulas wrote:
> Jean-Yves Migeon<jeanyves.migeon <at> free.fr>  wrote:
>> [snip]
>> In case someone wonders, if PAE is added as default option for ALL, more
>> fixes will be needed in some drivers under sys/dev/ (paddr_t vs unsigned
>> long issues). Question is: should it be added to ALL for additional checks?
>
> I think so

Okay

> and don't forget the drm code which makes assumptions about
> vsize_t... What is vsize_t now?

Remains unsigned long.

--

-- 
Jean-Yves Migeon
jeanyves.migeon <at> free.fr
Permalink | Reply | 0 comments |
headers
Andrew Doran | 23 Feb 2010 12:41
Picon

Re: [PAE support] Types + cosmetic fixes

On Mon, Feb 22, 2010 at 10:25:35AM +0100, Jean-Yves Migeon wrote:

> Opinions welcomed.

I would like to see paddr_t and related types always be 64-bit, regardless
of whether the kernel is PAE enabled.  If not we effectively create a new
platform.  Do you envision any compatibility problems with userspace
applications from this change?

Thanks.
Permalink | Reply | 32 comments |
headers
Jean-Yves Migeon | 23 Feb 2010 16:57
Picon
Favicon

Re: [PAE support] Types + cosmetic fixes


On Tue, 23 Feb 2010 11:41:17 +0000, Andrew Doran <ad <at> NetBSD.org> wrote:
> On Mon, Feb 22, 2010 at 10:25:35AM +0100, Jean-Yves Migeon wrote:
> 
>> Opinions welcomed.
> 
> I would like to see paddr_t and related types always be 64-bit,
regardless
> of whether the kernel is PAE enabled.  If not we effectively create a new
> platform.

Yep, i386-pae. IMHO, modules cannot be "safely" shared between PAE and
non-PAE.

>  Do you envision any compatibility problems with userspace
> applications from this change?

Typical userspace applications, no. However, I suspect that programs like
crash(8) or libkvm would be affected by such a change. As well as those
reading stuff directly in kmem.

There is much more work for in-kernel code though; for example, iterating
through the PDs/PTs is not as easy as iterating in a paddr_t array
(consider a 64-bits paddr_t with a non-PAE kernel). We would have to split
pd_entry_t from paddr_t, which is currently not the case.

Maybe there will be overhead by using 64 bits variables for paddr_t too; I
don't know.

Why would you like to have paddr_t as always being 64 bits :) ?
(Continue reading)

Permalink | Reply | 29 comments |
headers
Manuel Bouyer | 23 Feb 2010 20:15

Re: [PAE support] Types + cosmetic fixes

On Tue, Feb 23, 2010 at 04:57:55PM +0100, Jean-Yves Migeon wrote:
> > I would like to see paddr_t and related types always be 64-bit,
> regardless
> > of whether the kernel is PAE enabled.  If not we effectively create a new
> > platform.
> 
> Yep, i386-pae. IMHO, modules cannot be "safely" shared between PAE and
> non-PAE.

Yes. And I don't think making paddr_t 64bits unconditionally would
make them magically compatible for modules. There would be other issues.

> 
> >  Do you envision any compatibility problems with userspace
> > applications from this change?
> 
> Typical userspace applications, no. However, I suspect that programs like
> crash(8) or libkvm would be affected by such a change. As well as those
> reading stuff directly in kmem.

I don't think so. kmem grovellers care about virtual addresses,
not physical addresses. At last I've not noticed anything bad with
i386PAE Xen kernels.

> 
> There is much more work for in-kernel code though; for example, iterating
> through the PDs/PTs is not as easy as iterating in a paddr_t array
> (consider a 64-bits paddr_t with a non-PAE kernel). We would have to split
> pd_entry_t from paddr_t, which is currently not the case.
(Continue reading)

Permalink | Reply | 23 comments |
headers
Manuel Bouyer | 23 Feb 2010 20:27

Re: [PAE support] Types + cosmetic fixes

On Mon, Feb 22, 2010 at 10:25:35AM +0100, Jean-Yves Migeon wrote:
> 
> Hi lists,
> 
> Before asking for review of the patch regarding PAE support inside native
> i386 kernel (inspired from jmorse <at>  work from a few weeks ago), I would like
> to commit these beforehand ([1] & [2]). I made them separate because they
> are not for PAE support "per-see."
> 
> They are mostly types + cosmetic fixes. As some of you may now, introducing
> PAE affects the x86 paradigm inside NetBSD a bit:
> - sizeof paddr_t != sizeof vaddr_t (64 bits for paddr_t, 32 bits for
> vaddr_t)

We already gave platorms like that (or had - the sh5 port). we already
have it for Xen ... So no major problems with this I guess.

> - "unsigned long" cannot be considered as a physical address anymore

It should not in the first place :)

> 
> This affect a couple of printfs(), printk() and debugging messages, as well
> as some variables types used inside x86 pmap [1].
> 
> Second small patch [2] contains fixes regarding UVM:
> - RLIMIT_RSS which is now set to VM_MAXUSER_ADDRESS (shouldn't it be set to
> MIN(VM_MAXUSER_ADDRESS, ptoa(uvmexp.free) instead?),

I think it should be MIN(VM_MAXUSER_ADDRESS, ptoa(uvmexp.free).
(Continue reading)

Permalink | Reply | 2 comments |
headers
matthew green | 23 Feb 2010 21:57
Picon
Favicon

re: [PAE support] Types + cosmetic fixes


i don't see how changing the size of paddr_t affects userland except
for kvm and kvm is already special case and can/should be able to
handle it.  sparc deals with things like this already.

.mrg.
Permalink | Reply | 0 comments |
headers
Antti Kantee | 24 Feb 2010 13:12
Picon
Picon

Re: [PAE support] Types + cosmetic fixes

On Wed Feb 24 2010 at 13:03:26 +0100, Manuel Bouyer wrote:
> On Wed, Feb 24, 2010 at 11:59:33AM +0000, Andrew Doran wrote:
> > On Wed, Feb 24, 2010 at 10:16:56AM +0100, Manuel Bouyer wrote:
> > 
> > > I'm not sure what the effect to configure and similar scripts would be.
> > > If this is for modules, I think this needs more though. I suspect some
> > > kernel build options can also cause ABI changes which can cause modules
> > > to fail, so modules should really be per kernel (at last for now, once
> > > we have a documented API useable by modules, this can be rediscussed).
> > 
> > Such differences would be bugs and should be fixed.  Our efforts
> > to eliminate major ABI differences from the kernel have to date
> > been largely successful.
> 
> Which ABI ? where is it specified ?
> Sorry, but as long as what part of the kernel API is availble to module and
> what part is not is not clearly specified, sharing module between different
> kernel builds will work only by luck.

I have a theory that luck is the main component in why any operating
system works at all.

The fact that binary kernel modules work in rump (on i386) should be
proof positive that the fictious and unspecified ABI is more real than
what the unlucky would want to believe.
Permalink | Reply | 2 comments |

Gmane