matthew green | 28 Feb 10:44 2015

i386 vs radeondrmkms problem - isa attachments suck

hi folks.

i've been trying to find a least-ugly solution to the radeondrmkms
on i386 problem.  quick summary of what's wrong:

	radeondrmkms doesn't complete attachments (and most
	importantly create a wsdisplay) until mountroot completes.
	this means it happens quite late in boot.  in i386 GENERIC,
	vga <at> isa and pcdisplay <at> isa are still enabled and they will
	attach to the legacy vga device, and present a wsdisplay0
	to the system.  later, radeon0 attaches, and we get a
	wsdisplay1 that has taken over the console output.

this leaves us with a non-working console output, and the inability
to run X11 even if accessed remotely.

my first attempt (that is currently commited), made the radeondrmkms
driver attempt to map the isa vga registers to reserve them from the
vga <at> isa, and while that worked on my serial console machine, it does
not work on a normal system due to x86 consinit() attaching the
basic vga console driver (so we get early console output.)  in this
case, it has already mapped these registers (ie, radeon is unable
to map them) and the later real attachment knows not to attempt it
again.  so that method doesn't work.

we could have the vga driver detach itself at the right point, but
that leaves the console detached for quite a while, during the time
that drm is getting setup (ie, we'd miss several of its early
messages.)  that seems less than desireable.
(Continue reading)

Stephan | 27 Feb 12:55 2015

Adding a .c-file to the kernel


I want to add a new .c-file to the kernel source under sys/kern.
What´s the right way to make the build system aware so it we be
compiled into a new kernel image?

I´m also unsure about the name. The code implements an IPC mechanism.
I guess uipc_ is a good prefix, though I don´t know what 'u' means in
this case.

Maxime Villard | 25 Feb 12:30 2015

PaX: Heritage bug

I've found a bug in the way the kernel handles the PaX flags when
loading an ELF binary.

-------------------------- kern/exec_elf.c --------------------------
#if defined(PAX_MPROTECT) || defined(PAX_SEGVGUARD) || defined(PAX_ASLR)
	l->l_proc->p_pax = epp->ep_pax_flags;

	if (is_dyn)
		elf_placedynexec(l, epp, eh, ph);

'epp->ep_pax_flags' is set depending on information found in a section
of the binary being loaded. Here, the current proc PaX flag is
overwritten with the new one, and is then used in elf_placedynexec().

The problem here is that this flag is overwritten in the first part of
the loader, and not in the last one. If exec_elf_makecmds() fails, the
kernel returns an error to userland, and the calling process is still
alive. Therefore, it overwrote for free the PaX flag of the current

It means that if the current process is not PaX'ed, and tries to execve
a PaX'ed binary and fails to, it gets tagged as PaX'ed while it is not.

This can lead to several inconsistencies. For example, the mmap syscall
calls pax_aslr(l), which reads the PaX flag on the fly and offsets the

(Continue reading)

Murdak | 16 Feb 05:46 2015

GSOC 2015 [Enhance ptyfs to handle multiple instances]

my name is Pavel and i would like to know what should i do to try to fix
the "Enhance ptyfs to handle multiple instances" problem with you guys
mentoring me in GSOC (Google summer of code). I am a computer
engeneering student and i saw that the problem is at kernel level, so i
am also making the Eudyptula challenge and i think it could help me.
I am waiting for some news.

Best regards,
Pavel Teixeira.

Ignatios Souvatzis | 14 Feb 13:16 2015

vm_map hangs with netbsd-6


I'm experiencing situations, where my Shark, updated to 6.1.5,  can't exec or fork
or otherwise change the mappings of processes anymore. E.g. I start


in a pre-exsiting shell, and the process hangs in vm_map forever. Especially annoying
is that killing other processes hangs, too, so the only fix is to
hardware reset, including full fsck.

Culprit is the kernel; same problem before updating userland!

The machine was rock stable with netbsd-5.1.3

I've heard the suspicion that his is not Shark-specific, but applies to other 
small-vm-space (32bit) architectures, too; I've not seen it elsewhere.


