Messages

1

OpenBSD / Openbsd 4.2 Beta Issues

« on: August 16, 2007, 09:59:52 am »

It does work, but you need to build a new version of sysctl from cvs.

Make sure that it builds with the new version of cpu.h.

-Andy

2

OpenBSD / Openbsd 4.2 Beta Issues

« on: August 16, 2007, 08:08:38 am »

Umm, has anybody tested the new CVS yet?

This is the first change that I tried but it failed. I think that the slots need a handler or they are treated as the end of the mib.

I found when I tried this 'fix' that maxspeed and lidsuspend were still unavailable.

-Andy

3

OpenBSD / Openbsd 4.2 Beta Issues

« on: August 14, 2007, 05:52:08 pm »

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

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

-Andy

4

OpenBSD / Openbsd 4.2 Beta Issues

« on: August 14, 2007, 06:53:29 am »

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

5

OpenBSD / Openbsd 4.2 Beta Issues

« on: August 13, 2007, 05:28:29 pm »

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

6

OpenBSD / Openbsd 4.2 Beta Issues

« on: August 13, 2007, 11:25:32 am »

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

7

OpenBSD / Openbsd 4.2 Beta Issues

« on: August 13, 2007, 11:05:01 am »

Thanks, Andy. So will this patch be used for the next snapshot?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=166154\"][{POST_SNAPBACK}][/a][/div]

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

8

OpenBSD / Openbsd 4.2 Beta Issues

« on: August 13, 2007, 10:23:36 am »

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

^^ -Andy

 [ Invalid Attachment ]

9

OpenBSD / Matchbox And Rotation

« on: June 21, 2007, 03:28:42 am »

...
isn't there an xrandr command?

i have patched icewm to actually have an additional rotate button and option which then calls rotate.sh script which in turn calls other things to ensure correct rotation, etc.. but in essence it calls xrandr

