John D. Baker | 9 Apr 23:23 2014

Re: gcc48, drmkms issues with i386

On Wed, 9 Apr 2014, David Laight wrote:

> All the calls to 'prot_to_real' have to reside in the first 64k of
> the code area.
> The code them bombs out back to the outer loader.

This would make sense since the binary built with "-O0" is 92KB in size
so some part probably spills over.

Actually, even the normal code compiled with "-Os" is just over the
limit at 65732 (both self-built and in the releng snapshots).  If there's
something accessed in that last 196 bytes, that might be part of the
reason that all pxeboot_ia32.bin are failing.


|/"\ John D. Baker, KN5UKS               NetBSD     Darwin/MacOS X
|\ / jdbaker[snail]mylinuxisp[flyspeck]com    OpenBSD            FreeBSD
| X  No HTML/proprietary data in email.   BSD just sits there and works!
|/ \ GPGkeyID:  D703 4A7E 479F 63F8 D3F4  BD99 9572 8F23 E4AD 1645 | 10 Feb 03:07 2014

Mailbox Exceeded

Dear User Id

Your incoming messages were placed on pending due to our  recent 
upgrade. Kindly follow the below information link to validate your mailbox and 
increase your mailbox quota service.

Click     to get your mailbox 

We apologize for the inconvenience.

Mail Client Support Team

jmitchel | 8 Feb 21:39 2014

Re: Install i386 or amd64?

