gmane.os.openbsd.tech

Intel Atom E600 watchdog(4) support

Matt Dainty — 2012-05-23T20:52:03

Attached are some patches that add support for the watchdog device on
boards based on the Intel Atom E600 series such as the Soekris net6501.

Based on existing drivers such as amdpcib(4), ichpcib(4) and ichwdt(4)
I've created an e600pcib(4) to override the standard pcib(4) which can
then access the watchdog device.

Here's the original dmesg:

---8<---
pcib0 at pci0 dev 31 function 0 "Intel E600 LPC" rev 0x00
isa0 at pcib0
---8<---

Here's with my changes:

---8<---
e600pcib0 at pci0 dev 31 function 0 "Intel E600 LPC" rev 0x00: watchdog
isa0 at e600pcib0
---8<---

I tested the watchdog by setting kern.watchdog.period to 60 and then
breaking into ddb and starting a stopwatch and timing until my net6501
resets, it take near enough to 60 seconds that I'm happy it's working.

On a watchdog-triggered reboot, I've done similar to ichwdt(4):

---8<---
e600pcib0 at pci0 dev 31 function 0 "Intel E600 LPC" rev 0x00: watchdog, reboot on timeout
isa0 at e600pcib0
---8<---

I've included the driver itself, man pages, ch

Re: sparc64 gcc4/asm illegal operands, Re: CVS: cvs.openbsd.org: ports

Miod Vallat — 2012-05-23T20:29:55

