Takahiro HAYASHI | 19 Sep 13:06 2014

patch: verbose debug code for xhci


This patch does NOT improve xhci.c at all but may (or not) help
people who try to read debugging hexdump even though they are not
familiar with it.
This patch is imcomplete, buggy, and does not support all requests.

For example, you can read TRB values in human-readable form like this:

xhci0: xhci_do_command: input: 0x000000000355e000 0x00000000 0x01002c00
xhci0: xhci_do_command: output: 0x00000000033aa010 0x01000000 0x01008401

xhci0: xhci_do_command: input: 0x000000000355e000 0x00000000 0x01002c00
TYPE_ADDRESS_DEVICE(11) slot 1 bsr 0 ictx 000000000355e000 c 0
xhci0: xhci_do_command: output: 0x00000000033aa010 0x01000000 0x01008401
EVENT_CMD_COMPLETE(33) SUCCESS(1) slot 1 vf 0 c 1 param 0 cmd 00000000033aa010

by inserting xhci_dump_trb() to appropriate positions.

--- xhci.c.orig	2014-08-12 23:29:37.000000000 +0900
+++ xhci.c	2014-09-19 08:04:11.000000000 +0900
 <at>  <at>  -1734,6 +2451,7  <at>  <at>  xhci_do_command(struct xhci_softc * cons
  	device_printf(sc->sc_dev, "%s input: "
  	    "0x%016"PRIx64" 0x%08"PRIx32" 0x%08"PRIx32"\n", __func__,
  	    trb->trb_0, trb->trb_2, trb->trb_3);
+	xhci_dump_trb(-1, trb);

(Continue reading)

Mark Davies | 19 Sep 06:29 2014

problems when multiple mfi cards in system?

I have a Dell PERC H810 pcie card and an external disk array attached 
to it.  If I put this into a desktop 6.1_STABLE/amd64 system I can 
happily read and write terabytes from the external array.  However if 
I move the card to a Dell poweredge r610 (which also has an internal 
PERC 6/i) and try reading from the external array, after a few minutes 
the entire machine just freezes solid.  There doesn't seem to be any 
problem reading from the internal disks.

Any ideas how to identify whats failing here and how to fix it?

dmesg for the r610 is below.


Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 
    2006, 2007, 2008, 2009, 2010, 2011, 2012
    The NetBSD Foundation, Inc.  All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
    The Regents of the University of California.  All rights reserved.

NetBSD 6.1_STABLE (GENERIC) #25: Mon Jun  9 12:44:09 NZST 2014
mark <at> turakirae.ecs.vuw.ac.nz:/local/SAVE/6_64.obj/src/work/6/src/sys/arch/amd64/compile/GENERIC
total memory = 8182 MB
avail memory = 7929 MB
timecounter: Timecounters tick every 10.000 msec
timecounter: Timecounter "i8254" frequency 1193182 Hz quality 100
Dell Inc. PowerEdge R610
(Continue reading)

Kamil Rytarowski | 17 Sep 11:25 2014

Tru64 AdvFS porting to NetBSD - 1. status 2014-09-17


This is the first status of significant efforts of porting AdvFS [1] [2] to NetBSD.

Long term primary goals:
- complete port of AdvFS to NetBSD,
- relicense the original work with for BSD-friendly license.

1. What is done
- Put all sbin, usr.sbin and lib files into the NetBSD tree
- Add AdvFS user-space parts to initial Makefiles of build.sh
- Add initial variable MKADVFS to stop or start building user-land pieces
- Put kernel-space code into the tree (sys/fs/msfs/)
- Add msfs (aka AdvFS) to the kernel build-machinery and include it for amd64 kernel "ALL"
- Adapted for NetBSD or nuked missing #includes of files from sys/fs/msfs
2. What is in progress
- Party adapted locking dialect (mutex, krwmutex, condvar) for NetBSD (*)
- List of compatibility patches adapting for modern GCC and NetBSD (*)
- Researched and touched compatibility of catgen from NetBSD and Tru64
3. Issues
- Missing subsystems from Tru64: evm.h, devio, overlap.h (added an empty stub), disklabel details (*)
4. Next steps
- Tru64 Mach VM dialect porting to NetBSD UVM (*)
5. Pushed to NetBSD
- Proposed <sys/clock.h> patch [3]

(*) Considered significant effort and/or difficult.

Help and motivation support is appreciated.

(Continue reading)

Manuel Bouyer | 16 Sep 12:46 2014

HDMI transmitter attachement

I'm looking for advice about the design for a new driver.

the AM335x arm SoC includes a framebuffer, which outputs a parallel digital
video signal. A HDMI transmitter which will serialize this video signal
can be connected to the SoC, which then allows to connect external monitors.
The beaglebone black includes a TDA19988 HDMI transmitter.

A driver is needed for the TDA19988, to get the EDID from the monitor, and
also configure the transmitter appropriately. So, in addition to the
video output lines, the TDA19988 is connected to one of the I2C controller
of the AM335x (one the beaglebone black it's the I2C0 controller, but
other boards could use any of the AM335x's I2C controllers).
In addition, the TDA19988 can transmit a digital audio signal, which it
gets from the SoC's "multichannel audio serial port".

Now my question is how should the TDA19988 appears in the device tree ?
I could make it a child of the I2C controller, with the framebuffer and
audio drivers using ad-hoc callbacks to the TDA19988 driver.
Or I could make it a child of the framebuffer, the framebuffer driver
redirecting I2C requests to the I2C controller driver.

I think the second solution is less hackish and more flexible;
but I'd like to hear from people more familiar than I am with
video hardware and drivers.


Manuel Bouyer <bouyer <at> antioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la difference
(Continue reading)

Martin Husemann | 16 Sep 09:07 2014

Making cpufreq(9) per cpu

There was a recent discussion on port-sparc64 about the cpufreq(9) interface,
and I noticed it basically is a single, global interface, which stores
a single cookie.

This sounds a bit restrictive; for one it assumes identical cpus and available
frequencies for all cpus (ok, that is not a very far stretch, but we do
have working SMP setups where it would fail - if the affected CPUs would
provide any clock changing features at all).

So wouldn't it be better to add a cpuinfo* to cpufreq_register() and
friends (some already have it), and store the struct cpufreq (not the
pointer to it!) in the MI part of cpuinfo?

Then maybe add the notion of "I am a secondary core and will always have same
frequncy as cpuinfo* other". And of course some way to mark the cpufreq
data as not initialized (that could be just NULL pointers for

That way ACPI could still do its global thing bound to cpu0 and all others
as "slaves", while on sparc64 we could store the per cpu pci root bridge
softc pointer in the cf_cookie pointer in struct cpufreq.

What do you think?


Patrick Welche | 16 Sep 01:20 2014

detect valid fd

Given a filedescriptor, how can you tell that it is valid and has been

In the attached simple program, a file and a directory are opened
(with CLOEXEC set). I then call fcntl(fd, F_GETFD) on the range
fd = [3..15].  fd = {3,4} correspond to the open file and directory.
Why don't I get fcntl(4):

     [EBADF]            fildes is not a valid open file descriptor.

for fd = [5..15], but only for some of them?

$ ./cloexec
fd  3 testfile.txt flags = 0x1 (0x1)
fd  4 testdir flags = 0x1 (0x1)
fd  3's flags = 0x1 (0x1)
fd  4's flags = 0x1 (0x1)
fd  5's flags = 0x0 (0x0)
fd  6's flags = 0x0 (0x0)
fd  7's flags = 0x0 (0x0)
fd  8's flags = 0x0 (0x0)
fd  9's flags = 0x0 (0x0)
fd 10's flags = 0x0 (0x0)
cloexec: fcntl 11: Bad file descriptor
cloexec: fcntl 12: Bad file descriptor
fd 13's flags = 0x0 (0x0)
fd 14's flags = 0x0 (0x0)
cloexec: fcntl 15: Bad file descriptor

The motivation for the question is
(Continue reading)

Ryo ONODERA | 15 Sep 16:46 2014

Help: USB 3.0 xHCI driver does not support non-root hub


Our xHCI USB 3.0 driver with Intel Lynx Point/Lynx Point-LP, Renesas uPD70202
and Fresco Logic 0x1b73/0x1100 xHCI chips does not support non-root hub
as following.
I believe our xHCI driver have no non-root hub support.

I have tested some USB 1.1/2.0/3.0 hubs, and gotten same results.
Address Device Command TRB execution just after Enable Slot Command TRB
execution fails with USB Transaction Error.

I have spent some weeks, but I cannot find why Address Device Command fails.
(If your want to use Intel Lynx Point/Lynx Point-LP xHC, please
apply a patch in http://gnats.netbsd.org/49076.)

Anyone have a clue for xHCI's non-root hub support?
I really need any clue for non-root hub support.

Thank you.

I know our xHCI driver have other problems (some USB Ethernet adapter and
USB-Serial converter does not detected properly),
but non-root hub support is essential for me now.

With the hub that is advertised as USB 3.0 hub.
uhub3 at uhub0 port 8: VIA Labs, Inc. USB2.0 Hub, class 9/0, rev 2.00/90.30, addr 4
uhub3: single transaction translator
uhub3: 4 ports with 4 removable, self powered
xhci0: xhci_open addr 4 depth 1 port 8 speed 3
(Continue reading)

Kamil Rytarowski | 15 Sep 02:53 2014

Unification of common date/time macros

I need to use common macros (defines) for a year of Epoch (1970), seconds per day, seconds per year etc.

For user-space there is already /usr/include/tzfile.h, that contains i.a.:
#define SECSPERMIN 60
#define MINSPERHOUR 60
#define HOURSPERDAY 24
#define DAYSPERNYEAR 365
#define DAYSPERLYEAR 366
#define MONSPERYEAR 12
#define TM_YEAR_BASE 1900

#define EPOCH_YEAR 1970
#define isleap(y) ((((y) % 4) == 0 && ((y) % 100) != 0) || ((y) % 400) == 0)

For kernel-space these defines are spread across different files, drivers, architectures.
- arch/hp300/stand/common/clock.c:
#define FEBRUARY 2
#define STARTOFTIME 1970
#define SECDAY (60L * 60L * 24L)
#define SECYR (SECDAY * 365)
(Continue reading)

Emmanuel Dreyfus | 14 Sep 03:41 2014

How NFS keeps state for getdents()?


Retreiving a directory content through getdents() can split in multiple
calls. State is kept using the offset argument which tells where in the
directory listing buffer we want to start reading, and it is allowed to
use lseek() to move inside the directory listing buffer.

How does this handle the case when a directory entry is added or removed
between two getdents() calls? Is a directory listing cached and attached
to the file descriptor?

And how does this works in the NFS case? We do not even have file
descriptor here, just a file handle which let us retreive the vnode. 


Emmanuel Dreyfus
manu <at> netbsd.org

vbhat | 12 Sep 04:17 2014

Compressed Cache for NetBSD


I am a Masters student at Carnegie Mellon University specializing in
Systems (with special emphasis on Operating Systems and Storage Systems).
I have taken a class called Operating Systems Practicum
(https://www.cs.cmu.edu/~412/syllabus.html). The main objective of the
course is to add a feature to any Open Source systems-y product
(preferably an operating systems).

I was browsing through NetBSD project wiki and came across this really
interesting project of Compressed Cache
(http://wiki.netbsd.org/projects/project/compressed-cache/). I would
really appreciate if I could get some insights on this project status. I
will mostly be working alone on this project and the timeframe I have is
around 2 months.

I did some basic reading and have figured out that one approach to
implement this is to have a block device backed by kernel reserved memory.
This block device can used as a staging area for the compressed pages. The
interface can itself be provided through a VFS read/write semantics.

I would really appreciate if I could get any pointers and help on this
project. Eagerly awaiting a response.

Thanks and Regards,

Nick | 9 Sep 07:44 2014

tmpfs projects


I am new to NetBSD and would like to see if there is any chance that I could find something related to file system to work on (I am working on networking/platform SW full-time)

Are these two projects already complete or been taken care of by people? Those look like a good entry point to the file system: