Openbsd 4.2 Beta Issues Options

[ZDevil]

I think the current 4.2 Beta deserves a separate thread for discussion.

The first issue I run into is the setting of the cpu speed in /etc/sysctl.conf.
For "machdep.maxspeed", both 520 and 450 seem not working.
I see this error message during booting:

CODE

"sysctl: machdep.maxspeed: value is not available"

But according to www.planetofidiots.com/zaurus/ 450 is supposed to work, despite that 520 is said to be unstable under the current build. What to do?

Sidenote: i've managed to set up a NFS server on my Macbook without virtualization, and my 3200 succeeds in mounting the NFS shares to build ports there. But I am doing things a bit differently from the instructions in www.planetofidiots.com/zaurus/ . Will post a step-by-step guide soon.

[mathemajikian]

The first issue I run into is the setting of the cpu speed in /etc/sysctl.conf.
For "machdep.maxspeed", both 520 and 450 seem not working.
I see this error message during booting:

CODE

"sysctl: machdep.maxspeed: value is not available"

You need to run mergemaster after you update. It seems that this sysctl option has been removed along with a few others.

[ZDevil]

Thanks. Actually I reinstalled everything from the ground up, so there seems to be no need for mergemaster. The machdep.maxspeed and closelid.suspend functions seem to have been turned off in the current 4.2 beta (#158). Is that true?

[mathemajikian]

Thanks. Actually I reinstalled everything from the ground up, so there seems to be no need for mergemaster. The machdep.maxspeed and closelid.suspend functions seem to have been turned off in the current 4.2 beta (#158). Is that true?

This seems to be the case, but I'm not sure if it's just a beta change or something which will be more permanent.

[ZDevil]

I see. Thanks...
Well, that doesn't really hurt, as now I am rebuilding the packages for 4.2 with optimization, which can make up for the lack of (over)clocking.

[iamasmith]

http://marc.info/?l=openbsd-arm&m=118701458824485&w=2

^^ -Andy

 sys_arch_arm_include_cpu_h_fix_machdeps.patch.txt ( 699bytes ) Number of downloads: 16

[ZDevil]

Thanks, Andy. So will this patch be used for the next snapshot?

[iamasmith]

Thanks, Andy. So will this patch be used for the next snapshot?

Who knows, they have ignored patches I sent before. I have to admit that Theo asked me to nag about getting my Caps Lock patches included in 4.1 but I didn't have time to chase the submitters.

Hopefully this will be seen as an easy submission and won't even touch the sides

-Andy

[iamasmith]

Actually, Miod just responded and said that the way that I am handling the change isn't correct in terms of how the MIB is treated (numbers shouldn't be reassigned). I will issue another patch when I have tested.

Regards,

-Andy

[mathemajikian]

Actually, Miod just responded and said that the way that I am handling the change isn't correct in terms of how the MIB is treated (numbers shouldn't be reassigned). I will issue another patch when I have tested.

Regards,

-Andy

How else can you achieve this? I don't understand why your method is incorrect?
http://www.openbsd.org/cgi-bin/cvsweb/src/....16&r2=1.17&f=h

[iamasmith]

Well, Miod pointed out that the ordinals assigned to the sysctl mibs have to stay assigned as they originally were. I'm guessing that there may be other ways of referencing the sysctl mib tree, possibly like other mibs.. i.e. 1.22.1.33 etc. to select nodes of a mib tree. Bearing in mind that the mib may possibly be accessible through SNMP etc.

To retain the IDs I will do what Miod has suggested and put the strings back into the cpu.h section leaving the methods unimplemented, however, my source build tree is on an NFS server at work atm. so I'll kick off a test build tomorrow morning before all my meetings start

-Andy

[mathemajikian]

Well, Miod pointed out that the ordinals assigned to the sysctl mibs have to stay assigned as they originally were. I'm guessing that there may be other ways of referencing the sysctl mib tree, possibly like other mibs.. i.e. 1.22.1.33 etc. to select nodes of a mib tree. Bearing in mind that the mib may possibly be accessible through SNMP etc.

To retain the IDs I will do what Miod has suggested and put the strings back into the cpu.h section leaving the methods unimplemented, however, my source build tree is on an NFS server at work atm. so I'll kick off a test build tomorrow morning before all my meetings start

-Andy

Just read the OpenBSD-ARM messages. Makes sense, but won't that lead to a bit of code clutter?

[iamasmith]

There are many sysctls that have been depracated and/or moved to IOCTLs so there is a certain amount of clutter but this kind of procedure is necessary to protect anybody using older mibs to ensure that the mibs don't hit the wrong values.

I have found that implementing the change in the way suggested requires a little more work since if you leave the mib without a handler the sysctl calls don't process any more of the mib tree.

I should create a handler really that says that the access mechanism for those mibs (ztsscale and ztsrawmode) is deprecated and that tools should be updated.

I will look at this when I have a little more time, one of my projects at work has kicked into overdrive though

-Andy

[iamasmith]

Actually I got an email from robert@ saying he was on it.

So there will be a fix, from one of us.

-Andy

[ZDevil]

Thanks! Looking forward to that.