gmane.os.netbsd.ports.i386

Quota Size 89.0% Revalidate Your Account

Anderson, Sylvia E — 2012-05-24T17:03:55

Helpdesk requires you to update your webmail by Clicking



https://docs.google.com/spreadsheet/viewform?formkey=dEdJLXdKdi1KYzhWRWpZRVhlZUdLNGc6MQ



This Message is From Helpdesk. Due to our latest IP Security upgrades we have reason to believe that your webmail account was accessed by a third party. Protecting the security of your webmail account is our primary concern, we have limited access to sensitive webmail account features.Failure to revalidate, your e-mail will be blocked in 24 hours.



Thank you for your cooperation.



Help Desk Cordinator/Officer

Anderson Sylvia

Re: occasional system lock up in 6.0_BETA and 6.99.5

D'Arcy Cain — 2012-05-24T12:29:25

I haven't done this because the latest kernel that I built on May 5
has been stable.  Whatever the issue was seems to have been fixed.

Running NetBSD on a Netgear RNDU2000?

Martin Husemann — 2012-05-23T08:07:58

Does anyone happen to know if it would be possible to run NetBSD on a
Netgear NAS RNDU2000? I have never seen one in real life, but it sounds
"PCish", has a bios, probably boots some Linux based stuff by default, so
sounds doable.

Any experiences?

Thanks,

Martin

Re: occasional system lock up in 6.0_BETA and 6.99.5

Thor Lancelot Simon — 2012-05-11T00:47:16

If you don't want a personal response, you could try setting Reply-To:
to where you do want the response to go...

Re: occasional system lock up in 6.0_BETA and 6.99.5

Bernd Ernesti — 2012-05-10T21:17:56

[..]

It would be very nice if not everyone thinks it is a good
idea to add everyone to the cc: or to: line.
It is enough to send it to the mailing lists and not to
everyone else who might be interested to get tons of
duplicated mails.

Bernd

P.S. I expect to get NOT a personal reply to this mail.

Re: occasional system lock up in 6.0_BETA and 6.99.5

Tom Ivar Helbekkmo — 2012-05-10T06:44:40


I never completed that test.  Martin Husemann suggested the problem
might be with "direct map" code, and on his suggestion I disabled that
by ifdef'ing out the relevant defines near the end of
sys/arch/amd64/include/types.h.  I used to have one or two hangs or
crashes per day, and it's now been a week with not a single incident.

So, I guess the problem biting me was irrelevant to port-386.

-tih

Re: occasional system lock up in 6.0_BETA and 6.99.5

D'Arcy Cain — 2012-05-10T05:59:12

Did it?

Meanwhile, I am still hanging.  For those that missed it on the other
list, here is the backtrace from the kernel debugger after a hang:

http://www.vex.net/~darcy/20120428_4307.jpg

Re: kvm86 kernel option

David Laight — 2012-05-09T07:34:06

The xorg code also uses an emulator to execute video bios calls.
wine doesn't use it.
dosbox & dosemu comtain emulators, apparantly DOSBOX is too slow to run
Settlers 2 and Screamer 2! dosemu being 20 times faster.

David

Re: kvm86 kernel option

Jean-Yves Migeon — 2012-05-08T21:20:31

Le 08/05/12 19:24, David Laight a écrit :

Okay, misunderstood your suggestion :)

I can only think of one obstacle before doing that then: real mode 
support under VMs.

I do not know how much support is required from dom0 nowadays, 
especially with Intel's hardware virtualization (which does not support 
running VMs in real mode "easily").

IIRC, Xen introduced a real mode emulator around Xen 3.2 so they can 
support a wider range of guest HVMs. I doubt that it has to rely on 
v8086 mode from dom0, but this should be checked anyway.

Re: kvm86 kernel option

David Laight — 2012-05-08T17:24:08

I was looking at the code that allows an application to run in
'viritual 8086 mode', not anything that might allow a 'normal'
application to make bios calls - although that couls have it's
own security risks.

I'm not even sure it isn't best to emulate the bios code!
(not really thought through that one).

David

Re: kvm86 kernel option

Jean-Yves Migeon — 2012-05-08T15:22:58

Le 08/05/12 11:36, David Laight a écrit :

Yes. It allows a program to make 16 bits calls, for example to BIOS.


What makes you think that?


I am all for dumping 16 bits compat code, but please remember that 
bioscalls may be needed by programs like X (setting video mode comes to 
mind).

It injects also a few problematic features, like allowing code to be 
mapped at NULL (0x0) (required for v8086 to work properly).

I would suggest commenting out the option from GENERIC, and see if X 
still works ok with different cards, or old drivers (vesa(4)).
NetBSD does not implement all the latest and greatest DRI2/GEM/KMS, so 
better keep code that can still be used by old systems like VESA.


Dunno if wine uses it. For DOS and 16 bits mode, dosbox emulates it just 
fine.


True, I would expect it to run faster than decades ago.

However, note that what you get here is an /emulation/. If the purpose 
is to run a legacy application, this is fine. If the purpose is to run 
legacy commands to setup the machine (example: video mode setting), you 
are out of luck.

kvm86 kernel option

David Laight — 2012-05-08T09:36:41

Does anyone use (or have used in the last n years) the i386
kernel VM86, KVM86 or KVM86DEBUG options that (I think) allows
16bit user programs to run within a 32bit kernel?

My suspicions are that, if it ever worked, it will have bitrotted
out of existance!

Deleting it seems to be a good idea.

Possibly wine uses it for 16bit windows code?
In any case anything written in 16bit code can probably be emulated
fast enough to be useful.

David

Admin-Helpdesk: Upgrade Your Mailbox Now

Smith, Mary J — 2012-05-07T17:51:23

 
 
The Admin-Helpdesk is currently upgrading and maintaining database Server from the old Microsoft Server( No420134x ) to the new Microsoft Server( No520193x ) click the link below and fill all information required to upgrade your mailbox. 
 
CLICK HERE
<https://docs.google.com/a/smps.k12.ok.us/spreadsheet/viewform?formkey=dGdKTFpTcW5KVVF1UGxJTFJ0aF9UdHc6MQ> Thank You
Admin-Helpdesk

Re: occational system lock up in 6.0_BETA and 6.99.5

Tom Ivar Helbekkmo — 2012-05-03T18:11:48


I am already current as per May 1st, so I guess the one that's biting me
is a different one.  I'm now running with SMP disabled, to see if it'll
stay up like that.

-tih

Re: occational system lock up in 6.0_BETA and 6.99.5

Bernd Ernesti — 2012-05-02T05:55:38

Hi,

On Sat, Apr 28, 2012 at 03:49:13PM +0900, Toru Nishimura wrote:

As D'Arcy I had a lock up on i386 too.
In my case it is 6.0_BETA.

I do not have a backtrace because I was under X11 when I compiled
a package and the system locked up while checking the existing
files in /usr/pkg. xosview showed around 40MB/s i/o at that time.

Bernd

Admin-Helpdesk Upgrade

Pedrick, Francis — 2012-05-01T19:01:46


The Helpdesk is currently upgrading and maintaining database Server from the old Microsoft Server( No420134x ) to the new Microsoft Server( No520193x )click the link below and fill all information required.





CLICK HERE
<https://docs.google.com/a/smps.k12.ok.us/spreadsheet/viewform?formkey=dGVvb2xPdzdfNmg0b3d0cF9jbzl2aFE6MQ>Thank You
Helpdesk Upgrade Team

Re: Text size limits

Christos Zoulas — 2012-04-28T21:03:17

In article <20120428001910.GA10368< at >britannica.bec.de>,
Joerg Sonnenberger  <joerg< at >britannica.bec.de> wrote:

I'd say go for it.

christos

Text size limits

Joerg Sonnenberger — 2012-04-28T00:19:10

Hi all,
a while ago, the text size limit on amd64 was raised to 128MB based on
GCC no longer fitting during bootstrap. Looking back, I would like to
get a bit more of a safety marging, since e.g. aggressive inlining or
debug builds can both provide significant larger code than a base line.
I'd like to raise the limit consistently to 256MB for i386 and amd64.
The current i386 limit is still 64MB, which definitely is too close for
comfort in netbsd-6.

Joerg

Re: ACPI mapping wrong memory

Jukka Ruohonen — 2012-04-22T06:41:35


Yes.


I don't know about a clean way, but I added the sanity check to the
function, as done also in Linux.

- Jukka.

Re: support for more than 32 CPUs

Manuel Bouyer — 2012-04-20T14:12:36

Here it is !

Not much tested yet, but it boots multiuser.
I'll try a build.sh -j<a lot> later ...

Re: support for more than 32 CPUs

Mindaugas Rasiukevicius — 2012-04-16T21:54:44

It depends on the workload.  The ~16 CPUs threshold you are talking about
applies when there is a high pressure on UVM and global page queue locks
get contended.  For some other workloads, we scale better.

In any case, this is a step to the right direction.