Patrick Welche | 22 May 14:09 2015
Picon
Picon

vnd locking

There are a load of locking PRs involving vnd. I thought I would have a
stab at converting vnd to use condvars and mutexes (mutices?) as a first
step. I cobbled something together which allows me to

  vnconfig vnd0 /tmp/foo.img
  disklabel -r -w vnd0 vndtest
  newfs /dev/vnd0b
  mount /dev/vnd0b /mnt
  cd /mnt
  echo hello > foo
  cat foo
  df -h .
  umount /mnt

with a LOCKDEBUG kernel, so I may have guessed right, but I haven't found
any documentation on The Right Way, so please review carefully, assume
the worst, and tell me how to do it better!

Things to ponder:
- there was some sort of start kernel thread, thread sets variable,
  meanwhile loop waiting for variable to be set. I removed that. On
  the other hand I added a MUSTJOIN for the kernel thread exiting
  side of things.
- given that vnd is a pseudo-device, do I need an extra lock to care
  of device creation/destruction? (What am I protecting against?

Cheers,

Patrick
(Continue reading)

Ryota Ozaki | 22 May 12:27 2015
Picon

Run mcast tests on rump kernel

Hi,

I'm trying to run mcast tests on rump kernel.

The tests have been longly all failed due to that
they run directly on the host and the host's
network configuration doesn't meet the tests.

I think we should run the tests on a rump kernel
and configure its network so as to satisfy
requirements of them.

Here is a patch to do so:
http://www.netbsd.org/~ozaki-r/run-mcast-tests-on-rump.diff

With the patch, # of failures of the tests are down
to two.

Any comments?

  ozaki-r

Ryota Ozaki | 22 May 08:32 2015
Picon

Removing leftover IPX and DECNET stuffs

Hi,

My G/C continues... Next targets are IPX and DECNET.

http://www.netbsd.org/~ozaki-r/remove-ipx.diff
http://www.netbsd.org/~ozaki-r/remove-decnet.diff

Can I commit them?

  ozaki-r

Ryota Ozaki | 20 May 05:01 2015
Picon

Removing use of AF_NS and NS option

Hi,

There remain some stuffs of retired netns in the
source code. This attempt removes references to
AF_NS and NS option (and NETISR_NS definition).

Here is a patch:
http://www.netbsd.org/~ozaki-r/remove-netns.diff

Any objections to remove them?

  ozaki-r

Paul Goyette | 18 May 00:40 2015

Inter-driver #if dependencies

My crusade for modularity has arrived at the pcppi(4) driver, and I've 
discovered that there are a number of places in the code where a #if is 
used to determine whether or not some _other_ driver is available to 
provide certain routines.  For pcppi(4), these dependencies are for the 
attimer(4) and pckbd(4) drivers.  (While I haven't yet gone searching, 
I'd be willing to wager that there are other similar examples in other 
drivers.)

These #if constructs make it very difficult to modularize these drivers.

I'd like to propose the following new kernel mechanism that will allow 
us to remove these #if dependencies.

1. Extend the struct cfattach to have an additional member, and create
    a new CFATTACH_DECL4_NEW macro to initialize it (and updates to the
    existing CFATTACH_* family to default the value to NULL).

 	int	(*ca_callback)(device_t, int, void *);

    (This will require a kernel version bump.)

2. In kern/subr_device.c (or kern/subr_autoconfig) add a new routine
    to call the callback routines for a driver until something handles
    the request.  Note that the caller provides a device_t to identify
    itself to the callback routine.

 	int
 	config_device_callback(device_t caller, const char *name,
 			int cb, void *args)
 	{
(Continue reading)

Martin Husemann | 17 May 17:28 2015
Picon

pthread_getspecific without prior pthread_setspecific

Trying to trace down lots of failures of mips N32 userland running on a N64
kernel, I found that many calls to pthread_getspecific() happen without
any prior pthread_setspecific().

So I added an assertion and found this firing on lots of programs,
two simple examples:

	/usr/tests/libexec/ld.elf_so/h_df_1_noopen2
or
	gdb

This is the patch I used:

Index: pthread_specific.c
===================================================================
RCS file: /cvsroot/src/lib/libpthread/pthread_specific.c,v
retrieving revision 1.26
diff -u -r1.26 pthread_specific.c
--- pthread_specific.c	21 Mar 2013 16:49:12 -0000	1.26
+++ pthread_specific.c	17 May 2015 15:13:30 -0000
 <at>  <at>  -75,6 +75,8  <at>  <at> 
 	if (__predict_false(__uselibcstub))
 		return __libc_thr_getspecific_stub(key);

+	pthread__assert(pthread__self()->pt_havespecific);
+
 	return pthread__self()->pt_specific[key].pts_value;
 }

Now a simple fix is below, but I am not sure it is not just papering
(Continue reading)

Kengo NAKAHARA | 13 May 12:38 2015
Picon

Re: change MSI/MSI-X APIs

Hi,

On 2015/05/12 23:37, Christos Zoulas wrote:
> In article <55516416.3050901 <at> iij.ad.jp> you write:
>> Because some device drivers must select INTx, MSI, or MSI-X depending
>> on using devices; e.g. some devices have errata about MSI-X,
>> so the device driver cannot use MSI-X even if the devices have
>> MSI-X capability. In addition, some other the device drivers should
>> use MSI-X and INTx only since some devices have errata about MSI.
>> In a similar way, other device drivers should use MSI-X and MSI only.
>>
>> These selection logic codes can be done only in the device drivers
>> codes, therefore it is required for the device drivers to be able to
>> select interrupt types by allocation APIs.
>>
>>> Also can we add the disestablish/free code in the driver? What are the
>>> steps to undo the interrupt allocation/establishment?
>>
>> Here is the example code of if_wm:
>>    http://www.netbsd.org/~knakahara/unify-msi-apis/if_wm-example.diff
>>
>> This diff includes pci_intr_disestablish()/pci_intr_release() and
>> pci_{intx,msi,msix}_alloc()/pci_intr_establish().
>> How about this sample code?
> 
> I don't see where it free's the sc_intrs[] it allocated in the msi* alloc
> functions. I think that a lot of the code could be merged as follows:
> 
> 	http://www.netbsd.org/~christos/if_wm-example.diff
> 	[I have not even tried to compile this, just some thoughts]
(Continue reading)

Edgar Fuß | 13 May 10:11 2015
Picon

6.1 panic in mutex_vector_enter() called from genfs_do_putpages()

I had a panic on a 6.1/amd64 system during the release of a number of fss(4) 
snapshots. Of course I cannot tell for sure the panic  was caused by 
fssconfig -u, only it happened at that time:

uvm_fault(0xffffffff80724860, 0x0, 1) -> e
fatal page fault in supervisor mode
trap type 6 code 0 rip ffffffff8025cfbf cs 8 rflags 10283 cr2  8 cpl 0 rsp fffffe811d8be800
kernel: page fault trap, code=0
Stopped in pid 0,80 (system) at netbsd:mutex_vevtor_enter+0x80: movq	18(%r15),%rax

show registers reveals r15 contains fffffffffffffff0.

bt gives:
mutex_vector_enter() at netbsd:mutex_vector_enter+0x80
genfs_do_putpages() at netbsd:genfs_do_putpages+0xb19
VOP_PUTPAGES at netbsd:VOP_PUTPAGES+0x3a
uvm_pageout() at netbsd:uvm_pageout+0x20a

(thats all manual OCR, of course.)

I'm creating and destroying these snapshots daily (I hold them during backup), 
so it can't be a general problem related to snapshotting these file systems.

Any clues?

Kengo NAKAHARA | 13 May 02:03 2015
Picon

Re: change MSI/MSI-X APIs

Hi,

On 2015/05/12 23:37, Christos Zoulas wrote:
> In article <55516416.3050901 <at> iij.ad.jp> you write:
>> Here is the example code of if_wm:
>>    http://www.netbsd.org/~knakahara/unify-msi-apis/if_wm-example.diff
>>
>> This diff includes pci_intr_disestablish()/pci_intr_release() and
>> pci_{intx,msi,msix}_alloc()/pci_intr_establish().
>> How about this sample code?
> 
> I don't see where it free's the sc_intrs[] it allocated in the msi* alloc
> functions. I think that a lot of the code could be merged as follows:
> 
> 	http://www.netbsd.org/~christos/if_wm-example.diff
> 	[I have not even tried to compile this, just some thoughts]

That URL is not available. Is the same name file directly under your
home directory right?

Thanks,

--

-- 
//////////////////////////////////////////////////////////////////////
Internet Initiative Japan Inc.

Device Engineering Section,
Core Product Development Department,
Product Division,
Technology Unit
(Continue reading)

Kengo NAKAHARA | 11 May 08:15 2015
Picon

change MSI/MSI-X APIs

Hi,

I received feedback from some device driver authors. They point out
establish, disestablish and release APIs should be unified for INTx,
MSI and MSI-X. So, I would change the APIs as below:

 before                  | after (unify to)
-------------------------+-------------------------
 pci_intr_establish()    | 
 pci_msi_establish()     | pci_intr_establish()
 pci_msix_establish()    |
-------------------------+-------------------------
 pci_intr_disestablish() | 
 pci_msi_disestablish()  | pci_intr_disestablish()
 pci_msix_disestablish() |
-------------------------+-------------------------
 pci_intx_release()      | 
 pci_msi_release()       | pci_intr_release()
 pci_msix_release()      |
# In contrast, alloc APIs are not changed.

Here is the above modification diff.
    http://www.netbsd.org/~knakahara/unify-msi-apis/unify-msi-apis.diff

If there is no objection, I commit it in a few days.

Could you comment this modification?

Thanks,

(Continue reading)

Staffan Thomén | 8 May 20:03 2015
Picon

Atheros 802.11n cards


Hi, I've recently installed a pair of 802.11n cards in my soekris net6501 and
alix in the hope that they'd some day be able to be used in hostap mode on
netbsd (no need for n, g would be quite sufficient) but alas that day seems not
to be quite here yet.

The cards are the mini-PCIe and mini-PCI versions of the Merlin (according the
athn man page) the former is an AR9280 and the latter latter an AR9220 (I
think, it's detected as an AR9280 by the athn driver, pcidevs doesn't seem to
know about the 9220)

The AR9280 works well in client mode, but I get huge packet loss when I try
to run it in hostap mode. My sporadic research seems to suggest that this is
due to missing support for powersaving in connected clients.

The AR9220 is not doing quite as well, it's detected, but the athn driver thinks
it's an AR9280 and also thinks it's only capable of 802.11a.
'ifconfig athn0 list scan' yields no results, but then there are no 802.11a
access points transmitting near that machine anyway so no wonder.

Now I have a couple of questions, is anyone working on the powersaving issue?
Is there much work involved? Is there something I can do?

/Staffan

--

-- 
Staffan Thomén - ADB3 455F 10D5 86D1 78D6  048D 11BB D66E 7C7E 2EF8

Gmane