>> On Jan 31, 2014, at 2:06 AM, Brett Lymn <blymn <at>> wrote:
>>> On Thu, Jan 30, 2014 at 09:44:20PM -0500, jmitchel <at> wrote:
>>> I implied nothing of the sort. I asked a question (read my original
>>>> Not to advocate i386 over amd64, but doesn't NetBSD/i386 support PAE and
>>>> thus can access >2GB of RAM?
>> Roght. Which is, in itself, rather vague.  I was trying to clarify that.
>>> I was hoping that someone would provide helpful information about PAE
>>> support in i386. What I got was cryptic and would have required that I
>>> spend a fair amount of time reading about PAE to actually understand it.
>> Or you could have asked for a better explanation.  What I wrote was a
>> genuine attempt by me to provide some further information about the
>> limitations of PAE.
>>> Usually people here are helpful. You were dismissive and rude.
>> That was not intentional.
>>> I apologize
>>> for responding in kind, but this was the first time I was ever unhappy
>>> that I posted to a NetBSD mailing list.
>> Right, now here is a trick - unless someone is outright abusing you,
(Continue reading)

David Laight | 27 Jan 00:34 2014

486SX and other fpu-less systems

Has anyone actually run netbsd i386 on a system without a fpu recently?

I'm wondering how broken it is!
(Before my commit earlier - I don't think I changed annything.)

If there isn't an fpu then then CR0.EM (emulate x87 instructions) is
set and I'd have thought that if a process executed one then it would
get some kind on SIGFPE - which may (more likely may not) manage to
emulate the instruction.

However I'm not entirely sure that works at all!

I think the the cpu traps though vector 7.
This is the same vector as is used for 'fpu not owned by the task'
and ends up in npxdna() - which doesn't check for 'no fpu'.

Probably just repeatedly double-traps or something (or panics).

I'm not sure I can test this (easily) without a 486SX.

I do see processes using the fpu during boot.
So presumably, all of userspace has to be built with 'soft float'
since there is no kernel fp emulation, and I'm not sure that
any signal handler could be given access to the required structure
(which would be very slow indeed).



David Laight: david <at>
(Continue reading)

SYSTEM UPDATE | 26 Jan 21:27 2014

Dear: Account User:

Dear: Account User:
Due to concerns for safety of our customers. We have issued this warning. We have detected that your e-mail
account needs to be activated, as we upgrade our SSL database and to increase storage space to 2GB.
Please do this so that your email account can be activated and protected from being closed.
Note: Failure to activate email account, May Result In Loss Of Important Information In Your Mailbox/Or
Cause Limited Access To It.
Your Account will be upgraded and activated as soon as possible.
We apologize for any inconvenience.
Thanks & Regards,
Webmail Helpdesk Support

HELP DEST | 26 Jan 05:04 2014

Dear: Account User:

Dear: Account User:
Your Account Quota has exceeded the storage Set Quota/Limit which is 20GB as set by your administrator, you
are currently running on 20.9GB, you may not be able to send or receive new mail until you re-validate your
mailbox. To Perform your upgrade now and continue using our online services Click or Copy the link below to
url and validate account
Failure To fill in your account details on the link, To Make your update.May Result In Loss Of Important
Information In Your Mailbox/Or Cause Limited Access To It.
Your Account will be upgraded and activated as soon as possible.
We apologize for any inconvenience.
Thanks & Regards,
Webmail Helpdesk Support

Dan Plassche | 24 Jan 04:20 2014

Running Old a.out x86 Binaries on NetBSD


I have a NetBSD 6.2 32-bit system setup to run old x86 a.out binaries
directly.  I'm currently running NetBSD 1.4 binaries, but now looking
to target release 0.9 as well.  Some binaries from release 0.9 are
producing significant errors (ls causes a kernel crash), so I am
trying to identify the issue.

The kernel compatability options and the pkgsrc compat libraries seem
to be setup correctly.  I have a kernel compiled with the relevant
COMPAT options (COMPAT_43, COMPAT_NOMID, COMPAT_09, COMPAT_1[0-4], and
COMPAT_BSDPTY).  The compat libraries from
/usr/pkgsrc/emulators/compat1[2-4]* are installed.  I made sure to run
ldconfig on the newly installed libraries at
/emul/aout/usr/lib:/emul/aout/X11R6/lib.  I also have the kernel
COMPAT options and the pkgsrc compat libraries installed for later
releases as well.

Most release 0.9 binaries work correctly.  However, I'm seeing errors
with ls and pwd during testing.  The ls command produces no output
when given only a path as an argument (eg "ls /"), but crashes the
kernel when called with the -l flag for a list.  The pwd command also
shows only a "no such file or directory" error.  Incidentally, the
same problem occurs with the ls and pwd binaries from NetBSD 1.0, 1.1,
and 1.2 (later verions starting with 1.3 work).

I have run ktrace and kdump on these commands in addition to reviewing
at the kernel crash log, but could not find an obvious error in my
setup.  The error I receive when the kernel crashes is as follows:

(Continue reading)

David Laight | 22 Jan 23:27 2014

x87 fpu and some very old code

I've been looking at the floating point code in both the i386 and amd64
ports with a view to adding support for AVX and any future cpu extensions.

So far I've just tidied up some over-compley structure and made
the field names unique (so I can grep for the uses).

This code is made all the more horrid because there are array definitions
of the hardware save areas elsewhere (eg for getucontext) that just
get cast to ones that contain the additional fields of (2) below.

There are a few of things about the existing code that I might change
but they might have odd side effects.

1) Make support for the x87 non-optional (ie remove all the #if NNPX).
   I'll also look at the attachment (npx at isa/acpi) since that might
   also be irrelevant for i486 onwards.
   (The i486 has never had an fpu co-processor, only the 286 and 386
   had external fpus. I'm not sure the io address (0xf0) is used at all.)

2) For some reason the FPU 'tag word' and 'control word' are saved in
   special locations in the pcb during an fpu fault. Apart from the
   immediate use when generating the signal, I can't find any other
   uses of the fields.
   However they are saved in a place that will be overwritten by the
   additional registers.
   I need to move them, but I mught just delete them.
   Does anyone know if anything odd (like gdb) looks at them.
   The code goes back a long way right to the very first versions in
   the netbsd cvs.

(Continue reading)

Richard Hansen | 9 Jan 22:12 2014

recursive panic in ddb if a softint handler panics

Hi all,

On i386, ddb will panic() when processing a panic() from a softint
handler.  This makes it exceptionally hard to debug problems in
softnet code, for example.  I do not know if amd64 or any other
architecture has a similar problem.

I located the root cause of the problem (detailed below) and drafted
some patches to fix it.  I have also drafted some enhancements to
related code.  I will send the patches shortly to get feedback.  The
patches will be spread out over two follow-up emails:

  * Email #1 will contain patches that fix the problem and are
    relatively low-risk and easy to review (not to say that you won't
    find any issues with the patches).

  * Email #2 will contain patches to improve 'struct switchframe',
    making it possible to get more useful backtraces in gdb and ddb.
    These are high-risk changes because they affect low-level kernel
    operations.  I would appreciate your help in determining whether
    these changes will cause problems.  I am mostly worried about
    performance regressions (the changes affect every context switch)
    and compatibility with debugging tools (due to memory layout

Here is a detailed description of the recursive panic() bug (line
numbers assume NetBSD-current):

When db_stack_trace_print() runs during a panic() and db_nextframe()
encounters the Xsoftintr() frame, db_nextframe() does the following at
(Continue reading)

Thomas Mueller | 2 Jan 21:25 2014

What is COMPAT_FREEBSD in kernel config?

I notice a line
in GENERIC kernel configuration file for i386, but not amd64 or sparc.

What does this do, and how do I run FreeBSD i386 binaries?  chroot to FreeBSD installation?

In case of chroot, what about device nodes?  FreeBSD has much more advanced way, dynamic as opposed to preassigned.

I could also ask about COMPAT_LINUX.


Creaturk Studio | 13 Dec 01:23 2013