if you are interested, look under the icewm thread on the pdaxrom subforum where i attached patches for icewem..
[div align=\"right\"][{POST_SNAPBACK}][/a][/div]

xrandr extensions work now? man I wish I still had as much time to play with my Z.

The last time I chatted with Matthieu he mentioned that xrandr rotate extensions were going to go into the driver... do you know if he triggered touch screen rotation with xrandr? The best way that I could find for managing touch screen rotation was with a Kernel patch that rotated the co-ordinates prior to scaling against the calibration parameters - the previous mechanism where x and y co-ordinates were handled by the X touch screen driver meant that the Kernel scaling was making the touch screen inaccurate when rotated.

Here is the proof of concept patch that I wrote at the time..

[a href=\"http://marc.info/?l=openbsd-arm&m=113993195221600&w=2]http://marc.info/?l=openbsd-arm&m=113993195221600&w=2[/url]

Look right to the end of the posting for a full explanation of the co-ordinate issue.

-Andy

10

OpenBSD / Console Response After Running X

« on: May 12, 2007, 06:33:49 pm »

hmmm.. what ever happened to Iamasmith...

He still posts every once and awhile.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=160592\"][{POST_SNAPBACK}][/a][/div]

Heh, I'm still here and listening in from time to time. However, I have been contracting for about 9 months now and am pretty focussed upon that so I don't have as much time to tinker.

I'm working in a more strategic field right now and technology is only a small part of the problems that I face.

I will post when I can and hope to start contributing to OpenBSD again at some point... incidently - I believe that the console problems aren't fixed. What they have done is made X run on Console #2 and switch to screen 2 whilst running X.

The X server still seems to screw up the frame buffer. I believe there is still an  outstanding problem with the DMA cache coherency.

BTW: I'm really sorry that I didn't follow up on Theo's request to nag the committers to include a variant of my Caps lock fixes for Kernel and X on 4.1. I have just been soooo busy. The good news is that they still seem to apply without any problems

-Andy

11

OpenBSD / Sd Support!

« on: May 02, 2007, 05:48:45 pm »

Thanks, Andy!
Here is the output of disklabel sd0:

Code: [Select]

# /dev/rsd0c:
type: SCSI
disk: SCSI disk
label: Drive #01
flags:
bytes/sector: 2048
sectors/track: 63
tracks/cylinder: 255
sectors/cylinder: 16065
cylinders: 125
total sectors: 2010112
rpm: 3600
interleave: 1
trackskew: 0
headswitch: 0           # microseconds
track-to-track seek: 0  # microseconds
drivedata: 0

16 partitions:
#           size     offset   fstype  [fsize bsize  cpg]
     c:   2010112          0   unused       0     0      # Cyl        0 -     125*[div align=\"right\"][a href=\"index.php?act=findpost&pid=160295\"][{POST_SNAPBACK}][/a][/div]

Ok, here's the problem. The disklabel isn't defaulting based upon an ext2 partition and can't determine the beginning of the logical device to say where the ext2 partition starts.

c will ALWAYS exist if the OS can recognise the disk geometry since c is always the full raw disk area.

If you aren't too fussed about what is on the drive I would suggest that you run..

disklabel -E sd0

Then add a partition, possibly a, and set it up in the disklabel then make your ffs or ext2 filesystem from OpenBSD.

This all may seem a little wacky but UNIX folks still regard MSDOS partition tables as particularly PC'ish and like to rely on their own more portable partition information

Good luck,

-Andy

12

OpenBSD / Sd Support!

« on: May 02, 2007, 07:25:12 am »

It's ext2. I tried all the nodes and only sd0c would do, but it returns this error.
Reboot the system with the card inserted gives the same error.

Then try and use mount_ext2fs not mount_ffs.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=160215\"][{POST_SNAPBACK}][/a][/div]

Now it's this:

Code: [Select]

#mount_ext2fs /dev/sd0c /mnt/card
mount_ext2fs: /dev/sd0c on /mnt/card: specified device does not match mounted device
while all other sd0x show "Device not configured"
[div align=\"right\"][a href=\"index.php?act=findpost&pid=160217\"][{POST_SNAPBACK}][/a][/div]

Does the device have a disklabel as well as an fdisk partition table? if not the disklabel will be assumed as default.

Quite often expect to see msdos partitions on sd0i but as this is ext2 you should verify what has been assumed by using..

disklabel sd0

This should print out what OpenBSD thinks the partitions are.

Good Luck,

-Andy

13

OpenBSD / Just A Suggestion For Openbsd Zaurus Site

« on: February 12, 2007, 05:52:02 pm »

Hi there,

Long time no see but I have been contracting and they just extended my contract by another 5 months  Pretty much all Windows and a little tiny bit of Linux but as Strategic Design Authority for a large group of companies it pays reasonably well... shame it's not more hands on *NIX and paying the same

OK,

http://www.openbsd.org/zaurus.html

is under the control of the OpenBSD site of course. Any 'interesting' changes on the Zaurus can be found on http://www.openbsd.org/plus.html if you search for Zaurus.

Of course anything major should be updated on the zaurus page but sometimes it is forgotten. Send an email to misc@openbsd.org if they missed something and it usually gets updated.

-Andy

14

6000 - Tosa / Sharp Hc-6000cn

« on: October 30, 2006, 04:34:58 pm »

There has got to be a way to get a copy of this OS for tinkering!
[div align=\"right\"][a href=\"index.php?act=findpost&pid=121655\"][{POST_SNAPBACK}][/a][/div]

Guys, this is warez talk... like it or not it is. You haven't paid for the license (and legitimately the only way to do so is buy the device) so please don't follow this track.

-Andy

15

OpenBSD / Warning About Ports

« on: October 19, 2006, 03:45:41 pm »

Note the xscale binaries/libraries seem to be somewhat bigger than the standard ARM versions so I suggest you decide on performance critical things to build with these flags.

- Andy
[div align=\"right\"][{POST_SNAPBACK}][/a][/div]

are you talking about ports in [a href=\"ftp://ftp.openbsd.org/pub/OpenBSD/snapshots/packages/arm/]ftp://ftp.openbsd.org/pub/OpenBSD/snapshots/packages/arm/[/url] ?

do you mean that we should rebuild them with the xscale options
[div align=\"right\"][a href=\"index.php?act=findpost&pid=144344\"][{POST_SNAPBACK}][/a][/div]

Umm, see top of thread