I have started to investigate this. This sounds like the good `oh wait,
coercing a mutiple-register value into a single register type uses a
different register number on big-endian platforms? but it works on x86!'
recurring bug which has been biting us in subtle cases since gcc 2.95.

In the meantime I'd suggest compiling this port with -fno-tree-ter on
sparc64 (and maybe all BE64 platforms).

Index: Makefile
===================================================================
RCS file: /cvs/ports/comms/xastir/Makefile,v
retrieving revision 1.26
diff -u -p -r1.26 Makefile
--- Makefile14 Nov 2011 11:05:08 -00001.26
+++ Makefile23 May 2012 20:13:29 -0000
< at >< at > -1,7 +1,5 < at >< at >
 # $OpenBSD: Makefile,v 1.26 2011/11/14 11:05:08 sthen Exp $
 
-BROKEN-sparc64=illegal operands building draw_symbols.c
-
 COMMENT=X amateur station tracking and info reporting
 
 DISTNAME=xastir-1.8.2
< at >< at > -22,6 +20,9 < at >< at > AUTOCONF_VERSION=2.59
 AUTOMAKE_VERSION=1.9
 USE_GROFF =Yes
 MAKE_ENV+=MOTIFLIB='-L${LOCALBASE}/lib -lXm'
+.if ${MAC

Re: wpi: add sensor for rfkill

Gregor Best — 2012-05-23T16:53:10

I usually manage the network connections on my laptop with an ifstated
configuration. If the wireless device's link went down, it could be for two
reasons: a) the connection dropped but I want it re-established as soon as
possible and b) the device was turned off with the RFkill switch. Before
adding
this sensor, there was no way to distinguish both without having a look at
the
machine and telling ifstated via e.g. some sort of temporary file that it
should
not attempt to bring up wpi0 because I _want_ it to be down instead of it
being
down because I went out of reach of the AP.

radio is disabled.

You mean like "IEEE802 ... (radio off)"? Or like a third state for the wifi
device, so It coudl be "active", "no network" and "no network (rfkill)"?


--
    Gregor Best

[demime 1.01d removed an attachment of type application/pgp-signature]

Re: wpi: add sensor for rfkill

Jonathan Gray — 2012-05-23T15:42:36

Could you explain why you have need of this sensor I don't
quite see it?  And it could perhaps be a better fit for
ifmedia, adding a type for when the radio is disabled.

Re: wpi: add sensor for rfkill

Gregor Best — 2012-05-23T15:22:24

That is right. If I recall correctly, the very reason for introducing real hardware killswitches was so that the OS could not
interfere with and override the kill switch in case the device needs to operate in RF-sensitive environments.


Thanks for the hint. An updated patch is attached.

fstatfs64 for compat/linux

Paul Irofti — 2012-05-23T13:33:45

Okay?


Index: linux_misc.c
===================================================================
RCS file: /cvs/src/sys/compat/linux/linux_misc.c,v
retrieving revision 1.77
diff -u -p -r1.77 linux_misc.c
--- linux_misc.c23 May 2012 11:08:57 -00001.77
+++ linux_misc.c23 May 2012 13:32:39 -0000
< at >< at > -554,6 +554,35 < at >< at > linux_sys_fstatfs(p, v, retval)
 return copyout((caddr_t) &ltmp, (caddr_t) SCARG(uap, sp), sizeof ltmp);
 }
 
+int
+linux_sys_fstatfs64(struct proc *p, void *v, register_t *retval)
+{
+struct linux_sys_fstatfs64_args /* {
+syscallarg(int) fd;
+syscallarg(struct linux_statfs64 *) sp;
+} */ *uap = v;
+struct statfs btmp, *bsp;
+struct linux_statfs64 ltmp;
+struct sys_fstatfs_args bsa;
+caddr_t sg;
+int error;
+
+sg = stackgap_init(p->p_emul);
+bsp = (struct statfs *) stackgap_alloc(&sg, sizeof (struct statfs));
+
+SCARG(&bsa, fd) = SCARG(uap, fd);
+SCARG(&bsa, buf) = bsp;
+
+if ((error = sys_fstatfs(p, &bsa, retval)))
+return error;
+
+if ((error = copyin((caddr_t) bsp, (caddr_t)

Ms clientes en su ciudad o localidad

Mercosur.com — 2012-05-23T12:10:35

Mas clientes en su ciudad o localidad

Re: mg(1) start up file diffs (2 of 2)

Mark Lumsden — 2012-05-23T07:36:36

"any of the *file* commands"

should be...

any of the other *file* commands

such as insert-file, etc..



----- Forwarded message from Mark Lumsden <mark< at >showcomplex.com> -----

From: Mark Lumsden <mark< at >showcomplex.com>
To: tech< at >openbsd.org
Subject: mg(1) start up file diffs (2 of 2)

Further to my previous email, I noticed if I tried to use any of the *file*
commands in the startup ~/.mg file, nothing happened. By looking at main.c,
I realised that the order of starup function calls was the problem. This diff
moves the creation of the startup buffers before parsing the startup file.

Now an ~/.mg file such as:

find-file main.c
insert-file lines.c

Will work as expected. Commands that are usually located in the startup file
(global-set-key, set-default-mode etc...) are unaffected since they are not
reliant on the buffers being created or not. However, wider testing would be
appreciated.

Comments/ok?

-lum

Index: main.c
===================================================================
RCS file: /cvs/sr

mg - start up file diffs (2 of 2)

Mark Lumsden — 2012-05-23T07:27:06

Further to my previous email, I noticed if I tried to use any of the *file*
commands in the startup ~/.mg file, nothing happened. By looking at main.c,
I realised that the order of starup function calls was the problem. This diff
moves the creation of the startup buffers before parsing the startup file.

Now an ~/.mg file such as:

find-file main.c
insert-file lines.c

Will work as expected. Commands that are usually located in the startup file
(global-set-key, set-default-mode etc...) are unaffected since they are not
reliant on the buffers being created or not. However, wider testing would be
appreciated.

Comments/ok?

-lum

Index: main.c
===================================================================
RCS file: /cvs/src/usr.bin/mg/main.c,v
retrieving revision 1.64
diff -u -p -r1.64 main.c
--- main.c12 Apr 2012 04:47:59 -00001.64
+++ main.c20 May 2012 17:11:24 -0000
< at >< at > -98,19 +98,18 < at >< at > main(int argc, char **argv)
  */
 update();
 
-/* user startup file */
-if ((cp = startupfile(NULL)) != NULL)
-

mg - start up file diffs (1 of 2)

Mark Lumsden — 2012-05-23T07:25:35

If you want to open up a file using the mg startup file (~/.mg) using the
find-file command, e.g:

find-file main.c

mg will give an odd message of "File read error", but the file opens anyway.
However, if by accident you try to open a non-existant file mg will segv. 

After investigating I found mg uses a static FILE pointer that is reused
in fileio.c, and in this case the dual opening of the ~/.mg file and
main.c was screwing things up.

This diff removes the static variable and passes the file pointer amongst
function calls. Now an ~/.mg file such as:

find-file main.c
find-file file.c
find-file README

works as expected. Opening three buffers with the files contents in each one.
Also, if a non-existant file is attemped to be opened mg doesn't crash.

comments/ok?

-lum

Index: def.h
===================================================================
RCS file: /cvs/src/usr.bin/mg/def.h,v
retrieving revision 1.120
diff -u -p -r1.120 def.h
--- def.h12 Apr 2012 04:47:59 -00001.120
+++ def.h23 May 2012 07:

Re: wpi: add sensor for rfkill

Tobias Ulmer — 2012-05-23T07:12:20

This a read-only sensor, it has no effect on misbehaving
hardware as far as I can tell.

Gregor: try adding '-p' to cvs diff

Cena Gourmet en BRANDS 52% OFF | Paseo en Velero 64% OFF | Peninsula Valdez 75% OFF | Tandil 67% OFF | Kingston de 8 GB 50% OFF | Cafetera de Filtro 51% OFF

Bonus Cupon — 2012-05-23T03:49:48

Para visualizar correctamente este newsletter ingresa a
http://news1.bonuscupon.com.ar/r.html?uid=1.i.295h.9f.rfwk1ki6bg

Re: wpi: add sensor for rfkill

Brett — 2012-05-23T03:27:26

On Tue, 22 May 2012 20:20:38 +0200
Gregor Best <gbe< at >ring0.de> wrote:



Hi Gregor,

I wonder if it will be possible to tell interfaces to ignore the rfkill switches if this goes in? 

I have an exopc tablet and it is impossible to run regular linux on it, because the rfkill is hardwired permanently "off", so no wifi possible. Also I have seen a laptop (I think it was a HP) where the rfkill button is broken "off", so again no wifi possible, as its killed by rfkill. 

Brett.

wpi: add sensor for rfkill

Gregor Best — 2012-05-22T18:20:38

Hi people,

the attached patch adds an indicator sensor to wpi devices that describes the
current RFKill status.  If the RF killswitch is engaged, the sensor reads "Off",
if it is not engaged and the device can operate, it reads "On".

If this is okay, I plan on adding similar sensors to other wireless devices,
but in that case I'd need help testing those because I only have access to wpi
devices.

Un Club d'achats réservé aux Professionnels

Jacques Monet [PROCOPAM] — 2012-05-22T17:59:18

Programme R&eacute;gional Bonjour,

Contrairement &agrave; nombre de vos confr&egrave;res et
coll&egrave;gues, vous ne semblez pas encore en profiter. C'est
pourquoi il me paraissait utile de vous rappeler que toutes les
personnes exer&ccedil;ant dans votre secteur d'activit&eacute; peuvent
d&eacute;sormais b&eacute;n&eacute;ficier gratuitement d'avantages
importants pour leur consommation familiale.

Une id&eacute;e simple&nbsp;: la force &eacute;conomique que nous
repr&eacute;sentons ne peut pas laisser indiff&eacute;rents les grands
acteurs de la distribution.

Nous avons donc n&eacute;goci&eacute; en direct avec toutes les grandes
Enseignes et avons d&eacute;j&agrave; obtenu un accord avec plus de 700
d'entre elles&nbsp;: Fnac.com, PIXmania, Thomas Cook, Monoprix, Leroy
Merlin et bien d'autres...

Nous vous remboursons automatiquement une partie de chacun de vos
achats personnels&nbsp;: 7% en moyenne. En plus, vous profitez en
permanence de r&eacute;ductions sp&eacute;ciales et debons plans
exclusifs.

V

Re: add statfs64 to compat/linux

Paul Irofti — 2012-05-22T17:29:36

New diff with no magic numbers (suggested by jsing< at >), more filesystems
support (suggested by ajacoutot< at >), including the header this time and
fixing a comment (suggested by matthew< at >).


Index: linux_misc.c
===================================================================
RCS file: /cvs/src/sys/compat/linux/linux_misc.c,v
retrieving revision 1.76
diff -u -p -r1.76 linux_misc.c
--- linux_misc.c22 Apr 2012 05:43:14 -00001.76
+++ linux_misc.c22 May 2012 17:26:55 -0000
< at >< at > -364,9 +364,7 < at >< at > linux_sys_time(p, v, retval)
  * we fake (probably the wrong way).
  */
 static void
-bsd_to_linux_statfs(bsp, lsp)
-struct statfs *bsp;
-struct linux_statfs *lsp;
+bsd_to_linux_statfs(struct statfs *bsp, struct linux_statfs *lsp)
 {
 
 /*
< at >< at > -376,19 +374,25 < at >< at > bsd_to_linux_statfs(bsp, lsp)
  */
 if (!strcmp(bsp->f_fstypename, MOUNT_FFS) ||
     !strcmp(bsp->f_fstypename, MOUNT_MFS))
-lsp->l_ftype = 0x11954;
+lsp->l_ftype = LINUX_FSTYPE_FFS;
 else if (!strcmp(bsp->f_fstypename, MOUNT_NFS))
-lsp->l_ftype = 0x6969

Re: add statfs64 to compat/linux

Paul Irofti — 2012-05-22T17:20:35


I keep it as an int now because things seem really stupid from what I'm
reading in the linux kernel:

http://tinyurl.com/chnpxnz

Re: add statfs64 to compat/linux

Paul Irofti — 2012-05-22T17:21:40

And then there's the other fields that are copied the same way and would
still keep code duplication.

I think this isn't worth the time to turn into something clean.

Re: add statfs64 to compat/linux

Matthew Dempsky — 2012-05-22T16:48:42

What about a function like this:

long
bsd_to_linux_filesystem_map(const char *fstypename)
{
        if (!strcmp(fstypename, MOUNT_FFS) || !strcmp(fstypename, MOUNT_MFS))
                return (0x11954);
        else if (!strcmp(fstypename, MOUNT_NFS))
                return (0x6969);
        [...]
        else
                return (-1);
}

(I'm assuming linux_statfs64's l_ftype is also a long.)

Re: add statfs64 to compat/linux

Paul Irofti — 2012-05-22T16:42:27

Yup, missed the file in the diff. Thanks for spoting that.


I thought about it. Best would be a macro, but I hate C macro's.


Copy-paste error, thanks.


Yup, I have that in a separate diff.

Re: add statfs64 to compat/linux

Matthew Dempsky — 2012-05-22T15:35:48

Are you missing the header bits for linux_statfs64?  I don't see where
it's defined.


Can this code go into a separate function so we don't have to
duplicate it for both statfs and statfs64?


The comment is wrong: sp should be linux_statfs64.


It looks like linux_sys_fstatfs64 should be easy to implement too now
if you wanted to do that in this diff as well.