[Actually, I would have rebooted into a -5 but I updated mistakenly userland, too...


Maxime Villard | 13 Feb 19:18 2015

A brelse() in FFS...

this may be a stupid question; in ufs/ffs/ffs_vfsops.c, l.1153:

	if (fs->fs_sbsize < SBLOCKSIZE)
		brelse(bp, BC_INVAL);
		brelse(bp, 0);

However 'fs->fs_sbsize' is *always* smaller than SBLOCKSIZE. So only
the first branch is reached.

I don't understand what the BC_INVAL flag means, and its definition
in sys/buf.h is not very enlightening:

	#define	BC_INVAL	0x00002000	/* Does not contain valid info. */

Which branch do I keep?

Izaak | 8 Feb 11:38 2015

Dealing with debugging macros for printing as part of aprint clean-up


Sorry for my silence on the aprint project. I was busy in the last
while, but I have more time to dedicate to it now.

Anyway, I am currently working on the first task, converting printf to
the appropriate aprint during autoconfiguration. Having read through
many files, I have found that often printf is wrapped in a macro like
'DPRINTF', which is occasionally used both in the driver attachment
function and also elsewhere in the file. I am not sure whether to
replace the 'printf' inside the macro; make a new macro just for
attachment; replace the macro with a direct call to an aprint function.
Also, some macros contain uprintf, ttyprintf or tprintf (e.g.
/sys/dev/acpi/acpi_apm.c) -- Martin told me to leave those intact. I
suppose this question holds also for general macro usage, so what is the
best way to deal with that?

Thank you,



Tom Ivar Helbekkmo | 11 Feb 19:52 2015

Interrupt storm mitigation needed


I'm running NetBSD-current/amd64 on a Dell PowerEdge 2850, and have been
experiencing mysterious hangs.  With help and guidance from Christos
Zoulas, I belive I've gotten to where I now know what's going on.  What
to do about it is a more difficult question, and Christos suggested we
take the issue to tech-kern.

The behaviour is as follows: when the machine is busy with disk and
network I/O, using the integrated Dell PERC (AMI MegaRAID) "amr" RAID
controller and Intel i8254x "wm" network interfaces, there will be
sudden hangs, where it is completely unresponsive, including not
responding to keypresses on the console, or to ICMP echo packets on the
network.  In single CPU mode, these hangs will last for anything from
just noticeable to almost half a minute at the most.  Reducing the
activity on the machine keeps them from occurring; piling it on again
reintroduces them.  In SMP mode, they will typically be much longer -- I
then tend to get only one or two of, say, ten or twenty seconds, and
then what appears to be a permanent one (although it looks as if I've
had hangs, while I've been away from the machine, which have had it
resume operation after about a half hour).

Christos and I went through a long sequence of tests and modifications,
during which I, among other things, modified the amr driver to use
mutexes and condvars instead of splbio()/splx(), and added a couple of
bug fixes gleaned from FreeBSD.  In the end, however, it turned out that
the problem is interrupt storms from the integrated USB controller.

Here are some interrupt mappings (the devices that are actually in use
are amr0, wm0, and uhci2 (the latter running a 1200 bps serial line over
(Continue reading)

Jose Luis Rodriguez Garcia | 10 Feb 01:47 2015

/usr/src/sys/crypto/arc4 isn't used by kernel nad ppp_mppe

arc4 isn' t used in the kernel. I think that it must be deleted the
directory: /usr/src/sys/crypto/arc4
I have searched for arc4_setkey in OpenGrok and I haven't found a
reference about its use.

Doing a grep for arc4_setkey in syssrc, I have found that it is only
used until NetBSD 3. There is
only a reference for this function in   usr/src/sys/net80211/ieee80211_crypto.c

It was changed by other funtions in revision 1.7 :

I was polishing the patch of Aran Clauson in gnats 47618, of the
package mppe-lkm :
mppe encryption for pptp (I know that it is weak cryptography, but
better than clear text). This patch
includes the arc4 functions.

I have seen than GENERIC amd64  version 6.1.5 doesn't include the
arc4_setkey function an friends, but in
version 7 BETA they are included in GENERIC.

The question:

What must be done for NetBSD 7 and current?

1- Remove arc4 functions from kernel and add to the package.

2- Or add ppp_mppe to the kernel and keep arc4 functions. The sources
says that it is dual licensed: a
(Continue reading)

Maxime Villard | 7 Feb 12:19 2015

Removal of compat-FreeBSD

I intend to remove the compat-FreeBSD support from the system.

It has a limited interest since no major proprietary software is developed on
FreeBSD; if one were, it would certainly be available on Linux, and we have full
compatibility support for that.

You will also notice, after reading the code a bit, that our FreeBSD layer is
really poor: many syscalls are missing, the translation is not efficient, and
the layer is only available on i386. Recent FreeBSD-10 binaries often crash.

Recently we found two enormous bugs so obvious and harmful that we should
normally have received a bug report from a user somewhere. We didn't, which
means that in 6 years nobody tested compat-FreeBSD - "nobody" being the
developers and the users.

Clearly, we should not waste time and energy on something that simply does not
work. compat-FreeBSD could give the impression NetBSD has a reliable way to
execute FreeBSD binaries, which is far from being the case.

This is what motivates my proposal.


Martin Husemann | 3 Feb 21:47 2015

Making dhcpcd work on diskless clients

I recently tried to follow up on the "rtsol has been removed" warning
and switch a diskless client (booting via in-kernel dhcp client and NFS
on /) to dhcpcd.

This did not work well: midway through the dhcpcd startup, NFS started
erroring out with EHOSTUNREACH.

After talking to Roy, there is no "good" reason for this, and testing shows
that running dhcpcd later works just fine, without interrupting the / mount.

This led to the following change in /etc/rc.d/dhcpcd:

if ifconfig $( sysctl -n kern.root_device ) 2>/dev/null | fgrep flags= \
                | fgrep -q UP; then
        # a diskless client, try to make sure everything is in core
        echo A diskless client, trying to get dhpcpcd into buffers...
        cat /sbin/dhcpcd > /dev/null

run_rc_command "$1"

and this makes it work.

Can anyone think of a safer way, or some alternative to handle it inside
dhcpcd code?

(Continue reading)