OpenBSD Journal

New snapshots need testing

Contributed by jcs on from the but-you-always-test-new-snapshots-right? dept.

theo asks for testing of new snapshots:

"A number of snapshots are out there. Please try them, because they contain a monster diff from canacar. This diff affects every network driver. If you can, please try at least the kernel to make sure your network devices still work. In a few days this diff will be commited."

get new snapshots from your local ftp mirror.

(Comments are closed)

Comments

  1. By Yusuf Goolamabbas (61.10.7.223) on

    What does the "monster diff" do wrt network drivers ? Enable device polling ?

    Comments

    1. By henning (199.185.136.137) henning@openbsd on

      change in bpf behaviour; allows bpf filters to stop packets from going further up to the stack. canacar & me came up with this when discussing a certain dhcpd behaviour and canacar wrote this during the hackathon.

    2. By henning (199.185.136.137) henning@openbsd on

      change in bpf behaviour; allows bpf filters to stop packets from going further up to the stack. canacar & me came up with this when discussing a certain dhcpd behaviour and canacar wrote this during the hackathon.

      Comments

      1. By solarce (24.220.134.135) solarce@fallingsnow.net on solarce.org

        w00t for double posts! :D

  2. By gwyllion (193.190.253.43) on

    tdeval@ also wants people to test his diff which makes malloc uses mmap instead of brk/sbrk. Please read Help me clean the OS with mmap-malloc ! if you want to help.

    Comments
    1. Comments

      1. By Brad (216.138.200.42) brad at comstyle dot com on

        the gre diff was commited a number of days ago.

      2. By Philipp (80.185.105.220) pb@ on

        i "revoked" the upl(4) one. it's wrong. "do not even try" :-)

    2. Comments

      1. By Brad (216.138.200.42) brad at comstyle dot com on

        the poolpage diff was commited over 3 weeks ago.

      2. By anonymous coward (212.185.103.56) on

        I'd rather like to see a patch for filesystem snapshots, and I'm not alone with that. Yes I know, shut up and hack, yadda yadda, and tedu@ says it's not stable yet even in FreeBSD... but HEY!

        Comments

        1. By Brad (216.138.200.42) brad at comstyle dot com on

          This is already in the works.

          Comments

          1. By Philipp (80.185.108.160) pb@ on

            u-test-it ;-)))

  3. By Anonymous Coward (66.108.252.16) on

    so far, all my archs and interfaces have been working well since the said snapshot. the question i have is to what extent does the dev team want of success reports? full dmesg's? or snips? or other? don't want to burden the developers with useless info.

    Comments

    1. By djm@ (61.95.66.134) on

      If in doubt, send a dmesg to tech@ - better too much info than too little.

      Comments

      1. By gk (217.211.57.138) on

        I thought that sending to dmesg to dmesg@ would do the thing. What is that address for anyway, if not for dmesgs? :-) Matching compile time and GENERIC against incoming dmesg-reports should do the trick, no?

Latest Articles

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]