And now with actual applies action...

Sorry for the previous one; try this one instead.

Index: acpicpu.c
===================================================================
RCS file: /cvs/src/sys/dev/acpi/acpicpu.c,v
retrieving revision 1.40
diff -u -p -u -p -r1.40 acpicpu.c
--- acpicpu.c 29 Dec 2007 02:55:44 -0000 1.40
+++ acpicpu.c 30 Dec 2007 17:46:02 -0000
@@ -94,9 +94,16 @@ struct acpicpu_softc {
struct aml_node *sc_devnode;

int sc_pss_len;
+ int sc_ppc;
+ int sc_level;
struct acpicpu_pss *sc_pss;

In order to be able to move proper cpu throttling along I want to get
the following diff in. It adds support for _PPC which defines which
power states are available after a cable pull or insert. An example is
my Dell D810; if I use a 65W power suppoy I can only run at 800MHz; if I
run unplugged I only have 5 out of 6 power states (depending on the
battery) and when plugged in to 90W power supply it has all power states
available. It also gets the code ready for the addition of duty cycle
throttling (only run the cpu every so many clock cycles). When both
those are in we can move forward to making acpitz do throttling based on
thermal requirements but those diffs are still a few days away.

Please test and send me a report of success / failure. I Particularly
need testing on amd64 laptops.

Hi,

as you may know, 4.2 contains support for large disks and partitions.
Large meaning > 1TB. What's still missing is the ffs support for
64-bit block numbers, the buffer cache and some drivers already are
capable of using 64-bit disk blocks.

Based on some previous work done by Pedro, I now have a diff that
allows large partitions.

I also includes an experimental implementation of statvfs(2), which
allows df(1) to cope with the larger numbers involved.

If you are interested, please check
<http://www.drijf.net/openbsd/ffs>, here's the README file:

=====================
Things to consider

- After applying the diff, rebuild both your kernel and userland.

- Not all controllers can handle larger than 2TB disks. I know arc(4)
works, since my test system has one. I also know ami(4) does not
support > 2TB volumes.

I believe the pointer lh can never be null.

Index: isofs/udf/udf_vnops.c
===================================================================
RCS file: /cvs/src/sys/isofs/udf/udf_vnops.c,v
retrieving revision 1.30
diff -u -r1.30 udf_vnops.c
--- isofs/udf/udf_vnops.c 9 Dec 2007 20:54:01 -0000 1.30
+++ isofs/udf/udf_vnops.c 28 Dec 2007 18:23:19 -0000
@@ -133,8 +133,6 @@
vn_lock(up->u_vnode, LK_EXCLUSIVE | LK_RETRY, p);
mtx_enter(&ump->um_hashmtx);
lh = &ump->um_hashtbl[up->u_ino & ump->um_hashsz];
- if (lh == NULL)
- LIST_INIT(lh);
LIST_INSERT_HEAD(lh, up, u_le);
mtx_leave(&ump->um_hashmtx);

provides programming help and webdesing help
at
http://www.geocities.com/experts_25

On 12/27/07, Ivan Solonin wrote:

Well, that behaviour is based on inet_aton(). If you read
http://www.openbsd.org/cgi-bin/man.cgi?query=inet_aton closely you see
""""All numbers supplied as ``parts'' in a dot notation may be decimal, oc-
tal, or hexadecimal, as specified in the C language (i.e., a leading 0x
or 0X implies hexadecimal; a leading 0 implies octal; otherwise, the num-
ber is interpreted as decimal)."""

The inet_aton(3) manual page, section ``INTERNET ADDRESSES'', will tell you.

Miod

# ping 192.168.025.11
PING 192.168.025.11 (192.168.21.11): 56 data bytes
--- 192.168.025.11 ping statistics ---
11 packets transmitted, 0 packets received, 100.0%% packet loss
#

I think, that 025 interpreted as octal number, but not decimal like
other octets of address.

It is correct behaviour or bug?

Thanks.
Ivan

i already commited this to -current

thanks for spotting this!
reyk

On Thu, Dec 27, 2007 at 07:51:55AM -0300, Diego Giagio wrote:

Ted,

You are right. The second length check was wrongly removed. Below
follows the correct patch:

======= spamd-synchdr.patch start ==========
--- sync.c.old Tue Dec 25 22:55:07 2007
+++ sync.c Wed Dec 26 08:02:38 2007
@@ -273,7 +273,8 @@

/* Ignore invalid or truncated packets */
hdr = (struct spam_synchdr *)buf;
- if (hdr->sh_version != SPAM_SYNC_VERSION ||
+ if (len < sizeof(struct spam_synchdr) ||
+ hdr->sh_version != SPAM_SYNC_VERSION ||
hdr->sh_af != AF_INET ||
len < ntohs(hdr->sh_length))
goto trunc;

======= spamd-synchdr.patch end ==========

--
DG

On Dec 27, 2007 12:58 AM, Ted Unangst gmail.com> wrote: