Re: Lockless IP input queue, the pktqueue interface

2014-06-09 Thread Mindaugas Rasiukevicius 
Ryota Ozaki  wrote:
> Hi rmind,
> 
> maxlen of ip{,6}_pktq cannot be updated via sysctl.
> It seems that we need to do it in sysctl_pktq_count
> somehow.

Now it can:

http://mail-index.netbsd.org/source-changes/2014/06/09/msg055432.html

-- 
Mindaugas

Cleanup of cd9660 node initialization

2014-06-09 Thread J. Hannken-Illjes 
While starting to convert cd9660 to vcache the following problems and
bugs came up:

- cd9660_vget_internal() has two hint arguments "isodir" and "relocated"
  that have values when called from cd9660_lookup() and are NULL when
  called from cd9660_fhtovp().

- cd9660_lookup() passes data from a released buffer as "isodir".

- directory data is sometimes read via the directory vnode and
  sometimes via the device vnode leading to an inconsistent buffer
  cache that will just not explode as the filesystem is read-only.

- directory entries are sometimes taken from the parent and somtimes
  from the "."-entry of the directory.

The attached diff will:

  Remove the hints "isodir" and "relocated" from cd9660_vget_internal()
  and always reread the directory entry by inumber.  For directories
  the directory entry is always its "." entry.

  Always read directories via the device vnode to prevent buffer cache
  inconsistency.  Keep i_devvp as a hint for fstat(1) and friends and
  always use im_devvp for reads.  No need to vref()/vrele() i_devvp.

  The additional bread is either cached because cd9660_lookup() just
  released the buffer or will be used in the near future when the
  directory gets traversed during lookup.

Comments or objections anyone?

--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)



cd9660.diff
Description: Binary data

Re: Big test regression in -current

2014-06-09 Thread Martin Husemann 
On Sun, Jun 08, 2014 at 04:24:55PM +0100, Mindaugas Rasiukevicius wrote:
> That is RUMP-specific.  Fixed now.

Still not much better for me:

Summary for 587 test programs:
3723 passed test cases.
81 failed test cases.
32 expected failed test cases.
73 skipped test cases.

Any special cleaning needed for an update build?

Martin

Re: Big test regression in -current

2014-06-09 Thread Martin Husemann 
On Mon, Jun 09, 2014 at 06:37:11PM +0200, Martin Husemann wrote:
> On Sun, Jun 08, 2014 at 04:24:55PM +0100, Mindaugas Rasiukevicius wrote:
> > That is RUMP-specific.  Fixed now.
> 
> Still not much better for me:

Ooops, something went wrong with my cvs update - will retry.

Martin

Re: Big test regression in -current

2014-06-09 Thread Martin Husemann 
And after updating again we are down to a handfull of unusual failures:

Summary for 587 test programs:
3781 passed test cases.
21 failed test cases.
32 expected failed test cases.
75 skipped test cases.

Martin

Re: Big test regression in -current

2014-06-09 Thread Justin Cormack 
On Mon, Jun 9, 2014 at 8:30 PM, Martin Husemann  wrote:
> And after updating again we are down to a handfull of unusual failures:
>
> Summary for 587 test programs:
> 3781 passed test cases.
> 21 failed test cases.
> 32 expected failed test cases.
> 75 skipped test cases.

I am looking into one remaining issue, the rest of the failures I saw
were fixed today.

Justin

Re: Big test regression in -current

2014-06-09 Thread Paul Goyette 

And after updating again we are down to a handfull of unusual failures:

Summary for 587 test programs:
3781 passed test cases.
21 failed test cases.
32 expected failed test cases.
75 skipped test cases.



My amd64 test-bed is also back to a more normal failure count:


Source Check-Out TimePassFail   XFailSkip
 2014-06-06 01:50:16 3781 124  54  80
 2014-06-05 18:50:16 3867  33  56  83


   2014-06-09 13:50:18 3870  31  56  82

Thanks for the quick resolution.

-
| Paul Goyette | PGP Key fingerprint: | E-mail addresses:   |
| Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com|
| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net |
| Kernel Developer |  | pgoyette at netbsd.org  |
-

Re: Lockless IP input queue, the pktqueue interface

2014-06-09 Thread Ryota Ozaki 
On Mon, Jun 9, 2014 at 10:07 PM, Mindaugas Rasiukevicius
 wrote:
> Ryota Ozaki  wrote:
>> Hi rmind,
>>
>> maxlen of ip{,6}_pktq cannot be updated via sysctl.
>> It seems that we need to do it in sysctl_pktq_count
>> somehow.
>
> Now it can:
>
> http://mail-index.netbsd.org/source-changes/2014/06/09/msg055432.html

Works fine. Thanks!

  ozaki-r

>
> --
> Mindaugas