Re: request for the inclusion of the pcap-filter manpage
Lawrence Teo wrote: On Mon, Mar 05, 2012 at 12:43:07AM +0100, Ingo Schwarze wrote: http://www.manpagez.com/man/7/pcap-filter/ http://www.tcpdump.org/release/libpcap-1.2.1.tar.gz Please consider adding it to the distribution. From cursory inspection, it looks like OpenBSD is using a fork of libpcap 0.4 or 0.5, selectively including later tcpdump.org additions, but not tracking upstream development closely, so including parts of the libpcap 1.2.1 manual would seem wrong. Yes, the last selective sync was with libpcap 0.9.4 in 2006. On a related note, I sent a diff to tech@ back in November 2011 that imports a number of core functions from libpcap 1.2.0 to libpcap in base. It makes it easier to port programs that need the newer libpcap (like Snort 2.9.x) to OpenBSD. The diff could use some testing if anyone's interested. :) http://marc.info/?l=openbsd-techm=132029368027597w=2 My remark was based on a late night thinko. Indeed libpcap included with openbsd is rather old. This patch seems to be the proper answer. # Han
Re: enable/fix vt switching on sandybridge machines
On Sun, Mar 04, 2012 at 10:21:55PM +0100, Mark Kettenis wrote: Date: Sun, 4 Mar 2012 12:27:56 -0800 From: Mike Larkin mlar...@azathoth.net Cc: joshua stein j...@openbsd.org, tech@openbsd.org Reply-To: mlar...@azathoth.net List-Owner: mailto:owner-t...@openbsd.org X-Loop: tech@openbsd.org Sender: owner-t...@openbsd.org X-XS4ALL-DNSBL-Checked: mxdrop214.xs4all.nl checked 192.43.244.163 against DNS blacklists X-CNFS-Analysis: v=2.0 cv=e8exv9V/ c=1 sm=0 a=A3duGc4wJ8K8BtNzzvyz4A==:17 a=wom5GMh1gUkA:10 a=JV4z2ink_MgA:10 a=NDt0MqMu1W8A:10 a=WLtJ5LygAb0A:10 a=wPDyFdB5xvgA:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=rTCu5ZAxDHZ_rHRvVYYA:9 a=CjuIK1q_8ugA:10 a=A3duGc4wJ8K8BtNzzvyz4A==:117 X-Virus-Scanned: by XS4ALL Virus Scanner X-XS4ALL-Spam-Score: 0.0 () none X-XS4ALL-Spam: NO Envelope-To: mark.kette...@xs4all.nl On Sat, Mar 03, 2012 at 09:43:39PM +0100, Matthieu Herrb wrote: On Sat, Mar 03, 2012 at 12:50:32PM -0600, joshua stein wrote: And it only works if you don't suspend the machine. After a suspend/resume cycle, X still comes back, but text mode VTs stay black again. does the console resume properly even when you boot up and don't start x? it doesn't on my laptop, so this may be an acpi-related problem. No, even in text mode only the console doesn't come back from suspend. So yes it's an acpi issue. -- Matthieu Herrb This really has nothing to do with ACPI. It could be due to missing a repost in resume, but ACPI is really not involved in that part of the sequence. There is a block of code in sys/dev/pci/vga_pci.c that can be used to try one of two different resume video repost techniques. Did you try putting your card's ID in there and see what happens? (For both types of repost?) I'm pretty sure I tried both methods when I was hackig on the initial sandybridge support. They didn't help. We need to restore the graphics state ourselves in the kernel driver. I did as well. I'm also sure I tried to mess with the int10 hack and had no luck (because I didn't also have the restore code). (In short, I concur). -0- -- Absentee, n.: A person with an income who has had the forethought to remove himself from the sphere of exaction. -- Ambrose Bierce, The Devil's Dictionary
limiting the RAM used by OpenBSD
Hi, Is there a simple way to limit the amount of RAM used by OpenBSD? Can it be done from the User Kernel Config prompt or in some other way? I have a little Perl script that is able to hang OpenBSD running inside a virtual machine with little memory and lots of swap and now, I want to see if I can reproduce it on real hardware.
Re: limiting the RAM used by OpenBSD
On Mon, Mar 05, 2012 at 06:05:43PM +0100, Salvador Fandino wrote: Hi, Is there a simple way to limit the amount of RAM used by OpenBSD? Can it be done from the User Kernel Config prompt or in some other way? I have a little Perl script that is able to hang OpenBSD running inside a virtual machine with little memory and lots of swap and now, I want to see if I can reproduce it on real hardware. If it's i386/amd64, look at the 'mach mem' option in boot (eg, man boot). -ml
Re: queue(3) TAILQ example causes compiler warning
On Fri, Mar 02, 2012 at 12:46:15AM -0500, Lawrence Teo wrote:
The following example code in the queue(3) man page to delete all
elements in a tail queue generates a warning in gcc and clang.
while (np = TAILQ_FIRST(head)) {
TAILQ_REMOVE(head, np, entries);
free(np);
}
Here's a demo:
===BEGIN===
$ cat tailq.c
#include sys/queue.h
#include stdlib.h
struct entry {
int foo;
TAILQ_ENTRY(entry) entries;
} *np;
TAILQ_HEAD(tailhead, entry) head;
int
main(int argc, char *argv[])
{
TAILQ_INIT(head);
while (np = TAILQ_FIRST(head)) {
TAILQ_REMOVE(head, np, entries);
free(np);
}
return 0;
}
$ gcc -O2 -Wall -o tailq tailq.c
tailq.c: In function 'main':
tailq.c:16: warning: suggest parentheses around assignment used as truth value
===END===
The following diff fixes the example to prevent the warning from being
triggered.
Comments?
Thanks,
Lawrence
Index: queue.3
===
RCS file: /cvs/src/share/man/man3/queue.3,v
retrieving revision 1.54
diff -u -p -r1.54 queue.3
--- queue.3 11 Jan 2012 19:26:34 - 1.54
+++ queue.3 2 Mar 2012 05:29:24 -
@@ -966,7 +966,7 @@ TAILQ_FOREACH(np, head, entries)
for (np = n2; np != NULL; np = TAILQ_NEXT(np, entries))
np- ...
/* Delete. */
-while (np = TAILQ_FIRST(head)) {
+while ((np = TAILQ_FIRST(head)) != NULL) {
TAILQ_REMOVE(head, np, entries);
free(np);
}
If no one opposes, I'll commit this.
