Re: Memory Leak
Brian Feldman [EMAIL PROTECTED] writes: URL:http://green.homeunix.org/~green/boehm-gc.diffs have you sent this to the port maintainer (nobutaka@)? DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
5.2.1 + snort, dropping packets
hackers, I am running snort on 5.2.1-RELEASE, and I am getting high dropped packets rate. traffic is quiet, about 1kpps, the box runs on xeon processor, intel gigabit NICs (em driver), system load is low: CPU states: 1.9% user, 5.1% nice, 1.6% system, 4.7% interrupt, 86.8% idle Mem: 121M Active, 97M Inact, 75M Wired, 736K Cache, 60M Buf, 201M Free Swap: 512M Total, 512M Free I have tried: o both SMP and UP kernels o both SCHED_ULE and SCHED_4BSD options o libpcap libs versions 0.7 and 0.8.3 o 5.2.1-RELEASE and -current kernels o DEVICE_POLLING option o sysctl debug.bpf_bufsize set to maximum of 524288 and still having dropped packets. I am having a much lower spec box, running obsd 3.2, same snort configuration, capturing the same traffic. obsd shows constant 0 dropped packets. How would I fix that problem? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Third RFC on on pkg-data ideas for ports
[this is BCC'ed to -hackers and -arch just so everyone has a chance to see it, but I expect the bulk of the discussion should take place on the freebsd-ports mailing list] Well, Darren and I have done more work on my pkg-data ideas, but we're also getting closer to the time where Darren will be busy with his own full-time job, at which point the progress on this will be much slower. So, I'd like to show some of what we've been working on, make a third proposal, and see if this one is interesting enough for us to pursue. If not, then I'll probably just update my web pages with my thoughts so far, and then put this whole idea on a back-burner. [and if you thought progress was slow before, imagine how slow it will be when moved to a back-burner!] In the last go-round, someone pointed out that it could be helpful just to have a better idea of what the ports-collection really *is*. So we took some time to write a script which goes through a ports collection and gathers some statistics what files exist (on a per-port basis), and how much room they take up. I'll post some results of that script as a follow-up to this message. (that reply will only go to freebsd-ports...). So, hopefully that information will be of some interest even if we never do anything with the pkg-data ideas. Someone else (whose name I also forget) said something which focused my attention a bit more on patch-files per se, and how they really aren't the same as the other files I'm trying to collapse into pkg-data. Also, I haven't gotten quite as far along with figuring out what to do with pkg-descr files, so (in the interests of time), I think I'll leave those alone for this proposal. We've worked on some other ideas too, but those aren't far enough along yet. So I'll just write them up as future work (when I update the web pages...). The third proposal is basically: a) move most standard files into a new pkg-data file, as described in previous proposals, except for pkg-descr and patch files. b) create a new directory at the root directory of the ports collection. That directory would be called Patches, and inside would be a directory for each category. Inside each Patches/category directory would be a single-file for each port in that category, where that single-file would have all the ports-collection patches for the matching port. c) [minor] in the pkg-data section for distinfo, I'd like to change the format for each file from, eg: MD5 (bash-2.05b.tar.gz) = 5238251b4926d778dfe162f6ce729733 SIZE (bash-2.05b.tar.gz) = 1956216 to 5238251b4926d778dfe162f6ce729733 1956216 bash-2.05b.tar.gz So it collapses most standard files into the pkg-data file, and collapses the patch-related files for a given port into files such as: ports/Patches/shells/patches-bash2. This will not result in as dramatic a drop in inodes, but it has the nice side-effect that Patches are separated from all the other files. Thus, end-users could 'cvsup refuse' the patches for categories that they do not care about, and it would not break operations which work on the entire ports collection (such as `make index'). Our current transform script doesn't do part 'c' yet, but I thought it would be interesting to note the result of 'b': (63) du -sk pd-new/ports pd-new/ports/Patches 190944 pd-new/ports 28414 pd-new/ports/Patches 162530 == ports without the Patches And to compare the present ports collection to a transformed ports collection, the result would look like: 1K-blocks Inodes Used Used 23874279154pd-orig/ports 19094449321pd-new/ports 20% 37% = reduction So, should we pursue any of this? -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Animate the splash at boot
I have wanted to animate the splash , for example let the daemon dance in joy when booting the box. I first let the soft clock interrupt handler function to be triggered when the variable cold is still 1 at early boot time ; and then load some different bmp files using loader ; now I can show moving pictures at boot time at a certain interval without any twinkle and stop them using some sysctl after booted. I am sure this could be accomplished , I wander whether there are any people having the same idea as mine , or if this is already on its way ? - Do You Yahoo!? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB ethernet CDC driver
After having a bit more of a look through the archives and more searching it's apparent this driver has been written a number of times over independently by different people (and for different reasons). I will try to make a bit of a collation effort and sort out the good bits. Sam On Mon, 2004-05-24 at 11:14, Craig Boston wrote: On Sunday 23 May 2004 7:25 pm, Sam Lawrance wrote: That would be great, I would love to take a look at it. I'll go ahead and copy the list in case anybody else is interested... You can grab the source at http://www.gank.org/freebsd/cdce.tar.gz I'm planning to eventually make a FreeBSD projects page -- I have a few local patches and such I'd like to share. If and when I ever get time to do that, I'll move this in with it, but the above link should work until then. The list archives will have to suffice as documentation until then, here's a few random comments about it: * It's set up as a standalone kernel module. If you have the kernel source on your system it should be as simple as cd cdce; make all make install. That will dump it in /boot/kernel/if_cdce.ko, which can be loaded by any of the normal means. * When you plug in the device, if all goes well, you should end up with a cdce0 network device. Just ifconfig it and go. * It registers itself as the handler for the CDC Ethernet class. If your device doesn't report itself as that, you may have to add a specific device ID for it in the cdce_devs[] structure (get the values from usbdevs -v). If it complains about not being able to find endpoints, try adding it in there with the CDCE_NO_UNION flag. Linux on the Zaurus seems to be slightly non-conformant to the spec, so it may be similar on the iPaq. * The driver generates a random MAC address for the local end rather than trying to read it from the device. While incorrect for real Ethernet adapters, it seems to be fine (and may even be necessary) for these kinds of point-to-point connections. * There is special handling for the Zaurus's nonstandard frame format, but it should be off by default for other devices. This hasn't been tested yet, though :) * The driver is targeted at -CURRENT. It was originally developed against 5.2-RELEASE sources and should still compile fine on those systems. It would probably require some work to back-port to stable though. * Not entirely sure what to do about the copyright message -- I borrowed heavily from the if_axe and if_aue drivers... * BSD license, so feel free to do whatever with it :) * Also applies is my standard disclaimer: It works fine on my system, but may cause your toaster to explode. I used to sometimes get panics on detach, but I think the problem is fixed now. Haven't had one in quite a while, even if I unplug it while transferring something. Good luck! Craig ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Jails: An rc.d script
At 2004-05-23T01:04:51Z, William M. Grim [EMAIL PROTECTED] writes: I've written an rc.d script that can start/stop/restart jails, if they follow a certain pattern of setup. I'm strongly considering the placement of this in ports or base (ports seems most appropriate). Have you looked at the sysutils/jailadmin port? You can figure a set of named jails, and start/stop them individually or as a group. It includes an rc.d script as well. -- Kirk Strauser 94 outdated ports on the box, 94 outdated ports. Portupgrade one, an hour 'til done, 82 outdated ports on the box. pgpC7DRXobGsk.pgp Description: PGP signature
