Re: audioctl: display variables periodically

[Edd Barrett]

I agree with ratchov that in this instance, precise timing isn't important.

10 Dec 2022 05:53:48 Alexandre Ratchov :

> On Fri, Dec 09, 2022 at 12:43:31PM -0600, Scott Cheloha wrote:
>> On Fri, Dec 09, 2022 at 12:10:59PM +0100, Alexandre Ratchov wrote:
>>> This diff adds an option to display variables periodically. Basically
>>> it replaces this usage:
>>> 
>>>     while sleep 1; do audioctl play.errors; done
>>> 
>>> by
>>> 
>>>     audioctl -w 1 play.errors
>>> 
>>> The purpose of above audioctl commands is to debug underruns, so we
>>> don't want to fork a new process and reopen the device. This would
>>> trigger longer kernel code-paths and may cause additional underruns
>>> than the ones being investigated.
>>> 
>>> OK?
>> 
>> I like the idea, but I would like to tweak some things.
>> 
>> - Add [-w wait] to the first synoptic form in the manpage.  It's legal
>>   to do e.g.
>> 
>>     # audioctl -w 1
>> 
> 
> done
> 
>> - Call the variable "wait" in audioctl.c to match the manpage.
>> 
> 
> done (used wait_sec, as there's a global wait() symbol).
> 
>> - Update usagestr to mention [-w wait].
>> 
> 
> done
> 
>> - When polling variables periodically, it's better to use setitimer(2)
>>   and sigsuspend(2) instead of sleep(3).  setitimer(2) keeps the period
>>   from drifting.
>> 
>> - Let the user SIGINT (^C) out of the program without returning an
>>   error to the shell.
>> 
>>   I'm unsure about this one, but it seems logical to give the user a
>>   way to gracefully terminate the program.  You say in the manpage that
>>   the program will continue printing until it is interrupted.
>> 
> 
> I just tried these. Synchronizing the display to a clock might make
> sense if it was the sound card's clock, but here the result was boiler
> with no benefit. The intent of -w is to just show the variables from
> time to time, so keeping the code trivial is more important,
> IMHO. I've added a comment to say so.
> 
> About ^C, I've changed the man page text to "audioctl will display
> variables forever." which implies that ^C is out of the scope.
> 
> Index: audioctl.8
> ===
> RCS file: /cvs/src/usr.bin/audioctl/audioctl.8,v
> retrieving revision 1.4
> diff -u -p -r1.4 audioctl.8
> --- audioctl.8  23 Apr 2020 00:16:59 -  1.4
> +++ audioctl.8  10 Dec 2022 05:50:05 -
> @@ -35,9 +35,11 @@
> .Sh SYNOPSIS
> .Nm audioctl
> .Op Fl f Ar file
> +.Op Fl w Ar wait
> .Nm audioctl
> .Op Fl n
> .Op Fl f Ar file
> +.Op Fl w Ar wait
> .Ar name ...
> .Nm audioctl
> .Op Fl nq
> @@ -59,6 +61,12 @@ The default is
> Suppress printing of the variable name.
> .It Fl q
> Suppress all output when setting a variable.
> +.It Fl w Ar wait
> +Pause
> +.Ar wait
> +seconds between each display.
> +.Nm
> +will display variables forever.
> .It Ar name Ns = Ns Ar value
> Attempt to set the specified variable
> .Ar name
> @@ -130,10 +138,10 @@ audio control devices
> audio devices
> .El
> .Sh EXAMPLES
> -Display the number of bytes of silence inserted during play buffer
> -underruns since device started:
> +Once per-second, display the number of bytes of silence inserted due to 
> buffer
> +underruns (since the device started playback):
> .Bd -literal -offset indent
> -# audioctl play.errors
> +# audioctl -w 1 play.errors
> .Ed
> .Pp
> Use signed 24-bit samples and 44100Hz sample rate:
> Index: audioctl.c
> ===
> RCS file: /cvs/src/usr.bin/audioctl/audioctl.c,v
> retrieving revision 1.43
> diff -u -p -r1.43 audioctl.c
> --- audioctl.c  12 Jul 2021 15:09:19 -  1.43
> +++ audioctl.c  10 Dec 2022 05:50:05 -
> @@ -43,6 +43,7 @@ struct field {
> #define STR    2
> #define ENC    3
>     int type;
> +   int show;
>     int set;
> } fields[] = {
>     {"name",    ,    NULL,   STR},
> @@ -63,11 +64,11 @@ struct field {
> };
> 
> const char usagestr[] =
> -   "usage: audioctl [-f file]\n"
> -   "   audioctl [-n] [-f file] name ...\n"
> +   "usage: audioctl [-f file] [-w wait_sec]\n"
> +   "   audioctl [-n] [-f file] [-w wait_sec] name ...\n"
>     "   audioctl [-nq] [-f file] name=value ...\n";
> 
> -int fd, show_names = 1, quiet = 0;
> +int fd, show_names = 1, quiet = 0, wait_sec = 0;
> 
> /*
>   * parse encoding string (examples: s8, u8, s16, s16le, s24be ...)
> @@ -198,20 +199,9 @@ audio_main(int argc, char **argv)
>     char *lhs, *rhs;
>     int set = 0;
> 
> -   if (ioctl(fd, AUDIO_GETSTATUS, ) == -1)
> -   err(1, "AUDIO_GETSTATUS");
> -   if (ioctl(fd, AUDIO_GETDEV, ) == -1)
> -   err(1, "AUDIO_GETDEV");
> -   if (ioctl(fd, AUDIO_GETPAR, ) == -1)
> -   err(1, "AUDIO_GETPAR");
> -   if (ioctl(fd, AUDIO_GETPOS, ) == -1)
> -   err(1, "AUDIO_GETPOS");
>     if (argc == 0) {
> -   for (f = fields; f->name != NULL; f++) {
> -   printf("%s=", f->name);
> -   print_field(f, f->raddr);
> -   printf("\n");
> -   }
> +   for (f = fields; 

Re: audioctl: display variables periodically

[Edd Barrett]

On Fri, Dec 09, 2022 at 12:10:59PM +0100, Alexandre Ratchov wrote:
> -Display the number of bytes of silence inserted during play buffer
> -underruns since device started:
> +Once per second, display the number of bytes of silence inserted
> +during play buffer underruns since device started:

Would it read better as:

"Once per-second, display the number of bytes of silence inserted due to buffer
underruns (since the device started playback):"

And don't forget to update the usage message too :)

-- 
Best Regards
Edd Barrett

https://www.theunixzoo.co.uk

Re: Lenovo ThinkCentre M910q fails to suspend

[Edd Barrett]

On Fri, Jun 17, 2022 at 12:46:49PM -0700, Mike Larkin wrote:
> Sorry, out of ideas.

No worries. Thanks for all of the back and forth :)

-- 
Best Regards
Edd Barrett

https://www.theunixzoo.co.uk

Re: Lenovo ThinkCentre M910q fails to suspend

[Edd Barrett]

Hi Mike,

On Fri, Jun 17, 2022 at 11:55:51AM -0700, Mike Larkin wrote:
> >  - disabling xhci in ukc: the system fails to boot multi-user. The first
> >oddness comes where cpus #1-3 fail to "become ready" (as reported by 
> > dmesg).
> >It spends a while thinking about these cores not coming up, before
> >eventually proceeding, but eventually hard resetting. I guess the system
> >really needs xhci to function then...
> 
> That really makes no sense. can you try the same experiment again using 
> GENERIC?

Doing `boot bsd.sp -c` and then `disable xhci` means that the system can at
least boot with no xhci, but sadly it still won't stay in the suspended state.

That might rule out xhci as a source of the issue, maybe.

-- 
Best Regards
Edd Barrett

https://www.theunixzoo.co.uk

Re: Lenovo ThinkCentre M910q fails to suspend

[Edd Barrett]

Hi Mike,

On Fri, Jun 17, 2022 at 10:20:35AM -0700, Mike Larkin wrote:
> Oh, didn't read this closely enough the first time. If ZZZ doesn't instantly 
> wake
> the machine, then it's one of the two S3 devices described in your next email.
> Since one is XHCI, I'd disable xhci in ukc and see if that helps. Or maybe the
> other *hci(4)s also.

Alright, so here's some more info.

 - disabling xhci in ukc: the system fails to boot multi-user. The first
   oddness comes where cpus #1-3 fail to "become ready" (as reported by dmesg).
   It spends a while thinking about these cores not coming up, before
   eventually proceeding, but eventually hard resetting. I guess the system
   really needs xhci to function then...

 - disabling ehci or ahci: no change to sleep behaviour.

 - disabling usb: no change to sleep behaviour.

I don't see any [XEA]HCI options in the BIOS that I could tweak.

Unless you have any other ideas, I'll try disabling random devices in the hope
that I can narrow it down... I've already tried the network card, it aint that.

Thanks.

-- 
Best Regards
Edd Barrett

https://www.theunixzoo.co.uk

Re: Lenovo ThinkCentre M910q fails to suspend

[Edd Barrett]

On Fri, Jun 17, 2022 at 09:14:45AM +0100, Edd Barrett wrote:
> > 1. remove the code that truncates this list after 16, and note down all the
> > wake devices.

Here's the full list:

acpi0: wakeup devices PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) PEG2(S4) PEGP(S4) 
SIO1(S3) RP09(S4) PXSX(S4) RP10(S4) PXSX(S4) RP11(S4) PXSX(S4) RP12(S4) 
PXSX(S4) RP13(S4) PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) 
PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PXSX(S4) RP06(S4) PXSX(S4) RP07(S4) 
PXSX(S4) RP08(S4) PXSX(S4) RP17(S4) PXSX(S4) RP18(S4) PXSX(S4) RP19(S4) 
PXSX(S4) RP20(S4) PXSX(S4) RP21(S4) PXSX(S4) RP22(S4) PXSX(S4) RP23(S4) 
PXSX(S4) RP24(S4) PXSX(S4) RP14(S4) PXSX(S4) RP15(S4) PXSX(S4) RP16(S4) 
PXSX(S4) GLAN(S4) XHC_(S3) XDCI(S4) HDAS(S4)

So there are just two S3 things listed:
 - SIO1(S3)
 - XHC_(S3)

-- 
Best Regards
Edd Barrett

https://www.theunixzoo.co.uk

Re: Lenovo ThinkCentre M910q fails to suspend

[Edd Barrett]

Hi Mike,

On Thu, Jun 16, 2022 at 09:19:50PM -0700, Mike Larkin wrote:
> From your original dmesg:
> 
> > acpi0: wakeup devices PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) PEG2(S4) PEGP(S4) 
> > SIO1(S3) RP09(S4) PXSX(S4) RP10(S4) PXSX(S4) RP11(S4) PXSX(S4) RP12(S4) 
> > PXSX(S4) RP13(S4) [...]
> 
> Notice the [...] at the end, this is printed after 16 devices. What I'd 
> suggest
> is this:
> 
> 1. remove the code that truncates this list after 16, and note down all the 
> wake
> devices.
> 
> 2. If there are any in S3, try using ZZZ instead of zzz. If the machine does 
> not instantly
> wake, it's possible it's because of one of those S3 devices doing the wake 
> (since ZZZ
> uses S4).

I'll try removing the truncation then. Bear with me.

In the meantime, notice that the truncated list does include one S3 item
`SIO1(S3)`. I don't know if that's what we are looking for?

FWIW, I have already tried `ZZZ` on this machine and it does succeed to
hibernate, but upon wake up, it hangs when decompressing the memory image. I
left it decompressing a ~50MB image for more than an hour and concluded it had
got stuck.

> 3. If everything is S4, well, you're going to have to trace down those short 
> names
> like PEGP, PXSX, etc, and disable one at a time until you find the one that is
> doing the wake. And it's possible it's none of these and is a fixed function
> button or something.

One additional piece of info, which may be worthless. I tried a Debian live USB
stick, to see if Linux was able to sleep this box. It was able to.

I don't know if that rules out the idea of a fixed-function button?

-- 
Best Regards
Edd Barrett

https://www.theunixzoo.co.uk

Re: Lenovo ThinkCentre M910q fails to suspend

[Edd Barrett]

On Thu, Jun 16, 2022 at 10:22:16AM -0700, Mike Larkin wrote:
> did it ever work in the past?

I've only just received the machine, so it's difficult to say.

I've spent the last hour changing various BIOS settings to see if anything
changes, but alas no. I don't see any sleep-related power options, and any
fancy power stuff I don't need or recognise, I've disabled. No joy.

I've even updated the BIOS software to no avail. Hrm...

-- 
Best Regards
Edd Barrett

https://www.theunixzoo.co.uk

Lenovo ThinkCentre M910q fails to suspend

[Edd Barrett]

 pci0 dev 2 function 0 "Intel HD Graphics 530" rev 0x06
drm0 at inteldrm0
inteldrm0: msi, SKYLAKE, gen 9
xhci0 at pci0 dev 20 function 0 "Intel 200 Series xHCI" rev 0x00: msi, xHCI 1.0
usb0 at xhci0: USB revision 3.0
uhub0 at usb0 configuration 1 interface 0 "Intel xHCI root hub" rev 3.00/1.00 
addr 1
"Intel 200 Series Thermal" rev 0x00 at pci0 dev 20 function 2 not configured
"Intel 200 Series MEI" rev 0x00 at pci0 dev 22 function 0 not configured
ahci0 at pci0 dev 23 function 0 "Intel 200 Series AHCI" rev 0x00: msi, AHCI 
1.3.1
ahci0: PHY offline on port 0
ahci0: PHY offline on port 1
ahci0: PHY offline on port 2
ahci0: PHY offline on port 3
scsibus1 at ahci0: 32 targets
ppb0 at pci0 dev 27 function 0 "Intel 200 Series PCIE" rev 0xf0: msi
pci1 at ppb0 bus 1
nvme0 at pci1 dev 0 function 0 "Samsung SM961/PM961 NVMe" rev 0x00: msix, NVMe 
1.2
nvme0: SAMSUNG MZVLW128HEGR-000L1, firmware 5L1QCXB7, serial S341NX0K521287
scsibus2 at nvme0: 2 targets, initiator 0
sd0 at scsibus2 targ 1 lun 0: 
sd0: 122104MB, 512 bytes/sector, 250069680 sectors
pcib0 at pci0 dev 31 function 0 "Intel Q270 LPC" rev 0x00
"Intel 200 Series PMC" rev 0x00 at pci0 dev 31 function 2 not configured
azalia0 at pci0 dev 31 function 3 "Intel 200 Series HD Audio" rev 0x00: msi
azalia0: codecs: Realtek ALC294, Intel/0x2809, using Realtek ALC294
audio0 at azalia0
ichiic0 at pci0 dev 31 function 4 "Intel 200 Series SMBus" rev 0x00: apic 2 int 
16
iic0 at ichiic0
spdmem0 at iic0 addr 0x50: 8GB DDR4 SDRAM PC4-19200 SO-DIMM
spdmem1 at iic0 addr 0x52: 8GB DDR4 SDRAM PC4-19200 SO-DIMM
em0 at pci0 dev 31 function 6 "Intel I219-LM" rev 0x00: msi, address 
6c:4b:90:7e:76:f4
isa0 at pcib0
isadma0 at isa0
pckbc0 at isa0 port 0x60/5 irq 1 irq 12
pckbd0 at pckbc0 (kbd slot)
wskbd0 at pckbd0: console keyboard
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
vmm0 at mainbus0: VMX/EPT
vscsi0 at root
scsibus3 at vscsi0: 256 targets
softraid0 at root
scsibus4 at softraid0: 256 targets
root on sd0a (5d59e5562a788986.a) swap on sd0b dump on sd0b
WARNING: clock gained 2 days
WARNING: CHECK AND RESET THE DATE!
drm:pid0:intel_ddi_sanitize_encoder_pll_mapping *NOTICE* [drm] [ENCODER:94:DDI 
\M-j/PHY  ] is disabled/in DSI mode with an ungated DDI clock, gate it
drm:pid0:intel_ddi_sanitize_encoder_pll_mapping *NOTICE* [drm] [ENCODER:109:DDI 
\M-j/PHY  ] is disabled/in DSI mode with an ungated DDI clock, gate it
inteldrm0: 1920x1080, 32bpp
wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation), using wskbd0
wsdisplay0: screen 1-5 added (std, vt100 emulation)
```

-- 
Best Regards
Edd Barrett

https://www.theunixzoo.co.uk

Re: FAT32 short filename inconsistencies

[Edd Barrett]

Hi,

On Wed, Jan 26, 2022 at 05:41:30PM +0100, Tilo Stritzky wrote:
>  If neither -s nor -l are given, mount_msdos searches the root
>  directory of the file system to be mounted for any existing
>  Windows 95/98 long filenames.  If no such entries are found, -s
>  is the default.  Otherwise -l is assumed.

For a moment I couldn't find that text. Well, turns out this passage was
removed in November 2021 (in version 1.32 of mount_msdos.c):

http://cvsweb.openbsd.org/src/sbin/mount_msdos/mount_msdos.8

kn@ did the work, so I'm CCing them.

> The way I read this whole thing is that ``Force'' refers to turning
> off the auto-detection and enforce the long mode. See also the
> description of the -s flag further down.

Just to double check, on OpenBSD I created a new filesystem, and explicitly
mounted it with `-l`, created files called `A` and `LONGLONGLONG`. Then on
Linux (with default mount options), I see `a` and `LONGLONGLONG`.

So it's clear that OpenBSD doesn't always create long filenames, even if you
mount explicitly with `-l`. And `-l` does really appear to be default.

> Have you tried enforcing short (old scool) mode by using -s?

WELL THAT WOULD WORK, BUT ALL OF MY FILENA~1 WOULD BE TRUNCA~1 ;)

kn@, what do you think? Should `-l` *always* (really always) create long
filenames?

Cheers

-- 
Best Regards
Edd Barrett

https://www.theunixzoo.co.uk

FAT32 short filename inconsistencies

[Edd Barrett]

Hi,

CC afresh1@, with whom I've discussed this a little already.

If I make a FAT32 filesystem on a thumb drive on OpenBSD (using the default
parameters) and mount it (with the default options) and proceed to make some
strategically named files:

```
# touch a B a B longlonglong OPENBSD_OPENBSD
# ls
B  B  OPENBSD_OPENBSD  a  a  longlonglong
```

And now mount that filesystem (with default options) on a Linux box, we see
that some of the files appear with different case from how they were created
above:

```
# ls
a  a  b  b  longlonglong  OPENBSD_OPENBSD
```

After reading about the mess they made with FAT filesystems, what I think
happened was: OpenBSD made "long filename" entries for names that either didn't
fit in the 8.3 scheme, or which were not all upper-case (the assumption, I
think, being that files with no long filename will be displayed all upper-case
anyway, at least on OpenBSD).

The problem is that entries with no long filename seem to be open to
interpretation on different systems:

 - OpenBSD shows them upper-case
 - Linux (by default) shows them lower case.

If on Linux you mount with `-o shortname=win95`, then you get the same
interpretation as OpenBSD.

But is there (or should there be) a way to make OpenBSD display the filenames
as Linux would?

If everything above is correct, I think that would mean either creating all
files (even if they fit in 8.3) with a long filename, or changing OpenBSD's
interpretation of short-only filenames to be lower case. I see no
mount_msdos(8) options that may help.

Note that `-l` is the default:

>   -lForce listing and generation of Windows 95/98 long filenames and
> separate creation/modification/access dates.

I'm not sure if this is completely accurate. If we were really forcing
generation of long filenames, then the files `B` and `B` should have had
long filename entries, but they didn't appear to.

Should the sentence be suffixed "if the filename doesn't fit in the 8.3
scheme"? Or perhaps the behaviour `-l` should be changed to *really always*
create long filenames regardless of the length? I don't know.

Why do I ask? I need to copy lots of files, preserving case, to an SD card for
use in an embedded Linux machine on which I don't have control over the
filesystem type or mount options.

[One hack that I think would work for me, would be to rename all of my files
lower-case before copying to the FAT filesystem. This would force OpenBSD to
create long filenames, but that may not be suitable for every user's
circumstance]

Cheers

-- 
Best Regards
Edd Barrett

https://www.theunixzoo.co.uk

human-readable audio device descriptions

[Edd Barrett]

",
+   vendor, codec->vid & 0x);
+   } else
+   snprintf(buf, MAX_AUDIO_DESCR_LEN, "%s", codec->name);
+
+   if (i > 0)
+   strlcat(descr, ", ", len);
+   strlcat(descr, buf, len);
+   }
 }
 
 int
Index: sys/dev/usb/uaudio.c
===
RCS file: /cvs/src/sys/dev/usb/uaudio.c,v
retrieving revision 1.161
diff -u -p -r1.161 uaudio.c
--- sys/dev/usb/uaudio.c18 May 2021 10:02:00 -  1.161
+++ sys/dev/usb/uaudio.c2 Jul 2021 19:15:53 -
@@ -431,6 +431,7 @@ int uaudio_query_devinfo(void *, struct 
 int uaudio_get_port(void *, struct mixer_ctrl *);
 int uaudio_set_port(void *, struct mixer_ctrl *);
 int uaudio_get_props(void *);
+void uaudio_descr(void *, char *, size_t);
 
 int uaudio_process_unit(struct uaudio_softc *,
 struct uaudio_unit *, int,
@@ -493,7 +494,9 @@ struct audio_hw_if uaudio_hw_if = {
uaudio_trigger_input,   /* trigger_input */
uaudio_copy_output, /* copy_output */
uaudio_underrun,/* underrun */
-   uaudio_set_blksz/* set_blksz */
+   uaudio_set_blksz,   /* set_blksz */
+   NULL,   /* set_nblks */
+   uaudio_descr,   /* descr */
 };
 
 /*
@@ -4189,6 +4192,14 @@ int
 uaudio_get_props(void *self)
 {
return AUDIO_PROP_FULLDUPLEX;
+}
+
+
+void
+uaudio_descr(void *arg, char *descr, size_t len)
+{
+   struct uaudio_softc *sc = arg;
+   snprintf(descr, len, "%s %s", sc->udev->vendor, sc->udev->product);
 }
 
 int
Index: sys/sys/audioio.h
===
RCS file: /cvs/src/sys/sys/audioio.h,v
retrieving revision 1.27
diff -u -p -r1.27 audioio.h
--- sys/sys/audioio.h   14 Sep 2016 06:12:20 -  1.27
+++ sys/sys/audioio.h   7 Jul 2021 10:23:09 -
@@ -76,10 +76,10 @@ struct audio_status {
  * audio devices.
  */
 #define MAX_AUDIO_DEV_LEN  16
+#define MAX_AUDIO_DESCR_LEN32
 typedef struct audio_device {
char name[MAX_AUDIO_DEV_LEN];
-   char version[MAX_AUDIO_DEV_LEN];
-   char config[MAX_AUDIO_DEV_LEN];
+   char descr[MAX_AUDIO_DESCR_LEN]; /* device description string */
 } audio_device_t;
 
 struct audio_pos {
Index: usr.bin/audioctl/audioctl.c
===
RCS file: /cvs/src/usr.bin/audioctl/audioctl.c,v
retrieving revision 1.42
diff -u -p -r1.42 audioctl.c
--- usr.bin/audioctl/audioctl.c 2 Feb 2020 05:25:41 -   1.42
+++ usr.bin/audioctl/audioctl.c 2 Jul 2021 19:15:53 -
@@ -46,6 +46,7 @@ struct field {
int set;
 } fields[] = {
{"name",,NULL,   STR},
+   {"descr",   ,   NULL,   STR},
{"mode",,  NULL,   MODE},
{"pause",   , NULL,   NUM},
{"active",  ,NULL,   NUM},
Index: share/man/man4/audio.4
===
RCS file: /cvs/src/share/man/man4/audio.4,v
retrieving revision 1.86
diff -u -p -r1.86 audio.4
--- share/man/man4/audio.4  1 Nov 2020 21:32:03 -   1.86
+++ share/man/man4/audio.4  7 Jul 2021 13:41:38 -
@@ -112,8 +112,7 @@ argument.
 .Bd -literal
 typedef struct audio_device {
 char name[MAX_AUDIO_DEV_LEN];
-char version[MAX_AUDIO_DEV_LEN];
-char config[MAX_AUDIO_DEV_LEN];
+char descr[MAX_AUDIO_DESCR_LEN];
 } audio_device_t;
 .Ed
 .Pp


-- 
Best Regards
Edd Barrett

http://www.theunixzoo.co.uk

sndiod: allow mixing of duplex, record-only and play-only audio devices

[Edd Barrett]

~0U;
}
-   *rctlhdl = ctlhdl;
-   return hdl;
+   return 1;
}
}
-   return NULL;
+   return 0;
 }
 
 /*
@@ -144,38 +182,19 @@ int
 dev_sio_open(struct dev *d)
 {
struct sio_par par;
-   unsigned int mode = d->mode & (MODE_PLAY | MODE_REC);
 
-   d->sio.hdl = dev_sio_openlist(d, mode, >sioctl.hdl);
-   if (d->sio.hdl == NULL) {
-   if (mode != (SIO_PLAY | SIO_REC))
-   return 0;
-   d->sio.hdl = dev_sio_openlist(d, SIO_PLAY, >sioctl.hdl);
-   if (d->sio.hdl != NULL)
-   mode = SIO_PLAY;
-   else {
-   d->sio.hdl = dev_sio_openlist(d,
-   SIO_REC, >sioctl.hdl);
-   if (d->sio.hdl != NULL)
-   mode = SIO_REC;
-   else
-   return 0;
-   }
-   if (log_level >= 1) {
-   log_puts("warning, device opened in ");
-   log_puts(mode == SIO_PLAY ? "play-only" : "rec-only");
-   log_puts(" mode\n");
-   }
-   }
+   if (!dev_sio_openlist(d, >sio.hdl, >sioctl.hdl, >mode))
+   return 0;
+
sio_initpar();
par.bits = d->par.bits;
par.bps = d->par.bps;
par.sig = d->par.sig;
par.le = d->par.le;
par.msb = d->par.msb;
-   if (mode & SIO_PLAY)
+   if (d->mode & SIO_PLAY)
par.pchan = d->pchan;
-   if (mode & SIO_REC)
+   if (d->mode & SIO_REC)
par.rchan = d->rchan;
if (d->bufsz)
par.appbufsz = d->bufsz;
@@ -211,14 +230,14 @@ dev_sio_open(struct dev *d)
log_puts(": unsupported sample size\n");
goto bad_close;
}
-   if ((mode & SIO_PLAY) && par.pchan > NCHAN_MAX) {
+   if ((d->mode & SIO_PLAY) && par.pchan > NCHAN_MAX) {
dev_log(d);
log_puts(": ");
log_putu(par.pchan);
log_puts(": unsupported number of play channels\n");
goto bad_close;
}
-   if ((mode & SIO_REC) && par.rchan > NCHAN_MAX) {
+   if ((d->mode & SIO_REC) && par.rchan > NCHAN_MAX) {
dev_log(d);
log_puts(": ");
log_putu(par.rchan);
@@ -254,17 +273,15 @@ dev_sio_open(struct dev *d)
d->par.sig = par.sig;
d->par.le = par.le;
d->par.msb = par.msb;
-   if (mode & SIO_PLAY)
+   if (d->mode & SIO_PLAY)
d->pchan = par.pchan;
-   if (mode & SIO_REC)
+   if (d->mode & SIO_REC)
d->rchan = par.rchan;
d->bufsz = par.bufsz;
d->round = par.round;
d->rate = par.rate;
-   if (!(mode & MODE_PLAY))
-   d->mode &= ~(MODE_PLAY | MODE_MON);
-   if (!(mode & MODE_REC))
-   d->mode &= ~MODE_REC;
+   if (d->mode & MODE_PLAY)
+   d->mode |= MODE_MON;
sio_onmove(d->sio.hdl, dev_sio_onmove, d);
d->sio.file = file_new(_sio_ops, d, "dev", sio_nfds(d->sio.hdl));
if (d->sioctl.hdl) {
@@ -291,18 +308,13 @@ dev_sio_open(struct dev *d)
 int
 dev_sio_reopen(struct dev *d)
 {
-   struct sioctl_hdl *ctlhdl;
struct sio_par par;
struct sio_hdl *hdl;
+   struct sioctl_hdl *ctlhdl;
+   unsigned int mode;
 
-   hdl = dev_sio_openlist(d, d->mode & (MODE_PLAY | MODE_REC), );
-   if (hdl == NULL) {
-   if (log_level >= 1) {
-   dev_log(d);
-   log_puts(": couldn't open an alternate device\n");
-   }
+   if (!dev_sio_openlist(d, , , ))
return 0;
-   }
 
sio_initpar();
par.bits = d->par.bits;
@@ -310,10 +322,10 @@ dev_sio_reopen(struct dev *d)
par.sig = d->par.sig;
par.le = d->par.le;
par.msb = d->par.msb;
-   if (d->mode & SIO_PLAY)
-   par.pchan = d->pchan;
-   if (d->mode & SIO_REC)
-   par.rchan = d->rchan;
+   if (mode & SIO_PLAY)
+   par.pchan = d->reqpchan;
+   if (mode & SIO_REC)
+   par.rchan = d->reqrchan;
par.appbufsz = d->bufsz;
par.round = d->round;
par.rate = d->rate;
@@ -343,6 +355,7 @@ dev_sio_reopen(struct dev *d)
}
 
/* update parameters */
+   d->mode = mode;
d->par.bits = par.bits;
d->par.bps = par.bps;
d->par.sig = par.sig;


-- 
Best Regards
Edd Barrett

http://www.theunixzoo.co.uk

Re: sndiod: Move controls out of the device structure, please test & review

[Edd Barrett]

On Fri, Jan 29, 2021 at 04:16:44PM +0100, Alexandre Ratchov wrote:
> Thanks for the feedback, new diff below. It fixes a server crash when
> a client issues an invalid request.

I retested the crash scenario, and can confirm that it is fixed.

No other problems to report!

-- 
Best Regards
Edd Barrett

http://www.theunixzoo.co.uk

Re: search usbd_interfaces in case of non-compliant device

[Edd Barrett]

On Thu, Jan 28, 2021 at 09:56:14AM +, Edd Barrett wrote:
>

Here's a revised diff that always searches the array, instead of first
trying the expected index. Everyone agreed that this makes for simpler
code, and that since this function isn't called much, there's no real
performance concern.

Cursory testing seems good. All USB devices working so far, including
the non-compliant uaudio device.

Please give this a spin to check for breakage.

Index: usbdi.c
===
RCS file: /cvs/src/sys/dev/usb/usbdi.c,v
retrieving revision 1.107
diff -u -p -r1.107 usbdi.c
--- usbdi.c 27 Jan 2021 17:28:19 -  1.107
+++ usbdi.c 28 Jan 2021 14:19:28 -
@@ -638,12 +638,23 @@ usbd_status
 usbd_device2interface_handle(struct usbd_device *dev, u_int8_t ifaceno,
 struct usbd_interface **iface)
 {
+   u_int8_t idx;
+
if (dev->cdesc == NULL)
return (USBD_NOT_CONFIGURED);
-   if (ifaceno >= dev->cdesc->bNumInterfaces)
-   return (USBD_INVAL);
-   *iface = >ifaces[ifaceno];
-   return (USBD_NORMAL_COMPLETION);
+   /*
+* The correct interface should be at dev->ifaces[ifaceno], but we've
+* seen non-compliant devices in the wild which present non-contiguous
+* interface numbers and this skews the indices. For this reason we
+* linearly search the interface array.
+*/
+   for (idx = 0; idx < dev->cdesc->bNumInterfaces; idx++) {
+   if (dev->ifaces[idx].idesc->bInterfaceNumber == ifaceno) {
+   *iface = >ifaces[idx];
+   return (USBD_NORMAL_COMPLETION);
+   }
+   }
+   return (USBD_INVAL);
 }
 
 /* XXXX use altno */

-- 
Best Regards
Edd Barrett

http://www.theunixzoo.co.uk

Re: search usbd_interfaces in case of non-compliant device

[Edd Barrett]

Hi,

On Wed, Jan 27, 2021 at 08:58:21AM +0100, Alexandre Ratchov wrote:
> ok ratchov

Thanks everyone for your OKs.

Here's an updated diff that caters for Marcus' recent attribute renaming
and which also has the long comment wrapped.

I'll commit it shortly if nothing else comes up.


Index: usbdi.c
===
RCS file: /cvs/src/sys/dev/usb/usbdi.c,v
retrieving revision 1.107
diff -u -p -r1.107 usbdi.c
--- usbdi.c 27 Jan 2021 17:28:19 -  1.107
+++ usbdi.c 28 Jan 2021 00:01:11 -
@@ -638,12 +638,26 @@ usbd_status
 usbd_device2interface_handle(struct usbd_device *dev, u_int8_t ifaceno,
 struct usbd_interface **iface)
 {
+   u_int8_t idx;
+
if (dev->cdesc == NULL)
return (USBD_NOT_CONFIGURED);
-   if (ifaceno >= dev->cdesc->bNumInterfaces)
-   return (USBD_INVAL);
-   *iface = >ifaces[ifaceno];
-   return (USBD_NORMAL_COMPLETION);
+   if (ifaceno < dev->cdesc->bNumInterfaces &&
+   dev->ifaces[ifaceno].idesc->bInterfaceNumber == ifaceno) {
+   *iface = >ifaces[ifaceno];
+   return (USBD_NORMAL_COMPLETION);
+   }
+   /*
+* With some non-compliant devices, the correct interface may be found
+* at the wrong index.
+*/
+   for (idx = 0; idx < dev->cdesc->bNumInterfaces; idx++) {
+   if (dev->ifaces[idx].idesc->bInterfaceNumber == ifaceno) {
+   *iface = >ifaces[idx];
+   return (USBD_NORMAL_COMPLETION);
+   }
+   }
+   return (USBD_INVAL);
 }
 
 /*  use altno */


-- 
Best Regards
Edd Barrett

http://www.theunixzoo.co.uk

search usbd_interfaces in case of non-compliant device

[Edd Barrett]

Hi,

I've recently come across a uaudio device which doesn't work in OpenBSD:

uaudio2 at uhub0 port 1 configuration 1 interface 3 "E+ Corp. DAC Audio" rev 
1.10/0.01 addr 2
uaudio2: class v1, full-speed, async, channels: 2 play, 0 rec, 3 ctls
audio3 at uaudio2

When opening the audio device, the kernel reports `uaudio0: can't get iface
handle` in the dmesg buffer.

I posted information about the device and sthen@ and kettenis@ spotted
the problem: the device exposes non-consecutive interface numbers, and
is thus not compliant with the USB standard.

It has interfaces 0, 1 and 3, in that order. The audio stream is on
interface 3, which the kernel expects to find at index 3 in the ifaces
array, but actually it's at index 2!

I've pasted a load of info about the device (lsusb and debug kernel
output) here:
https://gist.github.com/vext01/958756d0fd515cc321f99a3ee1e3351a

The following diff makes this device work. It searches the ifaces array
in the event that the correct entry is not found at the expect index.
This should be a "no functional change" for all existing compliant
devices.

I've tested this for the past two days and all seems well, but I'd like
some USB stack hackers to verify it.

Cheers


Index: usbdi.c
===
RCS file: /cvs/src/sys/dev/usb/usbdi.c,v
retrieving revision 1.106
diff -u -p -r1.106 usbdi.c
--- usbdi.c 3 Apr 2020 20:11:47 -   1.106
+++ usbdi.c 24 Jan 2021 20:44:28 -
@@ -638,12 +638,23 @@ usbd_status
 usbd_device2interface_handle(struct usbd_device *dev, u_int8_t ifaceno,
 struct usbd_interface **iface)
 {
+   u_int8_t idx;
+
if (dev->cdesc == NULL)
return (USBD_NOT_CONFIGURED);
-   if (ifaceno >= dev->cdesc->bNumInterface)
-   return (USBD_INVAL);
-   *iface = >ifaces[ifaceno];
-   return (USBD_NORMAL_COMPLETION);
+   if (ifaceno < dev->cdesc->bNumInterface &&
+   dev->ifaces[ifaceno].idesc->bInterfaceNumber == ifaceno) {
+   *iface = >ifaces[ifaceno];
+   return (USBD_NORMAL_COMPLETION);
+   }
+   /* With some non-compliant devices, the interface may be at the wrong 
index */
+   for (idx = 0; idx < dev->cdesc->bNumInterface; idx++) {
+   if (dev->ifaces[idx].idesc->bInterfaceNumber == ifaceno) {
+   *iface = >ifaces[idx];
+   return (USBD_NORMAL_COMPLETION);
+   }
+   }
+   return (USBD_INVAL);
 }
 
 /*  use altno */


-- 
Best Regards
Edd Barrett

http://www.theunixzoo.co.uk

Re: RFC: kern.video.record

[Edd Barrett]

On Sat, Sep 19, 2020 at 06:07:05PM +0200, Solene Rapenne wrote:
> I vote for keeping both so we can enable audio only or video only
> and be sure about what is enabled and able to record our environment

I agree.

I do lots of audio-only calls with one of my colleagues and in that
scenario I'd prefer fine-grained control.

-- 
Best Regards
Edd Barrett

http://www.theunixzoo.co.uk

Re: cpu utilisation bars for top(1)

[Edd Barrett]

  break;
case 'C':
show_args = true;
break;
@@ -632,7 +637,7 @@ rundisplay(void)
char ch, *iptr;
int change, i;
struct pollfd pfd[1];
-   static char command_chars[] = "\f qh?en#sdkriIuSopCHg+P109)(";
+   static char command_chars[] = "\f qh?en#sdkriIuSopCHg+P109)(B";
 
        /*
 * assume valid command unless told
@@ -995,6 +1000,9 @@ rundisplay(void)
skip -= max_topn / 2;
if (skip < 0)
skip = 0;
+   break;
+   case CMD_bars:
+   cpu_bars = !cpu_bars;
break;
default:
new_message(MT_standout, " BAD CASE IN SWITCH!");


-- 
Best Regards
Edd Barrett

http://www.theunixzoo.co.uk

Re: cpu utilisation bars for top(1)

[Edd Barrett]

On Mon, Apr 13, 2020 at 11:40:21AM -0600, Theo de Raadt wrote:
> I don't like it.
> 
> CPU00 states:  0.0% user,  0.0% nice,  0.0% sys,  0.0% spin, 18.2% intr, 
> 81.8% idle
> CPU01 states:  0.0% user,  0.0% nice,  0.0% sys,  0.0% spin,  0.0% intr,  
> 100% idle
> 
> versus
> 
> []  
> 37.1%
> [#   ]  
> 45.0%
> 
> You have thrown information away.

Just to be clear, I'm not proposing we change the default display.

The bar graphs I'm proposing are only displayed when toggled on by
pressing `B` (or by invoking top(1) with `-B`).

Otherwise the display remains exactly as it was before.

-- 
Best Regards
Edd Barrett

http://www.theunixzoo.co.uk

Re: cpu utilisation bars for top(1)

[Edd Barrett]

On Mon, Apr 13, 2020 at 11:15:59AM -0600, Theo de Raadt wrote:
> I think your  bar-graph removes detailed information and replaces it
> with a visual which wastes screen real-estate.

I agree, that's why I made it a toggle.

-- 
Best Regards
Edd Barrett

http://www.theunixzoo.co.uk

Re: cpu utilisation bars for top(1)

[Edd Barrett]

On Mon, Apr 13, 2020 at 11:12:46AM -0600, Theo de Raadt wrote:

> If this is going to be done, it should look the same.  I'm not talking
> about the markers above it, but about your arbitrary use of #.

So you mean the first proposal is good, just change # to >?

Note that systat(1) uses both chevrons (first screen) and hashes (second
screen) for CPU bar graphs.

-- 
Best Regards
Edd Barrett

http://www.theunixzoo.co.uk

Re: cpu utilisation bars for top(1)

[Edd Barrett]

On Mon, Apr 13, 2020 at 06:26:53PM +0200, Sebastian Benoit wrote:
> If you make them look like the display in systat, you still get the user,
> ... nice, sys information. Also i like my bikeshed green.

So looking at the bar in `systat vmstat`, we have:
```
   0.0%Int   0.0%Spn   0.1%Sys  25.5%Usr  74.4%Idle
|||||||||||
>>>>>>>>>>>>>
```

To replicate that exactly per-processor, we'd need 3 lines per-cpu.

I don't think we want to steal too much screen real-estate from the actual
process listing, but we could try some middle-ground like:

 - No 'int, spn, sys, ...' line. You can toggle the bars off to see those.
 - One shared line for the hatchings, either an additional line or perhaps
   replacing the process counts line.
 - No enclosing square braces on the bars.
 - No numeric percentage display.
 - Use > instead of #.

So that might look like:

```
load averages:  1.13,  1.03,  0.65  arrakis.home 17:51:51
118 processes: 114 idle, 1 stopped, 3 on processorup 1 day,  4:36
|  |  |  |  |  |  |  |  |  |  |
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>
>>>>>>>
>
Memory: Real: 3931M/12G act/tot Free: 11G Cache: 6507M Swap: 0K/1028M

  PID USERNAME PRI NICE  SIZE   RES STATE WAIT  TIMECPU COMMAND
...
```

Something like that?

-- 
Best Regards
Edd Barrett

http://www.theunixzoo.co.uk

cpu utilisation bars for top(1)

[Edd Barrett]

umb terminal, or when the output is not a terminal.
+.It Fl B
+Show CPU utilisation bars instead of CPU states.
 .It Fl C
 Show command line arguments
 as well as the process itself.
@@ -295,6 +297,8 @@ Toggle the display of per CPU or combine
 Scroll up/down the process list by one line.
 .It \&( | \&)
 Scroll up/down the process list by screen half.
+.It B
+Toggle the display of CPU utilisation bars.
 .It C
 Toggle the display of process command line arguments.
 .It d Ar count
Index: top.c
===
RCS file: /cvs/src/usr.bin/top/top.c,v
retrieving revision 1.102
diff -u -p -r1.102 top.c
--- top.c   6 Jan 2020 20:05:10 -   1.102
+++ top.c   13 Apr 2020 14:43:10 -
@@ -72,6 +72,7 @@ static intskip;   /* how many processes 
 
 extern int ncpu;
 extern int ncpuonline;
+extern int cpu_bars;
 
 extern int (*proc_compares[])(const void *, const void *);
 int order_index;
@@ -131,6 +132,7 @@ struct statics  statics;
 #define CMD_up 25
 #define CMD_pagedown   26
 #define CMD_pageup 27
+#define CMD_bars   28
 
 static void
 usage(void)
@@ -212,11 +214,14 @@ parseargs(int ac, char **av)
char *endp;
int i;
 
-   while ((i = getopt(ac, av, "1SHICbinqus:d:p:U:o:g:")) != -1) {
+   while ((i = getopt(ac, av, "1SHICbinqus:d:p:U:o:g:B")) != -1) {
switch (i) {
case '1':
combine_cpus = 1;
break;
+   case 'B':
+   cpu_bars = true;
+   break;
case 'C':
show_args = true;
break;
@@ -632,7 +637,7 @@ rundisplay(void)
char ch, *iptr;
int change, i;
struct pollfd pfd[1];
-   static char command_chars[] = "\f qh?en#sdkriIuSopCHg+P109)(";
+   static char command_chars[] = "\f qh?en#sdkriIuSopCHg+P109)(B";
 
/*
 * assume valid command unless told
@@ -995,6 +1000,9 @@ rundisplay(void)
skip -= max_topn / 2;
if (skip < 0)
skip = 0;
+   break;
+   case CMD_bars:
+   cpu_bars = !cpu_bars;
break;
default:
new_message(MT_standout, " BAD CASE IN SWITCH!");


-- 
Best Regards
Edd Barrett

http://www.theunixzoo.co.uk

Re: Thinkpad X1 5th gen TPM chip

[Edd Barrett]

Hi Mike,

We've actually spoken about this issue before on this thread:
 
http://openbsd-archive.7691.n7.nabble.com/Thinkpad-X1-Carbon-5th-Gen-Flaky-Suspend-td334772.html

The symptoms remain the same and a colleague who also runs OpenBSD on an 
identical machine has the same issue.

Some time ago, I tried your strategy of moving the LED indicator flashing 
around to see if we could see where it gets stuck.

I got as far as deducing that the problem lies in a device driver (as opposed 
to stuff in the leadup to waking up devices), before a failed wake caused my 
disk to corrupt to the point where it wouldn't boot.

I've not had the time or the guts to try again, but Google searches suggest 
that people have had similar issues with Linux and even Windows on this model, 
so I'm not even certain it's a software issue. Then again, two (different) 
colleagues run Arch Linux on their X1 5gs and have no problem suspending.

Cheers!

Edd Barrett

Mon Mar 11 23:47:54 GMT 2019 Mike Larkin :

> On Mon, Mar 11, 2019 at 11:24:42AM +0000, Edd Barrett wrote:
> > Hi,
> >
> > I was looking at the manual page for tpm(4) and noticed that it has
> > something to to with suspend/resume:
> >
> > > Functionality is limited to instructing the device to save its
> > > state before a system suspend.
> >
> > The X1 5th generation has a MSFT0101 TPM chip which we don't yet attach
> > a driver to. tpm(4) seems happy to attach to with the following small
> > change. Then in dmesg I have:
> >
> > tpm0 at acpi0: TPM_ addr 0xfed4/0x5000: device 0x001b15d1 rev 0x10
> >
> > There are no errors relating to tpm in the dmesg.
> >
> > Sadly having tpm(4) attached doesn't fix suspend/resume on this machine,
> > but I wonder if the tpm driver should be used on this machine anyway? I
> > know nothing about tpm (really, I'm just stabbing in the dark here), so
> > I'm hoping someone else will have more of an idea.
> >
> > Thanks
> >
>
> What is broken with suspend/resume on this machine?
>
> >
> > Index: tpm.c
> > ===
> > RCS file: /cvs/src/sys/dev/acpi/tpm.c,v
> > retrieving revision 1.3
> > diff -u -p -r1.3 tpm.c
> > --- tpm.c 1 Jul 2018 19:40:49 - 1.3
> > +++ tpm.c 11 Mar 2019 10:57:38 -
> > @@ -194,6 +194,7 @@ const char *tpm_hids[] = {
> > "BCM0102",
> > "NSC1200",
> > "ICO0102",
> > + "MSFT0101",
> > NULL
> > };
> >
> >
> > --
> > Best Regards
> > Edd Barrett
> >
> > http://www.theunixzoo.co.uk
> >
>

Thinkpad X1 5th gen TPM chip

[Edd Barrett]

Hi,

I was looking at the manual page for tpm(4) and noticed that it has
something to to with suspend/resume:

>  Functionality is limited to instructing the device to save its
>  state before a system suspend.

The X1 5th generation has a MSFT0101 TPM chip which we don't yet attach
a driver to. tpm(4) seems happy to attach to with the following small
change. Then in dmesg I have:

tpm0 at acpi0: TPM_ addr 0xfed4/0x5000: device 0x001b15d1 rev 0x10

There are no errors relating to tpm in the dmesg.

Sadly having tpm(4) attached doesn't fix suspend/resume on this machine,
but I wonder if the tpm driver should be used on this machine anyway? I
know nothing about tpm (really, I'm just stabbing in the dark here), so
I'm hoping someone else will have more of an idea.

Thanks


Index: tpm.c
===
RCS file: /cvs/src/sys/dev/acpi/tpm.c,v
retrieving revision 1.3
diff -u -p -r1.3 tpm.c
--- tpm.c   1 Jul 2018 19:40:49 -   1.3
+++ tpm.c   11 Mar 2019 10:57:38 -
@@ -194,6 +194,7 @@ const char *tpm_hids[] = {
"BCM0102",
"NSC1200",
"ICO0102",
+   "MSFT0101",
    NULL
 };
 

-- 
Best Regards
Edd Barrett

http://www.theunixzoo.co.uk

Re: acpithinkpad: fix brightness keys, keyboard backlight value

[Edd Barrett]

On Wed, Mar 06, 2019 at 09:37:52PM +0100, Juan Francisco Cantero Hurtado wrote:
> The brightness keys on the X61s still work fine.

I've just built today's kernel on my X1 5th gen, and the backlight keys
now function.

Many thanks jcs@!

-- 
Best Regards
Edd Barrett

http://www.theunixzoo.co.uk

Re: dl_iterate_phdr(3) manual tweak

[Edd Barrett]

On Fri, Aug 24, 2018 at 11:47:35AM +0200, Mark Kettenis wrote:
> correct, but I'd leave out the second "until".

I prefer with the second until, but I'm not super-fussed.

Here's the diff without the second, OK?

Index: dl_iterate_phdr.3
===
RCS file: /cvs/src/share/man/man3/dl_iterate_phdr.3,v
retrieving revision 1.4
diff -u -p -r1.4 dl_iterate_phdr.3
--- dl_iterate_phdr.3   5 Jun 2013 03:42:03 -   1.4
+++ dl_iterate_phdr.3   24 Aug 2018 09:58:53 -
@@ -34,6 +34,11 @@ for each shared object, passing it infor
 program headers and the
 .Fa data
 argument.
+Iteration continues until either there are no more objects to
+iterate over, or
+.Fa callback
+returns a non-zero value.
+.Pp
 The information about the program headers is passed in a structure
 that is defined as:
 .Bd -literal

-- 
Best Regards
Edd Barrett

http://www.theunixzoo.co.uk

dl_iterate_phdr(3) manual tweak

[Edd Barrett]

Hi,

I've been working with dl_iterate_phdr(3) recently, and noticed a
missing detail from our manual page: when the callback returns non-zero,
iteration stops. This is documented in the Linux manual page, and I've
also verified this behaviour in our code:

dlfcn.c:
---8<---
for (object = _dl_objects; object != NULL; object = object->next) {
...
retval = callback(, sizeof (struct dl_phdr_info), data);
if (retval)
break;
}
--->8---

Any objections to the following change?

Index: dl_iterate_phdr.3
===
RCS file: /cvs/src/share/man/man3/dl_iterate_phdr.3,v
retrieving revision 1.4
diff -u -p -r1.4 dl_iterate_phdr.3
--- dl_iterate_phdr.3   5 Jun 2013 03:42:03 -   1.4
+++ dl_iterate_phdr.3   24 Aug 2018 09:19:02 -
@@ -34,6 +34,11 @@ for each shared object, passing it infor
 program headers and the
 .Fa data
 argument.
+Iteration continues until either there are no more objects to
+iterate over, or until
+.Fa callback
+returns a non-zero value.
+.Pp
 The information about the program headers is passed in a structure
 that is defined as:
 .Bd -literal

-- 
Best Regards
Edd Barrett

http://www.theunixzoo.co.uk

Re: RETGUARD

[Edd Barrett]

On Mon, Aug 21, 2017 at 12:13:05PM -, Christian Weisgerber wrote:
> lang/pypy retguard

I'm looking into PyPy.

Can you provide the build output?

Cheers

-- 
Best Regards
Edd Barrett

http://www.theunixzoo.co.uk

Small change to 6.1 upgrade guide

[Edd Barrett]

Hi,

A friend, who is fairly new to OpenBSD, was having some problems
upgrading the packages on his system.

The problem was that the upgrade guide doesn't make it totally clear
that `pkg_add -u` should be run after applying the configuration
changes. This matters for 6.1 as you need to migrate from pkg.conf(5) to
installurl(5) before `pkg_add -u` will work.

This change tries to make the order of the upgrade steps more explicit.

Makes sense? OK?


Index: faq/upgrade61.html
===
RCS file: /cvs/www/faq/upgrade61.html,v
retrieving revision 1.13
diff -u -p -r1.13 upgrade61.html
--- faq/upgrade61.html  24 Apr 2017 15:45:32 -  1.13
+++ faq/upgrade61.html  30 Apr 2017 09:33:12 -
@@ -35,12 +35,14 @@ For critical or physically remote machin
 local system first.
 
 
-Boot from the install kernel, bsd.rd:
+Start by performing the pre-update steps detailed below.
+Next, boot from the install kernel, bsd.rd:
 use bootable install media, or place the 6.1
 version of bsd.rd in the root of your filesystem and instruct the boot
 loader to boot this kernel.
 Once this kernel is booted, choose the (U)pgrade option and follow the
 prompts.
+Apply the configuration changes and remove the old files detailed below.
 Finish up by upgrading the packages: pkg_add -u.
 
 
-- 
Best Regards
Edd Barrett

http://www.theunixzoo.co.uk

Re: FAQ entry for vmm

[Edd Barrett]

Hi,

On Wed, Oct 19, 2016 at 06:42:08PM +0200, Daniel Jakots wrote:
> The second sentence in the FAQ is 'It covers the latest release of
> OpenBSD.'. Maybe it would be worth adding a sentence about the fact
> that it covers mainly current (as in -stable vmm is not enabled).

Just to keep the list in the loop, here is the version of the vmm faq
diff which I now have OKs for. We have decided however, to not commit
this until 6.1 release.

Thanks for all the feedback.


Index: faq/faq6.html
===
RCS file: /home/edd/cvsync/www/faq/faq6.html,v
retrieving revision 1.419
diff -u -p -r1.419 faq6.html
--- faq/faq6.html   8 Oct 2016 03:17:45 -   1.419
+++ faq/faq6.html   21 Oct 2016 15:22:13 -
@@ -50,6 +50,7 @@
 Setting up a network bridge
 Equal-cost multipath routing
 Adding and replacing NICs
+Networking vmm(4) guests
 
 
 
@@ -1183,6 +1184,89 @@ Some likely candidates might include:
   Bridge configuration (/etc/hostname.bridge*)
   Trunk configuration (/etc/hostname.trunk*)
 
+
+Networking vmm(4) guests
+
+Giving network access to a http://man.openbsd.org/vmm;>vmm(4)
+guest is easy if the host machine uses a wired connection.
+You can simply put the guest's http://man.openbsd.org/tap;>tap(4)
+interface into a bridged virtual switch with the host's wired interface.
+Inside the guest, the http://man.openbsd.org/vio;>vio(4)
+interface can then be configured as if it were a real machine physically
+connected to the host network.
+Unfortunately, this strategy does not work if the host machine uses a wireless
+network interface.
+Due to a limitation of the IEEE 802.11 standard, wireless interfaces cannot
+participate in network bridges.
+One way to work around this is to give the guest VM its own network and use
+network address translation (NAT) to the host's network.
+
+
+Suppose we have a host machine with network access via a wireless iwn0
+interface on the 192.168.1.0/24 network.
+We want to install an OpenBSD guest onto the 10.0.0.0/24 network and
+give the guest access to the host's network via NAT.
+Assume that we configured the guest's host-side interface to be fixed as
+tap0.
+Although we could set up NAT directly between the tap0 and
+iwn0, this tends to complicate matters, as tap0 will appear
+and disappear as the guest is powered up and down.
+In that case, we would have to reconfigure tap0 manually after each
+guest power-on.
+A more robust approach is to use an always-existing
+http://man.openbsd.org/vether;>vether(4) interface and
+have http://man.openbsd.org/vmd;>vmd(8) bridge this with
+tap0 when the guest is powered on.
+Since vether0 always exists regardless of whether the guest is powered
+up or not, its configuration will persist across guest power cycles.
+
+
+Let's make a vether0 interface:
+
+
+# echo "inet 10.0.0.1 255.255.255.0" > /etc/hostname.vether0
+# sh /etc/netstart vether0
+
+
+Add the following to /etc/pf.conf:
+
+
+match out on iwn0 inet from vether0:network to any nat-to (iwn0)
+
+
+And to finish off the NAT configuration:
+
+
+# pfctl -f /etc/pf.conf
+# echo "net.inet.ip.forwarding=1" >> /etc/sysctl.conf
+# sysctl net.inet.ip.forwarding=1
+net.inet.ip.forwarding: 0 -> 1
+
+
+In http://man.openbsd.org/vm.conf;vm.conf(5), ensure that you
+put vether0 into a virtual switch alongside tap0.
+For example:
+
+
+switch "my_switch" {
+add vether0
+interface bridge0
+}
+
+vm "my_vm" {
+...
+interface tap0 { switch "my_switch" }
+}
+
+
+Inside the guest, if we now assign vio0 an address on the
+10.0.0.0/24 network and set the default route to 10.0.0.1, we
+should be able to ping systems on the host network.
+For convenience, you may wish to set up a DHCP server on vether0.
+See http://man.openbsd.org/dhcpd;>dhcpd(8) and
+http://man.openbsd.org/dhcpd.conf;>dhcpd.conf(5) for details on
+how to set up a DHCP server (an example config file can be found at
+/etc/examples/dhcpd.conf).
 
 
 
Index: faq/index.html
===
RCS file: /home/edd/cvsync/www/faq/index.html,v
retrieving revision 1.495
diff -u -p -r1.495 index.html
--- faq/index.html  2 Oct 2016 21:16:26 -   1.495
+++ faq/index.html  20 Oct 2016 13:36:18 -
@@ -112,6 +112,7 @@ that are not covered in the FAQ.
 Setting up a network bridge
 Equal-cost multipath routing
 Adding and replacing NICs
+Networking vmm(4) guests
 
 
 Keyboard and Display Controls

-- 
Best Regards
Edd Barrett

http://www.theunixzoo.co.uk

Re: vm.conf(5) manual tweak for switches

[Edd Barrett]

On Sun, Oct 16, 2016 at 07:15:41PM +0100, Edd Barrett wrote:
> The following diff attempts to fix this, and tweaks the surrounding text
> a bit too.

Any love for this?

-- 
Best Regards
Edd Barrett

http://www.theunixzoo.co.uk

Re: FAQ entry for vmm

[Edd Barrett]

Hi,

On Mon, Oct 17, 2016 at 05:28:38PM +0100, Edd Barrett wrote:
> Thanks. The general consensus was to try to reduce this a lot before
> commit though. I will probably only include the wireless setup in the
> FAQ.

Here is the reduced version. I also moved this into the networking
section.

Better? OK?

Index: faq/faq6.html
===
RCS file: /home/edd/cvsync/www/faq/faq6.html,v
retrieving revision 1.419
diff -u -p -r1.419 faq6.html
--- faq/faq6.html   8 Oct 2016 03:17:45 -   1.419
+++ faq/faq6.html   19 Oct 2016 15:56:20 -
@@ -50,6 +50,7 @@
 Setting up a network bridge
 Equal-cost multipath routing
 Adding and replacing NICs
+Networking vmm(4) guests
 
 
 
@@ -1183,6 +1184,96 @@ Some likely candidates might include:
   Bridge configuration (/etc/hostname.bridge*)
   Trunk configuration (/etc/hostname.trunk*)
 
+
+Networking vmm(4) guests
+
+
+Giving a http://man.openbsd.org/vmm;>vmm(4) guest network
+access is easy if the host machine uses a wired network interface: you can then
+simply put the guest's http://man.openbsd.org/tap;>tap(4)
+interface into a bridged virtual switch with the host's wired interface.
+Inside the guest, the http://man.openbsd.org/vio;>vio(4)
+interface can then be configured as if it were a real machine physically
+connected to the host network.
+Unfortunately, this strategy does not work if the host machine has a wireless
+network interface.
+Due to a limitation of the IEEE 802.11 standard, wireless interfaces can not
+participate in network bridges.
+One way to work around this is to give the guest VM its own network and use
+network address translation (NAT) to the host's network.
+
+
+Suppose that we have a host machine with network access via a wireless
+iwn0 interface on the 192.168.1.0/24 network, and that we
+want to install an OpenBSD guest onto a the 192.168.10.0/24 network 
and
+give the guest access to the host's network via a NAT.
+Assume that we configured the guest's host-side interface to be fixed as
+tap0.
+Although we could set up NAT directly between the tap0 and
+iwn0, this tends to complicate matters, as tap0 will appear
+and disappear as the guest is powered up and down.
+This would mean that we would have to reconfigure the address of tap0
+manually after each guest power-on.
+A more robust approach is to use an always-existing
+http://man.openbsd.org/vether;vether(4) interface and
+have http://man.openbsd.org/vmd;vmd(8) bridge this with
+tap0 when the guest is powered on.
+Since vether0 always exists regardless of whether the guest is powered
+up or not, its configuration will persist across guest power cycles.
+
+
+Let's make a vether0 interface:
+
+
+# echo "inet 192.168.10.1 255.255.255.0" > /etc/hostname.vether0
+# sh /etc/netstart vether0
+
+
+
+We need to add a http://man.openbsd.org/pf;pf(4) rule to
+do the NATting.
+Put in the correct place in /etc/pf.conf:
+
+
+match out on iwn0 inet from vether0:network to any nat-to (iwn0)
+
+
+
+And to finish off the NAT configuration:
+
+
+# pfctl -f /etc/pf.conf
+# echo "net.inet.ip.forwarding=1" >> /etc/sysctl.conf
+# sysctl net.inet.ip.forwarding=1
+net.inet.ip.forwarding: 0 -> 1
+
+
+
+In
+http://man.openbsd.org/vm.conf;vm.conf(5), ensure
+that you put vether0 into a virtual switch alongside tap0.
+For example:
+
+
+switch "my_switch" {
+add vether0
+interface bridge0
+}
+
+vm "my_vm" {
+...
+interface tap0 { switch "my_switch" }
+}
+
+
+
+Inside the guest if we now assign vio0 an address on the
+192.168.10.0/24 network, and set the default route to
+192.168.10.1, we should be able to ping systems on the host network.
+For convenience, you may wish to set up a DHCP server on vether0.
+See http://man.openbsd.org/dhcpd;dhcpd(8) and
+http://man.openbsd.org/dhcpd.conf;dhcpd(5) for
+details on how to set up a DHCP server.
 
 
 
Index: faq/index.html
===
RCS file: /home/edd/cvsync/www/faq/index.html,v
retrieving revision 1.495
diff -u -p -r1.495 index.html
--- faq/index.html  2 Oct 2016 21:16:26 -   1.495
+++ faq/index.html  19 Oct 2016 16:07:59 -
@@ -112,6 +112,7 @@ that are not covered in the FAQ.
 Setting up a network bridge
 Equal-cost multipath routing
 Adding and replacing NICs
+Networking vmm(4) guests
 
 
 Keyboard and Display Controls

-- 
Best Regards
Edd Barrett

http://www.theunixzoo.co.uk

Re: FAQ entry for vmm

[Edd Barrett]

Hi Reyk,

On Mon, Oct 17, 2016 at 06:20:25PM +0200, Reyk Floeter wrote:
> Sorry for the late reply - thanks for doing this.  No objections, OK
> from me as well.

Thanks. The general consensus was to try to reduce this a lot before
commit though. I will probably only include the wireless setup in the
FAQ.

> It is a good place to explain things like networking in more detail
> that cannot be done in the manpages (but the vm.conf(5) manpage also
> needs improvement in the EXAMPLES section).

I posted an improvement to vm.conf(5) yesterday, albeit not to the
examples section. Still looking for an OK on that.

> One very minor nit: why re0? ;-) I think modern vmm-compatible
> machines with VMX/VT-d/EPT will have em0 in most cases ...

It's just what my test system had in it. We can easily switch to em.

-- 
Best Regards
Edd Barrett

http://www.theunixzoo.co.uk

vm.conf(5) manual tweak for switches

[Edd Barrett]

Hi,

In vm.conf(5):

---8<---
Virtual switches can be configured at any point in the configuration
file; they allow switchd to add network interfaces of VMs to the
underlying switch interfaces automatically.
--->8---

This confused me, since i've been using virtual switches without
switchd. I have a suspicion that "switchd" was supposed to be "vmd" in
that sentence (?).

The following diff attempts to fix this, and tweaks the surrounding text
a bit too.

Comments, OK?


Index: vm.conf.5
===
RCS file: /home/edd/cvsync/src/usr.sbin/vmd/vm.conf.5,v
retrieving revision 1.8
diff -u -p -r1.8 vm.conf.5
--- vm.conf.5   15 Oct 2016 14:02:11 -  1.8
+++ vm.conf.5   16 Oct 2016 18:14:00 -
@@ -165,23 +165,36 @@ is greater than the number of
 statements, additional default interfaces will be added.
 .El
 .Sh SWITCH CONFIGURATION
-Virtual switches can be configured at any point in the configuration file;
-they allow
-.Nm switchd
-to add network interfaces of VMs to the underlying switch interfaces
-automatically.
-It is possible to pre-configure switch interfaces using
+A virtual switch allows VMs to communicate with other network interfaces on the
+host system via either
+.Xr bridge 4
+or
+.Xr switch 4 .
+The network interface for each virtual switch defined in
+.Nm
+is automatically created by
+.Xr vmd 8 ,
+but it is also possible to pre-configure switch interfaces using
 .Xr hostname.if 5
 or
-.Xr ifconfig 8 ,
-see the sections
+.Xr ifconfig 8
+(see the
 .Sx BRIDGE
-or
+and
 .Sx SWITCH
-in
+sections in
 .Xr ifconfig 8
-accordingly.
+accordingly).
+When a VM is started, virtual network interfaces which are assigned to a
+virtual switch have their
+.Xr tap 4
+interface automatically added into the corresponding
+.Xr bridge 4
+or
+.Xr switch 4
+interface underlying the virtual switch.
 .Pp
+Virtual switches can be configured at any point in the configuration file.
 Each
 .Ic switch
 section starts with a declaration of the virtual switch:

-- 
Best Regards
Edd Barrett

http://www.theunixzoo.co.uk

FAQ entry for vmm

[Edd Barrett]

f # update kernel setting to: kernel "/vms/my_vm/bsd"
+
+
+
+Finally, we can restart the VM and it should boot multi-user.
+Note that the guest's ID will have changed.
+
+
+# vmctl reload # XXX better way? How to start a single VM defined in vm.conf?
+# vmctl status
+   ID   PID VCPUSMAXMEMCURMEM  TTY NAME
+2 73539 1 512MB  91MB   /dev/ttyp7 my_vm
+# vmctl console 2
+
+
+Hit enter:
+
+
+OpenBSD/amd64 (foo.bar) (tty00)
+
+login:
+
+
+Using vmm(4) when the host uses wireless networking
+
+
+Unfortunately, the setup described in the previous section would not have
+worked if the host's wired re0 interface had been a wireless 
interface.
+Due to a limitation of the ieee802.11 standard, wireless interfaces can not
+participate in network bridges.
+To work around this, we can give the guest VM its own network and use network
+address translation (NAT) to the host's network, but the upshot is we can no
+longer use the host network's DHCP server.
+We would need to either use static addresses, or our own DHCP server.
+Here we demonstrate the latter option.
+
+
+Suppose that we have a host machine with internet access via a wireless
+iwn0 interface on the 192.168.1.0/24 network, and that we
+want to install an OpenBSD guest which will get an IP address via our own DHCP
+server on the 192.168.10.0/24 network.
+The guest will access the internet via a NAT between the two networks and
+let's assume we are using the same kernel and disk image paths as before.
+
+
+Although we could run the DHCP server directly on the VM's
+http://man.openbsd.org/tap;>tap(4)
+interface, this is awkward, as the interface will come and go as the guest VM
+comes up and down.
+Instead, we can use an always-existing
+http://man.openbsd.org/vether;vether(4) interface and
+serve up DHCP there, later ensuring that this interface gets bridged to the
+VM's http://man.openbsd.org/tap;tap(4) interface.
+
+
+Let's make a vether0 interface:
+
+
+# echo "inet 192.168.10.1 255.255.255.0" > /etc/hostname.vether0
+# sh /etc/netstart vether0
+
+
+
+Next, put the following in /etc/dhcpd.conf:
+
+
+subnet 192.168.10.0 netmask 255.255.255.0 {
+option routers 192.168.10.1;
+option domain-name-servers 192.168.1.1;
+option domain-name "home";
+range 192.168.10.2 192.168.10.10;
+}
+
+
+
+And start the DHCP server, being careful to serve up DHCP on only
+vether0:
+
+
+# echo "dhcpd_flags=vether0" >> /etc/rc.conf.local
+# rcctl enable dhcpd
+# rcctl start dhcpd
+
+
+
+We need to add a http://man.openbsd.org/pf;pf(4) rule to
+do the NATting.
+Put in the correct place in /etc/pf.conf:
+
+
+match out on iwn0 inet from vether0:network to any nat-to (iwn0)
+
+
+
+And to finish off the NAT configuration:
+
+
+# pfctl -f /etc/pf.conf
+# echo "net.inet.ip.forwarding=1" >> /etc/sysctl.conf
+# sysctl net.inet.ip.forwarding=1
+net.inet.ip.forwarding: 0 -> 1
+
+
+
+Now the following
+http://man.openbsd.org/vm.conf;vm.conf(5)
+should work:
+
+
+switch "my_switch" {
+add vether0
+interface bridge0
+}
+
+vm "my_vm" {
+memory 512M
+disk "/vms/my_vm/disk.img"
+kernel "/vms/my_vm/bsd.rd"
+interface tap { switch "my_switch" }
+}
+
+
+
+Be aware that if you move the host machine between networks, (e.g. you take
+your laptop from your home to your work) you will have to update the DHCP
+server configuration to offer up the correct DNS server and router addresses.
+
 
 
Index: faq/index.html
===
RCS file: /home/edd/cvsync/www/faq/index.html,v
retrieving revision 1.495
diff -u -p -r1.495 index.html
--- faq/index.html  2 Oct 2016 21:16:26 -   1.495
+++ faq/index.html  15 Oct 2016 16:08:48 -
@@ -151,6 +151,7 @@ that are not covered in the FAQ.
 Using S/Key
 Directory services
 Keeping OpenBSD up to date
+Virtual machines with vmm(4)
 
 
 The X Window System

-- 
Best Regards
Edd Barrett

http://www.theunixzoo.co.uk

Re: vmm: experimentation with networking on wifi interfaces

[Edd Barrett]

Hi,

On Fri, Oct 14, 2016 at 12:56:09AM +0200, Reyk Floeter wrote:
> Using vether in a bridge with the tap allows you to preconfigure a
> fixed interface on the host that doesn't depend on the vm state.

Ah. Yes, and this actually fixes the quirks I mentioned. Using tap
directly is actually *more* complicated.

> I will also add an option for setting the switch in vmctl start.

Thanks

> Now go ahead and configure vether0 as you configure tap0 below... I'm
> usually running dhcpd on vether0, but you can also use fixed IPs of
> course.

Yep, this just worked. Thanks for your help.

You just have to remember to change the DNS server addresses if you move
the host machine between different networks (in /etc/resolv.conf for a
static IP guest, or in the host DHCP server if the guest uses DHCP).

(At some point I'm going to start making an FAQ entry covering the
common vmm cases.)

-- 
Best Regards
Edd Barrett

http://www.theunixzoo.co.uk

vmm: experimentation with networking on wifi interfaces

[Edd Barrett]

Hey,

As we saw earlier on misc@, getting a vmm host on the internet when the
host is using a wireless interface is not as straightforward as with
wired interfaces.

Specifically, a bridge won't work on a wireless interface, which in turn (I
think) means virtual switches don't work either (although I did not try
that).

Some mentioned that it's possible to use a nat with a vether bridge.

Striving for a simpler working setup, after some thinking, and a
discussion with mlarkin@, I decided to find out:

 1) If you really need the vether interface in the equation.
 2) If you could use dhcpd on the tap interface of a vm.

Mike asked me to write to tech@ reporting the outcome of 2.

Starting with 1, if all you want is to get a VM on the internet, you
don't need a vether.

On the host:
---8<---
# ifconfig tap0 192.168.10.1
# echo "pass out on iwn0 inet from tap0:network to any nat-to (iwn0)" >> 
/etc/pf.conf
# pfctl -f /etc/pf.conf
# sysctl net.inet.ip.forwarding=1
--->8---

On the guest:

---8<---
# ifconfig vio 192.168.10.2
# route add default 192.168.10.1
--->8---

(Or enter those parameters into the installer)

And you are good to go. I managed to install a guest via this method.

There are a couple of quirks though. First, you can't boot with that line in
pf.conf, as pf comes up before vmd, so the tap interface will not exist as pf
starts, causing pf to not parse its config file. Second, if you halt/reboot the
guest (I notice reboot actually halts), then the tap interface is deleted and
the IP is lost. If you want to bring the host back up, you need to set the IP
on the tap device again.

As for 2, DHCP over tap, this did not work for me.

On the host, in dhcpd.conf:

---8<---
subnet 192.168.10.0 netmask 255.255.255.0 {
option routers 192.168.1.1;
option domain-name-servers 192.168.1.1;
option domain-name "home";
range 192.168.10.2 192.168.10.10;
}
--->8---

Start with: doas dhcpd -df -c /etc/dhcpd.conf tap0

Then in the guest:

---8<---
Listening on tap0 (192.168.10.1).
DHCPDISCOVER from fe:e1:ba:d0:95:d1 via tap0
DHCPDISCOVER from fe:e1:ba:d0:95:d1 via tap0
already acking lease 192.168.10.2
DHCPDISCOVER from fe:e1:ba:d0:95:d1 via tap0
already acking lease 192.168.10.2
DHCPDISCOVER from fe:e1:ba:d0:95:d1 via tap0
already acking lease 192.168.10.2
DHCPDISCOVER from fe:e1:ba:d0:95:d1 via tap0
already acking lease 192.168.10.2
DHCPDISCOVER from fe:e1:ba:d0:95:d1 via tap0
already acking lease 192.168.10.2
DHCPDISCOVER from fe:e1:ba:d0:95:d1 via tap0
already acking lease 192.168.10.2
...
already acking lease 192.168.10.2
DHCPOFFER on 192.168.10.2 to fe:e1:ba:d0:95:d1 via tap0
DHCPDISCOVER from fe:e1:ba:d0:95:d1 via tap0
DHCPOFFER on 192.168.10.2 to fe:e1:ba:d0:95:d1 via tap0
DHCPDISCOVER from fe:e1:ba:d0:95:d1 via tap0
DHCPOFFER on 192.168.10.2 to fe:e1:ba:d0:95:d1 via tap0
--->8---

The guest at this point is saying:

---8<---
# dhcpd -df -c /etc/dhcpd.conf tap0
DHCPDISCOVER on vio0 - interval 3
DHCPDISCOVER on vio0 - interval 8
DHCPDISCOVER on vio0 - interval 14
...
--->8---

An address is never acquired.

When I tried once more:

---8<---
# dhcpd -df -c /etc/dhcpd.conf tap0
Listening on tap0 (192.168.10.1).
DHCPDISCOVER from fe:e1:ba:d0:95:d1 via tap0
DHCPOFFER on 192.168.10.2 to fe:e1:ba:d0:95:d1 via tap0
DHCPDISCOVER from fe:e1:ba:d0:95:d1 via tap0
DHCPOFFER on 192.168.10.2 to fe:e1:ba:d0:95:d1 via tap0
DHCPDISCOVER from fe:e1:ba:d0:95:d1 via tap0
DHCPOFFER on 192.168.10.2 to fe:e1:ba:d0:95:d1 via tap0
DHCPDISCOVER from fe:e1:ba:d0:95:d1 via tap0
DHCPOFFER on 192.168.10.2 to fe:e1:ba:d0:95:d1 via tap0
DHCPDISCOVER from fe:e1:ba:d0:95:d1 via tap0
DHCPOFFER on 192.168.10.2 to fe:e1:ba:d0:95:d1 via tap0
...
--->8---

When I ran dhclient in the guest this time:

---8<---
# dhclient vio0   
DHCPDISCOVER on vio0 - interval 3
panic: kernel diagnostic assertion "m != NULL" failed: file 
"../../../../dev/pci/if_vio.c", line 1008
Stopped at  Debugger+0x9:   leave
   TIDPIDUID PRFLAGS PFLAGS  CPU  COMMAND
*45447  45447 770x100013  00  dhclient
Debugger() at Debugger+0x9
panic() at panic+0xfe
__assert() at __assert+0x25
vio_rxeof() at vio_rxeof+0x1db
vio_rx_intr() at vio_rx_intr+0x28
virtio_check_vqs() at virtio_check_vqs+0x8c
virtio_pci_legacy_intr() at virtio_pci_legacy_intr+0x6b
intr_handler() at intr_handler+0x28
Xintr_legacy7() at Xintr_legacy7+0xdd
--- interrupt ---
Xspllower() at Xspllower+0xc
if_enqueue() at if_enqueue+0x69
ether_output() at ether_output+0x1b0
bpfwrite() at bpfwrite+0x153
spec_write() at spec_write+0xb5
end trace frame: 0x8e3a8c60, count: 0
http://www.openbsd.org/ddb.html describes the minimum info required in bug
reports.  Insufficient info makes it difficult to find and fix bugs.
--->8---

Oops. Well, please don't take that as a bug report, as the guest is running
vanilla 6.0-release. If someone wants more info, I can mail it, but

Re: removing wsmouse_input [2]: zts, hilms, uts

[Edd Barrett]

On Mon, Jun 06, 2016 at 01:53:01PM +0200, Stefan Sperling wrote:
> On Mon, Jun 06, 2016 at 12:40:24PM +0100, Edd Barrett wrote:
> > I have a uts.
> > 
> > I can test later. Am I expecting to see any functional change?
> 
> No change is expected. It should just work.

Ah, my apologies, my touchscreen is attaching to ums.

ums2 at uhidev4 reportid 2: 3 buttons, tip, barrel, eraser
wsmouse3 at ums2 mux 0


P.S.

Please feel free to CC me if there is any touch-screen related diffs
that I could test with my touchscreen. Although I have a touch-screen,
and despite a bit of hacking a few years back to get it working at all,
the support is still not good, and thus I have barely used it.

My touch-screen has issues with suspend:
http://marc.info/?l=openbsd-bugs=146504820529987=2

And we currently do not correctly transpose X co-ordinates when randr is
used to rotate the screen.

Cheers

-- 
Best Regards
Edd Barrett

http://www.theunixzoo.co.uk

Re: removing wsmouse_input [2]: zts, hilms, uts

[Edd Barrett]

I have a uts.

I can test later. Am I expecting to see any functional change?



On 5 June 2016 15:55:19 BST, Mark Kettenis  wrote:
>> From: Ulf Brosziewski 
>> Date: Sun, 5 Jun 2016 09:55:07 +0200
>> 
>> ok?
>
>Would have been nice if somebody with zts(4) or uts(4) would have
>tested this, but we have to move forwards.
>
>ok kettenis@
>
>> On 06/01/2016 01:23 AM, Ulf Brosziewski wrote:
>> > zts, hilms, and uts are the drivers that still use wsmouse_input
>> > with absolute coordinates (or with both types of coordinates).
>> > The new, "flag-less" interface of wsmouse requires calls of
>> > wsmouse_position, and, possibly, of wsmouse_touch in this case.
>> > 
>> > Questions, tests and OKs would be welcome.
>> > 
>> > 
>> > Index: arch/zaurus/dev/zts.c
>> > ===
>> > RCS file: /cvs/src/sys/arch/zaurus/dev/zts.c,v
>> > retrieving revision 1.16
>> > diff -u -p -r1.16 zts.c
>> > --- arch/zaurus/dev/zts.c  29 Mar 2014 18:09:30 -  1.16
>> > +++ arch/zaurus/dev/zts.c  31 May 2016 19:23:10 -
>> > @@ -544,10 +544,9 @@ zts_irq(void *v)
>> >DPRINTF(("%s: tp.z = %d, tp.x = %d, tp.y = %d\n",
>> >sc->sc_dev.dv_xname, tp.z, tp.x, tp.y));
>> >  
>> > -  wsmouse_input(sc->sc_wsmousedev, down, tp.x, tp.y,
>> > -  0 /* z */, 0 /* w */,
>> > -  WSMOUSE_INPUT_ABSOLUTE_X | WSMOUSE_INPUT_ABSOLUTE_Y |
>> > -  WSMOUSE_INPUT_ABSOLUTE_Z);
>> > +  wsmouse_buttons(sc->sc_wsmousedev, down);
>> > +  wsmouse_position(sc->sc_wsmousedev, tp.x, tp.y);
>> > +  wsmouse_input_sync(sc->sc_wsmousedev);
>> >sc->sc_buttons = down;
>> >sc->sc_oldx = tp.x;
>> >sc->sc_oldy = tp.y;
>> > Index: dev/hil/hilms.c
>> > ===
>> > RCS file: /cvs/src/sys/dev/hil/hilms.c,v
>> > retrieving revision 1.5
>> > diff -u -p -r1.5 hilms.c
>> > --- dev/hil/hilms.c10 Apr 2007 22:37:17 -  1.5
>> > +++ dev/hil/hilms.c31 May 2016 19:23:10 -
>> > @@ -219,7 +219,7 @@ void
>> >  hilms_callback(struct hildev_softc *dev, u_int buflen, u_int8_t
>*buf)
>> >  {
>> >struct hilms_softc *sc = (struct hilms_softc *)dev;
>> > -  int type, flags;
>> > +  int type;
>> >int dx, dy, dz, button;
>> >  #ifdef DIAGNOSTIC
>> >int minlen;
>> > @@ -256,9 +256,6 @@ hilms_callback(struct hildev_softc *dev,
>> > */
>> >  
>> >if (type & HIL_MOUSEMOTION) {
>> > -  flags = sc->sc_features & HIL_ABSOLUTE ?
>> > -  WSMOUSE_INPUT_ABSOLUTE_X | WSMOUSE_INPUT_ABSOLUTE_Y |
>> > -  WSMOUSE_INPUT_ABSOLUTE_Z : WSMOUSE_INPUT_DELTA;
>> >if (sc->sc_features & HIL_16_BITS) {
>> >dx = *buf++;
>> >dx |= (*buf++) << 8;
>> > @@ -302,8 +299,7 @@ hilms_callback(struct hildev_softc *dev,
>> >if ((sc->sc_features & HIL_ABSOLUTE) == 0 &&
>> >sc->sc_buttons == 0)
>> >dy = -dy;
>> > -  } else
>> > -  dx = dy = dz = flags = 0;
>> > +  }
>> >  
>> >if (type & HIL_MOUSEBUTTON) {
>> >button = *buf;
>> > @@ -332,7 +328,18 @@ hilms_callback(struct hildev_softc *dev,
>> >/* buf++; */
>> >}
>> >
>> > -  if (sc->sc_wsmousedev != NULL)
>> > -  wsmouse_input(sc->sc_wsmousedev,
>> > -  sc->sc_buttonstate, dx, dy, dz, 0, flags);
>> > +  if (sc->sc_wsmousedev == NULL)
>> > +  return;
>> > +
>> > +  wsmouse_buttons(sc->sc_wsmousedev, sc->sc_buttonstate);
>> > +  if (type & HIL_MOUSEMOTION) {
>> > +  if ((sc->sc_features & HIL_ABSOLUTE) == 0) {
>> > +  wsmouse_motion(sc->sc_wsmousedev, dx, dy, dz, 0);
>> > +  } else {
>> > +  wsmouse_position(sc->sc_wsmousedev, dx, dy);
>> > +  if (sc->sc_axes > 2)
>> > +  wsmouse_touch(sc->sc_wsmousedev, dz, 0);
>> > +  }
>> > +  }
>> > +  wsmouse_input_sync(sc->sc_wsmousedev);
>> >  }
>> > Index: dev/usb/uts.c
>> > ===
>> > RCS file: /cvs/src/sys/dev/usb/uts.c,v
>> > retrieving revision 1.37
>> > diff -u -p -r1.37 uts.c
>> > --- dev/usb/uts.c  10 Feb 2016 05:49:50 -  1.37
>> > +++ dev/usb/uts.c  31 May 2016 19:23:12 -
>> > @@ -476,9 +476,7 @@ uts_intr(struct usbd_xfer *xfer, void *a
>> >DPRINTF(("%s: tp.down = %d, tp.z = %d, tp.x = %d, tp.y = %d\n",
>> >sc->sc_dev.dv_xname, tp.down, tp.z, tp.x, tp.y));
>> >  
>> > -  wsmouse_input(sc->sc_wsmousedev, tp.down, tp.x, tp.y, tp.z, 0,
>> > -  WSMOUSE_INPUT_ABSOLUTE_X | WSMOUSE_INPUT_ABSOLUTE_Y |
>> > -  WSMOUSE_INPUT_ABSOLUTE_Z);
>> > +  WSMOUSE_TOUCH(sc->sc_wsmousedev, tp.down, tp.x, tp.y, tp.z, 0);
>> >sc->sc_oldy = tp.y;
>> >sc->sc_oldx = tp.x;
>> >  
>> > 
>> > 
>> 
>> 

-- 
Sent from my Android 

schizo0: safari error

[Edd Barrett]

schizo_bus_map: type 1 off 400 sz 100 
flags 0 cspace 1: ivec 0x219schizo_bus_map: type 2 off 12a000 sz 1000 flags 0 
cspace 2, using 4K of on-board RAM
scsibus2 at siop1: 16 targets, initiator 7
usb0 at ohci0: USB revision 1.0
uhub0 at usb0 "Sun OHCI root hub" rev 1.00/1.00 addr 1
schizo1 at mainbus0: "Schizo", version 4, ign 200, bus A 0 to 0
schizo1: schizo_iommu_init: getprop failed, using iobase=0x, tsbsize=7
dvma map c000-
schizo_bus_map: type 0 off 0 sz 100 flags 0 cspace 0pci1 at schizo1
qla0 at pci1 dev 4 function 0 "QLogic ISP2200" rev 0x05schizo_bus_map: type 2 
off 10 sz 1000 flags 0 cspace 2: ivec 0x204
qla0: firmware rev 2.2.6, attrs 0x7
scsibus3 at qla0: 256 targets, WWPN 2103ba100e6a, WWNN 2003ba100e6a
sym0 at scsibus3 targ 1 lun 0: <SEAGATE, ST3146707FC, 0003> SCSI3 0/direct 
fixed naa.2014c303de67
sd0 at scsibus0 targ 0 lun 0: <SEAGATE, ST3146707FC, 0003> SCSI3 0/direct fixed 
naa.2014c303de67
sd0: 140014MB, 512 bytes/sector, 286749488 sectors
sym1 at scsibus3 targ 2 lun 0: <SEAGATE, ST3146807FC, 0006> SCSI3 0/direct 
fixed naa.2018623c7bd4
sd1 at scsibus0 targ 1 lun 0: <SEAGATE, ST3146807FC, 0006> SCSI3 0/direct fixed 
naa.2018623c7bd4
sd1: 140014MB, 512 bytes/sector, 286749488 sectors
upa0 at mainbus0
creator0 at upa0: Elite3D, model SUNW,540-3623, dac 0, 1280x1024
wsdisplay0 at creator0 mux 1: console (std, sun emulation)
"ppm" at mainbus0 not configured
uhidev0 at uhub0 port 4 configuration 1 interface 0 "Fujitsu Component Type 6 
Keyboard" rev 1.00/1.01 addr 2
uhidev0: iclass 3/1
ukbd0 at uhidev0: 8 variable keys, 6 key codes, country code 32
wskbd0 at ukbd0: console keyboard, using wsdisplay0
vscsi0 at root
scsibus4 at vscsi0: 256 targets
softraid0 at root
scsibus5 at softraid0: 256 targets
bootpath: /pci@8,60/SUNW,qlc@4,0/fp@0,0/disk@2114c303de67,0
root on sd0a (8d7ec6f394d57510.a) swap on sd0b dump on sd0b
creator0: firmware rev 1.3.11

-- 
Best Regards
Edd Barrett

http://www.theunixzoo.co.uk

Re: Allow top(1) to search arguments (again)

[Edd Barrett]

On Wed, May 11, 2016 at 02:28:51PM +0200, Michal Mazurek wrote:
> As discussed off list, "if (!term)" is redundant, as the caller does the
> check.
> 
> Also fix whitespace in some unrelated places.

Can you split out the "term" change from style changes?

You can do a KNF whack in a separate commit (later).

-- 
Best Regards
Edd Barrett

http://www.theunixzoo.co.uk

Re: Allow top(1) to search arguments (again)

[Edd Barrett]

On Thu, Apr 28, 2016 at 03:26:48PM +0100, Edd Barrett wrote:
> Resubmitting this diff, as I've been unable to get an OK.

Style tweaks fixed, as pointed out by Michal Mazurek. Thanks for this.

OK?

Index: machine.c
===
RCS file: /home/edd/cvsync/src/usr.bin/top/machine.c,v
retrieving revision 1.85
diff -u -p -r1.85 machine.c
--- machine.c   20 Aug 2015 22:32:42 -  1.85
+++ machine.c   4 May 2016 22:09:32 -
@@ -57,6 +57,8 @@
 static int swapmode(int *, int *);
 static char*state_abbr(struct kinfo_proc *);
 static char*format_comm(struct kinfo_proc *);
+static int cmd_matches(struct kinfo_proc *, char *);
+static char**get_proc_args(struct kinfo_proc *);
 
 /* get_process_info passes back a handle.  This is what it looks like: */
 
@@ -360,6 +362,60 @@ getprocs(int op, int arg, int *cnt)
return (procbase);
 }
 
+static char **
+get_proc_args(struct kinfo_proc *kp)
+{
+   static char **s;
+   size_t  siz = 100;
+   int mib[4];
+
+   for (;; siz *= 2) {
+   if ((s = realloc(s, siz)) == NULL)
+   err(1, NULL);
+   mib[0] = CTL_KERN;
+   mib[1] = KERN_PROC_ARGS;
+   mib[2] = kp->p_pid;
+   mib[3] = KERN_PROC_ARGV;
+   if (sysctl(mib, 4, s, , NULL, 0) == 0)
+   break;
+   if (errno != ENOMEM)
+   return NULL;
+   }
+   return s;
+}
+
+static int
+cmd_matches(struct kinfo_proc *proc, char *term)
+{
+   extern int  show_args;
+   char**args = NULL;
+
+   if (!term) {
+   /* No command filter set */
+   return 1;
+   } else {
+   /* Filter set, process name needs to contain term */
+   if (strstr(proc->p_comm, term))
+   return 1;
+   /* If showing arguments, search those as well */
+   if (show_args) {
+   args = get_proc_args(proc);
+
+   if (args == NULL) {
+   /* Failed to get args, so can't search them */
+   return 0;
+   }
+
+   while (*args != NULL) {
+   if (strstr(*args, term))
+   return 1;
+   args++;
+   }
+   }
+   }
+   return 0;
+}
+
 caddr_t
 get_process_info(struct system_info *si, struct process_select *sel,
 int (*compare) (const void *, const void *))
@@ -421,8 +477,7 @@ get_process_info(struct system_info *si,
(!hide_uid || pp->p_ruid != sel->huid) &&
(!show_uid || pp->p_ruid == sel->uid) &&
(!show_pid || pp->p_pid == sel->pid) &&
-   (!show_cmd || strstr(pp->p_comm,
-   sel->command))) {
+   (!show_cmd || cmd_matches(pp, sel->command))) {
*prefp++ = pp;
active_procs++;
}
@@ -462,27 +517,17 @@ state_abbr(struct kinfo_proc *pp)
 static char *
 format_comm(struct kinfo_proc *kp)
 {
-   static char **s, buf[MAX_COLS];
-   size_t siz = 100;
-   char **p;
-   int mib[4];
-   extern int show_args;
+   static char buf[MAX_COLS];
+   char**p, **s;
+   extern int  show_args;
 
if (!show_args)
return (kp->p_comm);
 
-   for (;; siz *= 2) {
-   if ((s = realloc(s, siz)) == NULL)
-   err(1, NULL);
-   mib[0] = CTL_KERN;
-   mib[1] = KERN_PROC_ARGS;
-   mib[2] = kp->p_pid;
-   mib[3] = KERN_PROC_ARGV;
-   if (sysctl(mib, 4, s, , NULL, 0) == 0)
-   break;
-   if (errno != ENOMEM)
-   return (kp->p_comm);
-   }
+   s = get_proc_args(kp);
+   if (s == NULL)
+   return kp->p_comm;
+
buf[0] = '\0';
for (p = s; *p != NULL; p++) {
if (p != s)
Index: top.1
===
RCS file: /home/edd/cvsync/src/usr.bin/top/top.1,v
retrieving revision 1.66
diff -u -p -r1.66 top.1
--- top.1   6 May 2015 07:53:29 -   1.66
+++ top.1   4 May 2016 22:15:10 -
@@ -108,6 +108,7 @@ The default is 1 for dumb terminals.
 Display only processes that contain
 .Ar string
 in their command name.
+If displaying of arguments is enabled, the arguments are searched too.
 .It Fl H
 Show process threads in the display.
 Normally, only the main process is shown.
@@ -306,6 +307,7 @@ command.
 Display only p

Allow top(1) to search arguments (again)

[Edd Barrett]

ile: /home/edd/cvsync/src/usr.bin/top/top.1,v
retrieving revision 1.66
diff -u -p -r1.66 top.1
--- top.1   6 May 2015 07:53:29 -   1.66
+++ top.1   6 Feb 2016 15:03:50 -
@@ -107,7 +107,8 @@ The default is 1 for dumb terminals.
 .It Fl g Ar string
 Display only processes that contain
 .Ar string
-in their command name.
+in their command name. If displaying of arguments is enabled, the
+arguments are searched too.
 .It Fl H
 Show process threads in the display.
 Normally, only the main process is shown.
@@ -305,7 +306,8 @@ command.
 .It g Ar string
 Display only processes that contain
 .Ar string
-in their command name.
+in their command name. If displaying of arguments is enabled, the
+arguments are searched too.
 .Sq g+
 shows all processes.
 .It H

-- 
Best Regards
Edd Barrett

http://www.theunixzoo.co.uk

-- 
Best Regards
Edd Barrett

http://www.theunixzoo.co.uk

Re: Scheduler hack for multi-threaded processes

[Edd Barrett]

On Thu, Mar 24, 2016 at 12:09:39PM +, Edd Barrett wrote:
> On Wed, Mar 23, 2016 at 09:35:50PM +0100, Mark Kettenis wrote:
> > So here is a diff that keeps yield() the same and adds the code in the
> > sched_yield(2) implementation instead.
> 
> I'm going to now run with this diff for a while. On first glance,
> browser performance is good. Video seems to work well in firefox.

Just to follow this up. Zero problems in the last 4 days. Good browser
experience.

I can't vouch for the code though.

-- 
Best Regards
Edd Barrett

http://www.theunixzoo.co.uk

Re: Scheduler hack for multi-threaded processes

[Edd Barrett]

On Wed, Mar 23, 2016 at 09:35:50PM +0100, Mark Kettenis wrote:
> So here is a diff that keeps yield() the same and adds the code in the
> sched_yield(2) implementation instead.

I'm going to now run with this diff for a while. On first glance,
browser performance is good. Video seems to work well in firefox.

Thanks.

-- 
Best Regards
Edd Barrett

http://www.theunixzoo.co.uk

Re: Scheduler hack for multi-threaded processes

[Edd Barrett]

On Sat, Mar 19, 2016 at 01:53:07PM +0100, Martin Pieuchot wrote:
> I experimented with various values for "p_priority" and this one is
> the one that generates fewer # IPIs when watching a HD video on firefox. 
> Because yes, with this diff, now I can.

Works well here in firefox too.

Will run this diff for a few days and let you know if anything bad
happens.

-- 
Best Regards
Edd Barrett

http://www.theunixzoo.co.uk

Re: New scheduler for OpenBSD

[Edd Barrett]

On Thu, Mar 17, 2016 at 09:26:08PM +0100, Henrik Friedrichsen wrote:
> On Tue, Mar 15, 2016 at 03:05:47PM +0100, Michal Mazurek wrote:
> > Chrome still isn't smooth.
> > 
> > Please test, and let me know if the performance of something else
> > degrades.
> 
> While Chrome may not be 100% smooth yet, the system is a lot more
> interactive. I can now play YouTube videos without stutters while doing
> other things.

I can't vouch for the code, but this makes video playback in firefox
usable on my x240t. Before it would stutter beyond belief.

I'll run with this for a while and let you know if anything comes up.

-- 
Best Regards
Edd Barrett

http://www.theunixzoo.co.uk

Re: New scheduler for OpenBSD

[Edd Barrett]

On Sat, Mar 19, 2016 at 09:06:26AM +0100, Alexandre Ratchov wrote:
> The browsers problems seem caused by the way pthreads behave;
> browsers appear to spin.  With the proposed scheduler they spin
> less.  But the real question is why they spin at all?

Inspired by this comment, I set out to see if I could find *where* the browsers
are spinning. "Just build the browsers with profiling instrumentation and look
where the time goes when playing a youtube video" I thought. "Easy" I thought.

Well no. We build our chrome and firefox with clang, which doesn't
support gprof style profiling.

Clang does have this -fprofile-instr-generate flag, which throws out some
profiling data at runtime, but it appears it is designed to be used by the
compiler itself as compile-time optimisation hints[1]. It's not even clear if
there is any timing data in there.

There's another clang profiling mode which depends upon Linux perf, which is
obviously not an option for us.

Nevertheless, I decided to try it on the off-chance that clang's profiling data
could be useful (and I'm totally accepting that, if it is, I will probably have
to write a python script to make sense of the output). Sadly I stumbled at the
first hurdle:

---8<---
$ cat a.c
#include 
#include 

int
main(int argc, char **argv)
{
return (EXIT_SUCCESS);
}
$clang -fprofile-instr-generate a.c -lclang
/usr/local/lib/libclang.so.2.0: warning: warning: sprintf() is often misused, 
please use snprintf()
/tmp/a-f91c15.o: In function `__llvm_profile_register_functions':
a.c:(.text+0x3c): undefined reference to `__llvm_profile_register_function'
/tmp/a-f91c15.o: In function `__llvm_profile_runtime_user':
a.c:(.text+0x53): undefined reference to `__llvm_profile_runtime'
clang-3.7: error: linker command failed with exit code 1 (use -v to see 
invocation)
--->8---

Any clang afficionados know what is missing here? Or is there a better way to
find the spinning code? There has to be a better way.

A potential option would be to port and use the profiling portion of [2].

[1] http://clang.llvm.org/docs/UsersManual.html#profile-guided-optimization
[2] https://github.com/gperftools/gperftools

-- 
Best Regards
Edd Barrett

http://www.theunixzoo.co.uk

Re: Allow top(1) to search arguments

[Edd Barrett]

On Fri, Feb 12, 2016 at 06:59:02PM +, Edd Barrett wrote:
> Updated diff:

I've now tested the updated diff on sparc64 and amd64 with S malloc
flags for a while. No issues.

Would anyone go as far as "OK"?

-- 
Best Regards
Edd Barrett

http://www.theunixzoo.co.uk

uplcom usb panic in amd64 snap

[Edd Barrett]

 dev 26 function 0 "Intel 7 Series USB" rev 0x04: apic 2 int 16
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 "Intel EHCI root hub" rev 2.00/1.00 addr 1
azalia0 at pci0 dev 27 function 0 "Intel 7 Series HD Audio" rev 0x04: msi
azalia0: codecs: Realtek ALC269, Intel/0x2806, using Realtek ALC269
audio0 at azalia0
ppb0 at pci0 dev 28 function 0 "Intel 7 Series PCIE" rev 0xc4: msi
pci1 at ppb0 bus 2
sdhc0 at pci1 dev 0 function 0 "Ricoh 5U822 SD/MMC" rev 0x07: apic 2 int 16
sdmmc0 at sdhc0
ppb1 at pci0 dev 28 function 1 "Intel 7 Series PCIE" rev 0xc4: msi
pci2 at ppb1 bus 3
iwn0 at pci2 dev 0 function 0 "Intel Centrino Wireless-N 2200" rev 0xc4: msi, 
MIMO 2T2R, BGN, address 9c:4e:36:b8:f8:f8
ppb2 at pci0 dev 28 function 2 "Intel 7 Series PCIE" rev 0xc4: msi
pci3 at ppb2 bus 4
ehci1 at pci0 dev 29 function 0 "Intel 7 Series USB" rev 0x04: apic 2 int 23
usb1 at ehci1: USB revision 2.0
uhub1 at usb1 "Intel EHCI root hub" rev 2.00/1.00 addr 1
pcib0 at pci0 dev 31 function 0 "Intel QM77 LPC" rev 0x04
ahci0 at pci0 dev 31 function 2 "Intel 7 Series AHCI" rev 0x04: msi, AHCI 1.3
ahci0: port 0: 6.0Gb/s
ahci0: port 1: 1.5Gb/s
scsibus1 at ahci0: 32 targets
sd0 at scsibus1 targ 0 lun 0: <ATA, Crucial_CT240M50, MU02> SCSI3 0/direct 
fixed naa.500a0751093c44b5
sd0: 228936MB, 512 bytes/sector, 468862128 sectors, thin
cd0 at scsibus1 targ 1 lun 0: <MATSHITA, DVD-RAM UJ8C2, SB01> ATAPI 5/cdrom 
removable
ichiic0 at pci0 dev 31 function 3 "Intel 7 Series SMBus" rev 0x04: apic 2 int 18
iic0 at ichiic0
spdmem0 at iic0 addr 0x50: 8GB DDR3 SDRAM PC3-12800 SO-DIMM
spdmem1 at iic0 addr 0x51: 8GB DDR3 SDRAM PC3-12800 SO-DIMM
isa0 at pcib0
isadma0 at isa0
pckbc0 at isa0 port 0x60/5 irq 1 irq 12
pckbd0 at pckbc0 (kbd slot)
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pms0 at pckbc0 (aux slot)
wsmouse0 at pms0 mux 0
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
uhub2 at uhub0 port 1 "Intel Rate Matching Hub" rev 2.00/0.00 addr 2
uhidev0 at uhub2 port 2 configuration 1 interface 0 "Logitech USB Receiver" rev 
2.00/12.01 addr 3
uhidev0: iclass 3/1
ukbd0 at uhidev0: 8 variable keys, 6 key codes
wskbd1 at ukbd0 mux 1
wskbd1: connecting to wsdisplay0
uhidev1 at uhub2 port 2 configuration 1 interface 1 "Logitech USB Receiver" rev 
2.00/12.01 addr 3
uhidev1: iclass 3/1, 8 report ids
ums0 at uhidev1 reportid 2: 16 buttons, Z and W dir
wsmouse1 at ums0 mux 0
uhid0 at uhidev1 reportid 3: input=4, output=0, feature=0
uhid1 at uhidev1 reportid 4: input=1, output=0, feature=0
uhid2 at uhidev1 reportid 8: input=1, output=0, feature=0
uhidev2 at uhub2 port 2 configuration 1 interface 2 "Logitech USB Receiver" rev 
2.00/12.01 addr 3
uhidev2: iclass 3/0, 33 report ids
uhid3 at uhidev2 reportid 16: input=6, output=6, feature=0
uhid4 at uhidev2 reportid 17: input=19, output=19, feature=0
uhid5 at uhidev2 reportid 32: input=14, output=14, feature=0
uhid6 at uhidev2 reportid 33: input=31, output=31, feature=0
ugen0 at uhub2 port 4 "Broadcom Corp BCM20702A0" rev 2.00/1.12 addr 4
uvideo0 at uhub2 port 6 configuration 1 interface 0 "Chicony Electronics Co., 
Ltd. Integrated Camera" rev 2.00/5.20 addr 5
video0 at uvideo0
uhub3 at uhub1 port 1 "Intel Rate Matching Hub" rev 2.00/0.00 addr 2
uplcom0 at uhub3 port 2 "Prolific Technology PL2303 Serial" rev 1.10/2.02 addr 3
ucom0 at uplcom0
uhub4 at uhub3 port 3 "Standard Microsystems product 0x2514" rev 2.00/0.00 addr 
4
uhidev3 at uhub4 port 1 configuration 1 interface 0 "SEJIN SEJIN USB joint 
Keyboard" rev 1.10/1.30 addr 5
uhidev3: iclass 3/1
ukbd1 at uhidev3: 8 variable keys, 6 key codes
wskbd2 at ukbd1 mux 1
wskbd2: connecting to wsdisplay0
uhidev4 at uhub3 port 5 configuration 1 interface 0 "Tablet ISD-V4" rev 
1.10/6.11 addr 6
uhidev4: iclass 3/1, 2 report ids
ums1 at uhidev4 reportid 1: 2 buttons
wsmouse2 at ums1 mux 0
ums2 at uhidev4 reportid 2: 3 buttons, tip, barrel, eraser
wsmouse3 at ums2 mux 0
vscsi0 at root
scsibus2 at vscsi0: 256 targets
softraid0 at root
scsibus3 at softraid0: 256 targets
root on sd0a (a81068940d057f4c.a) swap on sd0b dump on sd0b
--->8---

-- 
Best Regards
Edd Barrett

http://www.theunixzoo.co.uk

Re: diff(1) performance

[Edd Barrett]

On Sat, Feb 13, 2016 at 01:27:01PM -0700, Todd C. Miller wrote:
> GNU diff uses a superior (more modern) algorithm.  Changing that
> means rewriting the guts of diff(1).  The GNU diff code includes
> references to papers describing the algorithm.

Right. A task for a rainy day then.

Cheers

-- 
Best Regards
Edd Barrett

http://www.theunixzoo.co.uk

Revisiting the HDMI2 bug with i915 and docking stations.

[Edd Barrett]

tached
uhid2 detached
uhidev1 detached
uhid3 detached
uhid4 detached
uhid5 detached
uhid6 detached
uhidev2 detached
ugen0 detached
video0 detached
uvideo0 detached
uhub2 detached
uhub0 detached
wskbd2: disconnecting from wsdisplay0
wskbd2 detached
ukbd1 detached
uhidev4 detached
uhub4 detached
wsmouse2 detached
ums1 detached
wsmouse3 detached
ums2 detached
uhidev3 detached
uhub3 detached
uhub1 detached
uhub0 at usb0 "Intel EHCI root hub" rev 2.00/1.00 addr 1
uhub1 at usb1 "Intel EHCI root hub" rev 2.00/1.00 addr 1
uhub2 at uhub0 port 1 "Intel Rate Matching Hub" rev 2.00/0.00 addr 2
uhidev0 at uhub2 port 2 configuration 1 interface 0 "Logitech USB Receiver" rev 
2.00/12.01 addr 3
uhidev0: iclass 3/1
ukbd0 at uhidev0: 8 variable keys, 6 key codes
wskbd1 at ukbd0 mux 1
wskbd1: connecting to wsdisplay0
uhidev1 at uhub2 port 2 configuration 1 interface 1 "Logitech USB Receiver" rev 
2.00/12.01 addr 3
uhidev1: iclass 3/1, 8 report ids
ums0 at uhidev1 reportid 2: 16 buttons, Z and W dir
wsmouse1 at ums0 mux 0
uhid0 at uhidev1 reportid 3: input=4, output=0, feature=0
uhid1 at uhidev1 reportid 4: input=1, output=0, feature=0
uhid2 at uhidev1 reportid 8: input=1, output=0, feature=0
uhidev2 at uhub2 port 2 configuration 1 interface 2 "Logitech USB Receiver" rev 
2.00/12.01 addr 3
uhidev2: iclass 3/0, 33 report ids
uhid3 at uhidev2 reportid 16: input=6, output=6, feature=0
uhid4 at uhidev2 reportid 17: input=19, output=19, feature=0
uhid5 at uhidev2 reportid 32: input=14, output=14, feature=0
uhid6 at uhidev2 reportid 33: input=31, output=31, feature=0
ugen0 at uhub2 port 4 "Broadcom Corp BCM20702A0" rev 2.00/1.12 addr 4
uvideo0 at uhub2 port 6 configuration 1 interface 0 "Chicony Electronics Co., 
Ltd. Integrated Camera" rev 2.00/5.20 addr 5
video0 at uvideo0
uhub3 at uhub1 port 1 "Intel Rate Matching Hub" rev 2.00/0.00 addr 2
uhub4 at uhub3 port 3 "Standard Microsystems product 0x2514" rev 2.00/0.00 addr 
3
uhidev3 at uhub3 port 5 configuration 1 interface 0 "Tablet ISD-V4" rev 
1.10/6.11 addr 4
uhidev3: iclass 3/1, 2 report ids
ums1 at uhidev3 reportid 1: 2 buttons
wsmouse2 at ums1 mux 0
ums2 at uhidev3 reportid 2: 3 buttons, tip, barrel, eraser
wsmouse3 at ums2 mux 0
uhidev4 at uhub4 port 4 configuration 1 interface 0 "SEJIN SEJIN USB joint 
Keyboard" rev 1.10/1.30 addr 5
uhidev4: iclass 3/1
ukbd1 at uhidev4: 8 variable keys, 6 key codes
wskbd2 at ukbd1 mux 1
wskbd2: connecting to wsdisplay0

-- 
Best Regards
Edd Barrett

http://www.theunixzoo.co.uk

diff(1) performance

[Edd Barrett]

Hey,

I've not looked into this at all, but looks like diff(1) could be
optimised:

# With GNU diff:
$ time gdiff -u file1 file2 > out-gdiff
gdiff -u file1 file2 > out-gdiff  0.16s user 0.13s system 101% cpu 0.286 total

# With OpenBSD diff:
$ time diff -u file1 file2 > out-bdiff 
diff -u file1 file2 > out-bdiff  1005.24s user 0.33s system 99% cpu 16:46.44 
total

Admittedly the files are big (~10MB each), but still.

Good news is, the outcomes are the same bar the diff header syntax:

---8<---
$ gdiff -u out-bdiff out-gdiff 
--- out-bdiff   2016-02-13 18:15:42.991267362 +
+++ out-gdiff   2016-02-13 17:58:47.153912520 +
@@ -1,5 +1,5 @@
 file1  Wed Feb  4 13:20:14 2015
-+++ file2  Wed Feb  4 13:20:14 2015
+--- file1  2015-02-04 13:20:14.899249552 +
 file2  2015-02-04 13:20:14.859249471 +
 @@ -62,7 +62,7 @@
  TaskState::packetPending: 
  HandlerTask::fn: 
--->8---

Tarred up files: http://theunixzoo.co.uk/random/diff_files.tgz

-- 
Best Regards
Edd Barrett

http://www.theunixzoo.co.uk

Re: Allow top(1) to search arguments

[Edd Barrett]

It Fl H
 Show process threads in the display.
 Normally, only the main process is shown.
@@ -305,7 +306,8 @@ command.
 .It g Ar string
 Display only processes that contain
 .Ar string
-in their command name.
+in their command name. If displaying of arguments is enabled, the
+arguments are searched too.
 .Sq g+
 shows all processes.
 .It H

-- 
Best Regards
Edd Barrett

http://www.theunixzoo.co.uk

Allow top(1) to search arguments

[Edd Barrett]

mmand name.
+in their command name. If displaying of arguments is enabled, the
+arguments are searched too.
 .It Fl H
 Show process threads in the display.
 Normally, only the main process is shown.
@@ -305,7 +306,8 @@ command.
 .It g Ar string
 Display only processes that contain
 .Ar string
-in their command name.
+in their command name. If displaying of arguments is enabled, the
+arguments are searched too.
 .Sq g+
 shows all processes.
 .It H

-- 
Best Regards
Edd Barrett

http://www.theunixzoo.co.uk

Re: Firefox, malloc(3) and threads

[Edd Barrett]

 at uhidev1 reportid 3: input=4, output=0, feature=0
uhid1 at uhidev1 reportid 4: input=1, output=0, feature=0
uhid2 at uhidev1 reportid 8: input=1, output=0, feature=0
uhidev2 at uhub2 port 2 configuration 1 interface 2 "Logitech USB Receiver" rev 
2.00/12.01 addr 3
uhidev2: iclass 3/0, 33 report ids
uhid3 at uhidev2 reportid 16: input=6, output=6, feature=0
uhid4 at uhidev2 reportid 17: input=19, output=19, feature=0
uhid5 at uhidev2 reportid 32: input=14, output=14, feature=0
uhid6 at uhidev2 reportid 33: input=31, output=31, feature=0
ugen0 at uhub2 port 4 "Broadcom Corp BCM20702A0" rev 2.00/1.12 addr 4
uvideo0 at uhub2 port 6 configuration 1 interface 0 "Chicony Electronics Co., 
Ltd. Integrated Camera" rev 2.00/5.20 addr 5
video0 at uvideo0
uhub3 at uhub1 port 1 "Intel Rate Matching Hub" rev 2.00/0.00 addr 2
uhub4 at uhub3 port 3 "Standard Microsystems product 0x2514" rev 2.00/0.00 addr 
3
uhidev3 at uhub3 port 5 configuration 1 interface 0 "Tablet ISD-V4" rev 
1.10/6.11 addr 4
uhidev3: iclass 3/1, 2 report ids
ums1 at uhidev3 reportid 1: 2 buttons
wsmouse2 at ums1 mux 0
ums2 at uhidev3 reportid 2: 3 buttons, tip, barrel, eraser
wsmouse3 at ums2 mux 0
uhidev4 at uhub4 port 4 configuration 1 interface 0 "SEJIN SEJIN USB joint 
Keyboard" rev 1.10/1.30 addr 5
uhidev4: iclass 3/1
ukbd1 at uhidev4: 8 variable keys, 6 key codes
wskbd2 at ukbd1 mux 1
wskbd2: connecting to wsdisplay0

-- 
Best Regards
Edd Barrett

http://www.theunixzoo.co.uk

Thinkpad dock only provides HDMI2 after first suspend.

[Edd Barrett]

 0 Chicony Electronics Co., 
Ltd. Integrated Camera rev 2.00/5.20 addr 5
video0 at uvideo0
uhub3 at uhub1 port 1 Intel Rate Matching Hub rev 2.00/0.00 addr 2
uhub4 at uhub3 port 3 Standard Microsystems product 0x2514 rev 2.00/0.00 addr 
3
uhidev3 at uhub3 port 5 configuration 1 interface 0 Tablet ISD-V4 rev 
1.10/6.11 addr 4
uhidev3: iclass 3/1, 2 report ids
ums1 at uhidev3 reportid 1: 2 buttons
wsmouse2 at ums1 mux 0
ums2 at uhidev3 reportid 2: 3 buttons, tip, barrel, eraser
wsmouse3 at ums2 mux 0
vscsi0 at root
scsibus2 at vscsi0: 256 targets
softraid0 at root
scsibus3 at softraid0: 256 targets
root on sd0a (a81068940d057f4c.a) swap on sd0b dump on sd0b
uhidev4 at uhub4 port 4 configuration 1 interface 0 SEJIN SEJIN USB joint 
Keyboard rev 1.10/1.30 addr 5
uhidev4: iclass 3/1
ukbd1 at uhidev4: 8 variable keys, 6 key codes
wskbd2 at ukbd1 mux 1
wskbd2: connecting to wsdisplay0
wskbd1: disconnecting from wsdisplay0
wskbd1 detached
ukbd0 detached
uhidev0 detached
wsmouse1 detached
ums0 detached
uhid0 detached
uhid1 detached
uhid2 detached
uhidev1 detached
uhid3 detached
uhid4 detached
uhid5 detached
uhid6 detached
uhidev2 detached
ugen0 detached
video0 detached
uvideo0 detached
uhub2 detached
uhub0 detached
wskbd2: disconnecting from wsdisplay0
wskbd2 detached
ukbd1 detached
uhidev4 detached
uhub4 detached
wsmouse2 detached
ums1 detached
wsmouse3 detached
ums2 detached
uhidev3 detached
uhub3 detached
uhub1 detached
uhub0 at usb0 Intel EHCI root hub rev 2.00/1.00 addr 1
uhub1 at usb1 Intel EHCI root hub rev 2.00/1.00 addr 1
uhub2 at uhub0 port 1 Intel Rate Matching Hub rev 2.00/0.00 addr 2
uhidev0 at uhub2 port 2 configuration 1 interface 0 Logitech USB Receiver rev 
2.00/12.01 addr 3
uhidev0: iclass 3/1
ukbd0 at uhidev0: 8 variable keys, 6 key codes
wskbd1 at ukbd0 mux 1
wskbd1: connecting to wsdisplay0
uhidev1 at uhub2 port 2 configuration 1 interface 1 Logitech USB Receiver rev 
2.00/12.01 addr 3
uhidev1: iclass 3/1, 8 report ids
ums0 at uhidev1 reportid 2: 16 buttons, Z dir
wsmouse1 at ums0 mux 0
uhid0 at uhidev1 reportid 3: input=4, output=0, feature=0
uhid1 at uhidev1 reportid 4: input=1, output=0, feature=0
uhid2 at uhidev1 reportid 8: input=1, output=0, feature=0
uhidev2 at uhub2 port 2 configuration 1 interface 2 Logitech USB Receiver rev 
2.00/12.01 addr 3
uhidev2: iclass 3/0, 33 report ids
uhid3 at uhidev2 reportid 16: input=6, output=6, feature=0
uhid4 at uhidev2 reportid 17: input=19, output=19, feature=0
uhid5 at uhidev2 reportid 32: input=14, output=14, feature=0
uhid6 at uhidev2 reportid 33: input=31, output=31, feature=0
ugen0 at uhub2 port 4 Broadcom Corp BCM20702A0 rev 2.00/1.12 addr 4
uvideo0 at uhub2 port 6 configuration 1 interface 0 Chicony Electronics Co., 
Ltd. Integrated Camera rev 2.00/5.20 addr 5
video0 at uvideo0
uhub3 at uhub1 port 1 Intel Rate Matching Hub rev 2.00/0.00 addr 2
uhub4 at uhub3 port 3 Standard Microsystems product 0x2514 rev 2.00/0.00 addr 
3
uhidev3 at uhub3 port 5 configuration 1 interface 0 Tablet ISD-V4 rev 
1.10/6.11 addr 4
uhidev3: iclass 3/1, 2 report ids
ums1 at uhidev3 reportid 1: 2 buttons
wsmouse2 at ums1 mux 0
ums2 at uhidev3 reportid 2: 3 buttons, tip, barrel, eraser
wsmouse3 at ums2 mux 0
uhidev4 at uhub4 port 4 configuration 1 interface 0 SEJIN SEJIN USB joint 
Keyboard rev 1.10/1.30 addr 5
uhidev4: iclass 3/1
ukbd1 at uhidev4: 8 variable keys, 6 key codes
wskbd2 at ukbd1 mux 1
wskbd2: connecting to wsdisplay0

-- 
Best Regards
Edd Barrett

http://www.theunixzoo.co.uk

USB panic

[Edd Barrett]

 interface 0 SCM Microsystems Inc.
eUSB Multi-Slot Reader rev 1.10/5.15 addr 4
umass0: using SCSI over Bulk-Only
scsibus4 at umass0: 2 targets, initiator 0
sd1 at scsibus4 targ 1 lun 0: eUSB, Compact Flash, 5.0F SCSI2 0/direct
removable
sd1: 3847MB, 512 bytes/sector, 7880544 sectors
sd2 at scsibus4 targ 1 lun 1: eUSB, SD-MS-SM, 5.0F SCSI2 0/direct
removable

-- 
Best Regards
Edd Barrett

http://www.theunixzoo.co.uk

Re: USB panic

[Edd Barrett]

Ah, just before that we have:

...
softraid0 at root
scsibus3 at softraid0: 256 targets
root on sd0a (a81068940d057f4c.a) swap on sd0b dump on sd0b
WARNING: / was not properly unmounted
ehci_idone: ex=0xff041d0aaaf0 is done!
umass0 at uhub3 port 2 configuration 1 interface 0 Shuttle Technology
product 0x0325 rev 1.10/5.15 addr 4
umass0: using SCSI over Bulk-Only
scsibus4 at umass0: 2 targets, initiator 0
uvm_fault(0x818dc840, 0x8421, 0, 1) - e
...

You know the rest.

The ehci_idone part is relevant?


On 8 February 2015 at 22:24, Martin Pieuchot mpieuc...@nolizard.org wrote:

 On 08/02/15(Sun) 21:57, Edd Barrett wrote:
  Hey,
 
  I have been having issues with a userland program hard resetting my
 machine.
 
  I *think* but cannot be sure it is the USB compact flash reader causing
 the
  issue:

 Difficult to believe that's an hardware problem.

  umass0 at uhub3 port 2 configuration 1 interface 0 SCM Microsystems Inc.
  eUSB Multi-Slot Reader rev 1.10/5.15 addr 4
  umass0: using SCSI over Bulk-Only
  scsibus4 at umass0: 2 targets, initiator 0
 
  I am using this to image a CF under fs-uae to insert into a real amiga. I
  have done this before in the past without issue. It basically involves
  pointing the emulator at /dev/rsd1c.
 
  About 1/5 times when I start fs-uae, I get a hard reset of my machine.
 
  I notice the following in dmesg log from the last boot where it crashed:

 And nothing before that?

  uvm_fault(0x818dc840, 0x8421, 0, 1) - e
  kernel: page fault trap, code=0
  Stopped at  usb_allocmem+0x175: cmpq%rbx,0(%rax)

 This correspond to a chunk of DMA memory in the freelist, looks like
 you're losing a race against your HC and freeing this chunk too soon.

  splassert: sleep_finish: want 12 have 14
  splassert: assertwaitok: want 0 have 14
  splassert: mi_switch: want 12 have 14
  splassert: sched_chooseproc: want 12 have 14
  panic: kernel diagnostic assertion p-p_wchan == NULL failed: file
  ../../../../kern/kern_sched.c, line 322
  panic: tsleep: not SONPROC
  panic: tsleep: not SONPROC
  panic: tsleep: not SONPROC
  panic: tsleep: not SONPROC
  panic: tsleep: not SONPROC
  panic: tsleep: not SONPROC
  panic: tsleep: not SONPROC
  ...
 
  I am not given a chance to interact with ddb.
 
  I believe the CF reader to work OK (but it is quite old, maybe it is
  dying?).
 
  I will try to source another CF reader to see if the problem goes away.
 
  Dmesg below. (Not sure what happened to em0)
 
  OpenBSD 5.7-beta (GENERIC.MP) #838: Sat Feb  7 09:15:03 MST 2015
  t...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
  real mem = 16844521472 (16064MB)
  avail mem = 16392187904 (15632MB)
  mpath0 at root
  scsibus0 at mpath0: 256 targets
  mainbus0 at root
  bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xdae9d000 (68 entries)
  bios0: vendor LENOVO version GCET92WW (2.52 ) date 02/25/2013
  bios0: LENOVO 3437CTO
  acpi0 at bios0: rev 2
  acpi0: sleep states S0 S3 S4 S5
  acpi0: tables DSDT FACP SLIC TCPA SSDT SSDT SSDT HPET APIC MCFG ECDT FPDT
  ASF! UEFI UEFI POAT SSDT SSDT UEFI DBG2
  acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) EXP3(S4) XHCI(S3)
 EHC1(S3)
  EHC2(S3) HDEF(S4)
  acpitimer0 at acpi0: 3579545 Hz, 24 bits
  acpihpet0 at acpi0: 14318179 Hz
  acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
  cpu0 at mainbus0: apid 0 (boot processor)
  cpu0: Intel(R) Core(TM) i5-3320M CPU @ 2.60GHz, 2594.54 MHz
  cpu0:
 
 FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
  cpu0: 256KB 64b/line 8-way L2 cache
  cpu0: smt 0, core 0, package 0
  mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
  cpu0: apic clock running at 99MHz
  cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE
  cpu1 at mainbus0: apid 1 (application processor)
  cpu1: Intel(R) Core(TM) i5-3320M CPU @ 2.60GHz, 2594.11 MHz
  cpu1:
 
 FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
  cpu1: 256KB 64b/line 8-way L2 cache
  cpu1: smt 1, core 0, package 0
  cpu2 at mainbus0: apid 2 (application processor)
  cpu2: Intel(R) Core(TM) i5-3320M CPU @ 2.60GHz, 2594.11 MHz
  cpu2:
 
 FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
  cpu2: 256KB 64b/line 8-way L2 cache
  cpu2: smt 0, core 1, package 0
  cpu3 at mainbus0

Non-functional USB ports on thinkpad x230t/OpenBSD

[Edd Barrett]

: 1366x768
wsdisplay0 at vga1 mux 1: console (std, vt100 emulation)
wsdisplay0: screen 1-5 added (std, vt100 emulation)
Intel 7 Series xHCI rev 0x04 at pci0 dev 20 function 0 not configured
Intel 7 Series MEI rev 0x04 at pci0 dev 22 function 0 not configured
em0 at pci0 dev 25 function 0 Intel 82579LM rev 0x04: msi, address 
3c:97:0e:a5:02:69
ehci0 at pci0 dev 26 function 0 Intel 7 Series USB rev 0x04: apic 2 int 16
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 Intel EHCI root hub rev 2.00/1.00 addr 1
azalia0 at pci0 dev 27 function 0 Intel 7 Series HD Audio rev 0x04: msi
azalia0: codecs: Realtek ALC269, Intel/0x2806, using Realtek ALC269
audio0 at azalia0
ppb0 at pci0 dev 28 function 0 Intel 7 Series PCIE rev 0xc4: msi
pci1 at ppb0 bus 2
sdhc0 at pci1 dev 0 function 0 Ricoh 5U822 SD/MMC rev 0x07: apic 2 int 16
sdmmc0 at sdhc0
ppb1 at pci0 dev 28 function 1 Intel 7 Series PCIE rev 0xc4: msi
pci2 at ppb1 bus 3
iwn0 at pci2 dev 0 function 0 Intel Centrino Wireless-N 2200 rev 0xc4: msi, 
MIMO 2T2R, BGN, address 9c:4e:36:b8:f8:f8
ppb2 at pci0 dev 28 function 2 Intel 7 Series PCIE rev 0xc4: msi
pci3 at ppb2 bus 4
ehci1 at pci0 dev 29 function 0 Intel 7 Series USB rev 0x04: apic 2 int 23
usb1 at ehci1: USB revision 2.0
uhub1 at usb1 Intel EHCI root hub rev 2.00/1.00 addr 1
pcib0 at pci0 dev 31 function 0 Intel QM77 LPC rev 0x04
ahci0 at pci0 dev 31 function 2 Intel 7 Series AHCI rev 0x04: msi, AHCI 1.3
scsibus1 at ahci0: 32 targets
sd0 at scsibus1 targ 0 lun 0: ATA, Crucial_CT240M50, MU02 SCSI3 0/direct 
fixed naa.500a0751093c44b5
sd0: 228936MB, 512 bytes/sector, 468862128 sectors, thin
ichiic0 at pci0 dev 31 function 3 Intel 7 Series SMBus rev 0x04: apic 2 int 18
iic0 at ichiic0
spdmem0 at iic0 addr 0x50: 8GB DDR3 SDRAM PC3-12800 SO-DIMM
spdmem1 at iic0 addr 0x51: 8GB DDR3 SDRAM PC3-12800 SO-DIMM
isa0 at pcib0
isadma0 at isa0
pckbc0 at isa0 port 0x60/5
pckbd0 at pckbc0 (kbd slot)
pckbc0: using irq 1 for kbd slot
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pms0 at pckbc0 (aux slot)
pckbc0: using irq 12 for aux slot
wsmouse0 at pms0 mux 0
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
uhub2 at uhub0 port 1 Intel Rate Matching Hub rev 2.00/0.00 addr 2
ugen0 at uhub2 port 4 Broadcom Corp BCM20702A0 rev 2.00/1.12 addr 3
uvideo0 at uhub2 port 6 configuration 1 interface 0 Chicony Electronics Co., 
Ltd. Integrated Camera rev 2.00/5.20 addr 4
video0 at uvideo0
uhub3 at uhub1 port 1 Intel Rate Matching Hub rev 2.00/0.00 addr 2
uhidev0 at uhub3 port 5 configuration 1 interface 0 Tablet ISD-V4 rev 
1.10/6.11 addr 3
uhidev0: iclass 3/1, 2 report ids
ums0 at uhidev0 reportid 1: 2 buttons
wsmouse1 at ums0 mux 0
ums1 at uhidev0 reportid 2: 3 buttons, tip, barrel, eraser
wsmouse2 at ums1 mux 0
vscsi0 at root
scsibus2 at vscsi0: 256 targets
softraid0 at root
scsibus3 at softraid0: 256 targets
root on sd0a (a81068940d057f4c.a) swap on sd0b dump on sd0b
uhidev1 at uhub2 port 2 configuration 1 interface 0 Microsoft Microsoft 
IntelliMouse\M-. Optical rev 1.10/1.21 addr 5
uhidev1: iclass 3/1
ums2 at uhidev1: 5 buttons, Z dir
wsmouse3 at ums2 mux 0
wsmouse3 detached
ums2 detached
uhidev1 detached
umass0 at uhub2 port 2 configuration 1 interface 0 Kingston DataTraveler 2.0 
rev 2.00/1.00 addr 5
umass0: using SCSI over Bulk-Only
scsibus4 at umass0: 2 targets, initiator 0
sd1 at scsibus4 targ 1 lun 0: Kingston, DataTraveler 2.0, PMAP SCSI2 0/direct 
removable serial.09511665BDB1595433FB
sd1: 29984MB, 512 bytes/sector, 61408128 sectors
sd1 detached
scsibus4 detached
umass0 detached

-- 
Best Regards
Edd Barrett

http://www.theunixzoo.co.uk

Re: Stairstep mouse motion

[Edd Barrett]

On Tue, Oct 29, 2013 at 11:07:29PM +0600, Alexandr Shadchin wrote:

  Look good to me. However I've a concern about compatibility with
  NetBSD. The kernel change should be documented in the commit message
  for xf86-input-ws so that they can catch up with the kernel change
  before they update xf86-input-ws...
  
 
 Update diff (add small hack for NetBSD).

Having spent ten minutes scribbling in xournal using my stylus, I can say
that this appears to work well. Diagonal lines are smooth even when drawn
fast. ws.c is looking much tidier too.

If the others are happy with the kernel portion of your diff, then I
reckon this is good to go in.

-- 
Best Regards
Edd Barrett

http://www.theunixzoo.co.uk

Re: Stairstep mouse motion

[Edd Barrett]

On Thu, Oct 24, 2013 at 10:33:22PM +0300, Henri Kemppainen wrote:
 What happens when priv-swap_axes is set, and the ax  ay branch is
 taken along with the wsWheelEmuFilterMotion() branch.  Following
 continue another event is processed and now the axes are swapped again
 (ax and ay were not reset after use) and then what?  Not very likely
 I know.

Ah, yes, there is the possibility of posting an inconsistent pointer sample
in this case. Perhaps we should only update the old_ax/old_ay if the
wsWheelEmuFilterMotion branch is not taken?

What do you think? And yes, this is a very very unlikely case. You could
argue it wouldn't matter even if it did happen.

-- 
Best Regards
Edd Barrett

http://www.theunixzoo.co.uk

Re: Stairstep mouse motion

[Edd Barrett]

On Wed, Oct 16, 2013 at 11:45:34PM +0100, Edd Barrett wrote:
 Tested on my x230t and will continue to test. No regrssions noticed on
 relative pointing devices.
 
 OK?

Anyone?

I appreciate that I am probably the only one using OpenBSD on a tablet,
but a looks OK and no regressions for relative pointing devices
would be great.

Keen to get this in so that I don't have to rebuild the ws driver every
time I update my snapshot.

-- 
Best Regards
Edd Barrett

http://www.theunixzoo.co.uk

Re: Stairstep mouse motion

[Edd Barrett]

On Thu, Jul 18, 2013 at 09:23:00PM +0100, Edd Barrett wrote:
 After applying your diff:
 Touchpad: smooth lines.
 Nipple:   smooth lines.
 Pen:  jagged lines.
 
 I wonder if it is because the pen is an absolute pointing device.  You
 probably need extra magic in the WSCONS_EVENT_MOUSE_ABSOLUTE_* cases.

The following diff fixes the jagged diagonal lines for absolute pointing
devices. I think I might be able to simplify some of the relative pointer
code here too, but that should be a separate diff.

Tested on my x230t and will continue to test. No regrssions noticed on
relative pointing devices.

OK?

Index: src/ws.c
===
RCS file: /home/edd/cvsync/cvs/xenocara/driver/xf86-input-ws/src/ws.c,v
retrieving revision 1.58
diff -u -p -u -r1.58 ws.c
--- src/ws.c20 Jul 2013 13:24:50 -  1.58
+++ src/ws.c16 Oct 2013 22:36:21 -
@@ -474,7 +474,7 @@ wsReadInput(InputInfoPtr pInfo)
 {
WSDevicePtr priv = (WSDevicePtr)pInfo-private;
static struct wscons_event eventList[NUMEVENTS];
-   int n, c, dx, dy;
+   int n, c, dx, dy, ax, ay;
struct wscons_event *event = eventList;
unsigned char *pBuf;
 
@@ -488,11 +488,11 @@ wsReadInput(InputInfoPtr pInfo)
if (n == 0)
return;
 
-   dx = dy = 0;
+   dx = dy = ax = ay = 0;
n /= sizeof(struct wscons_event);
while (n--) {
int buttons = priv-lastButtons;
-   int newdx = 0, newdy = 0, dz = 0, dw = 0, ax = 0, ay = 0;
+   int newdx = 0, newdy = 0, dz = 0, dw = 0;
int zbutton = 0, wbutton = 0;
 
switch (event-type) {
@@ -595,25 +595,17 @@ wsReadInput(InputInfoPtr pInfo)
ax = ay;
ay = tmp;
}
-   if (ax) {
+   if (ax  ay) {
int xdelta = ax - priv-old_ax;
-   priv-old_ax = ax;
-   if (wsWheelEmuFilterMotion(pInfo, xdelta, 0))
-   continue;
-
-   /* absolute position event */
-   DBG(3, ErrorF(postMotionEvent X %d\n, ax));
-   xf86PostMotionEvent(pInfo-dev, 1, 0, 1, ax);
-   }
-   if (ay) {
int ydelta = ay - priv-old_ay;
+   priv-old_ax = ax;
priv-old_ay = ay;
-   if (wsWheelEmuFilterMotion(pInfo, 0, ydelta))
+   if (wsWheelEmuFilterMotion(pInfo, xdelta, ydelta))
continue;
-
/* absolute position event */
-   DBG(3, ErrorF(postMotionEvent y %d\n, ay));
-   xf86PostMotionEvent(pInfo-dev, 1, 1, 1, ay);
+   DBG(3, ErrorF(postMotionEvent X %d Y %d\n, ax, ay));
+   xf86PostMotionEvent(pInfo-dev, 1, 0, 2, ax, ay);
+   ax = ay = 0; /* prevent second post below */
}
}
if (dx || dy) {
@@ -624,6 +616,24 @@ wsReadInput(InputInfoPtr pInfo)
DBG(3, ErrorF(postMotionEvent dX %d dY %d\n,
dx, dy));
xf86PostMotionEvent(pInfo-dev, 0, 0, 2, dx, dy);
+   }
+   if (ax) {
+   int xdelta = ax - priv-old_ax;
+   priv-old_ax = ax;
+   if (wsWheelEmuFilterMotion(pInfo, xdelta, 0))
+   return;
+   /* absolute position event */
+   DBG(3, ErrorF(postMotionEvent X %d\n, ax));
+   xf86PostMotionEvent(pInfo-dev, 1, 0, 1, ax);
+   }
+   if (ay) {
+   int ydelta = ay - priv-old_ay;
+   priv-old_ay = ay;
+   if (wsWheelEmuFilterMotion(pInfo, 0, ydelta))
+   return;
+   /* absolute position event */
+   DBG(3, ErrorF(postMotionEvent Y %d\n, ay));
+   xf86PostMotionEvent(pInfo-dev, 1, 1, 1, ay);
}
return;
 }

-- 
Best Regards
Edd Barrett

http://www.theunixzoo.co.uk

Re: memset.S for amd64

[Edd Barrett]

On Thu, Sep 19, 2013 at 01:23:19PM -0400, Brad Smith wrote:
 On 19/09/13 7:47 AM, mxb wrote:
 
 This file is already in base.
 /usr/src/sys/lib/libkern/arch/amd64/memset.S
 
 That is in the kernel not libc.

Indeed. I recall seeing a macro called COPY_TO_KERNEL or something. I
probably need to use that.

With regards to the differences. The only difference between the in-kernel
version and FreeBSD's from libc (that is not in a comment) is as follows:

---8---
@@ -8,6 +11,7 @@
 
 ENTRY(memset)
movq%rsi,%rax
+   andq$0xff,%rax
movq%rdx,%rcx
movq%rdi,%r11
---8---

The FreeBSD implementation has the extra instruction.

It looks like they copy the second argument (int c) from rsi and stash it it
rax. Since c is going to be used as a char (and thus uses only a byte) the
original author clears bits 8 through 63 with an andq.

It looks like this is not strictly necessary as the lower byte of rax (aka,
AL) is then copied across the other bytes of rax anyway. This allows them to
copy the bytes 8 at a time by movq.

Can someone check this? Is the andq unnecessary in this case?

-- 
Best Regards
Edd Barrett

http://www.theunixzoo.co.uk

Re: memset.S for amd64

[Edd Barrett]

On Wed, Sep 18, 2013 at 07:08:31PM +0100, Edd Barrett wrote:
 In short, each experiment warms up by setting and checking a load of buffers
 before setting as many buffers as possible given a one minute timeframe. The
 experiments were run with varying buffer sizes under both memset.S and
 memset.c.

Forgot to say, each experiment was repeated 5 times (each bufsz/
memset combination) and averages were taken.

See the Python scripts in the repo for details.

-- 
Best Regards
Edd Barrett

http://www.theunixzoo.co.uk

memset.S for amd64

[Edd Barrett]

Hi,

A few weeks back (at a PyPy sprint) someone asked me why amd64/OpenBSD
has no assembler implementation of memset(3). After asking on icb, there
were a couple of theories:

 a) Perhaps the available assembler implementations of memset are slower
than our C one.
 b) Perhaps due to a), no-one got round to it.

It turns out that (on the systems I benchmarked on), FreeBSD's memset.S [1]
is faster than our memset.c in libc. Those interested can see the results
(including graphs) of some benchmarks comparing FreeBSD memset.S and our
memset.C here: https://github.com/vext01/openbsd-libc-benchmarks

In short, each experiment warms up by setting and checking a load of buffers
before setting as many buffers as possible given a one minute timeframe. The
experiments were run with varying buffer sizes under both memset.S and
memset.c. During experimentation, the machines were otherwise idle. Although
the results vary from system to system, it seems that memset.S is between 6
and 30 times faster. The results also show that there was no case (that we
tested) where memset.c was faster than memset.S.

Thw following diff enables memset.S in libc on amd64.

 * Is what I have done with the vendor keywords acceptable? (moved -- but
   preserving order -- them to the top and removed __FBSDID).
 * I removed the non-executable stack hint as I don't see anything
   similar in other .S files in-tree.
 * I don't think any library bump is needed. Can someone confirm this?

I have run with this diff for the last week or so with no issues. I have
been running some heavy compilation tasks during this time (building
lang/pypy).

[1] 
http://svnweb.freebsd.org/base/head/lib/libc/amd64/string/memset.S?revision=217106view=markup

PS.

If people think this kind of work is worthwhile, then there are some
other routines we could borrow from the other BSDs too.


Index: lib/libc/arch/amd64/string/Makefile.inc
===
RCS file: /cvs/src/lib/libc/arch/amd64/string/Makefile.inc,v
retrieving revision 1.4
diff -u -p -r1.4 Makefile.inc
--- lib/libc/arch/amd64/string/Makefile.inc 4 Sep 2012 03:10:42 -   
1.4
+++ lib/libc/arch/amd64/string/Makefile.inc 18 Sep 2013 17:05:10 -
@@ -3,4 +3,4 @@
 SRCS+=  bcmp.c ffs.S index.c memchr.c memcmp.c bcopy.c bzero.c \
 rindex.c strcat.c strcmp.c strcpy.c strcspn.c strlen.c \
 strncat.c strncmp.c strncpy.c strpbrk.c strsep.c \
-strspn.c strstr.c swab.c memset.c strlcpy.c strlcat.c
+strspn.c strstr.c swab.c memset.S strlcpy.c strlcat.c
Index: lib/libc/arch/amd64/string/memset.S
===
RCS file: lib/libc/arch/amd64/string/memset.S
diff -N lib/libc/arch/amd64/string/memset.S
--- /dev/null   1 Jan 1970 00:00:00 -
+++ lib/libc/arch/amd64/string/memset.S 18 Sep 2013 17:05:10 -
@@ -0,0 +1,58 @@
+/* $OpenBSD$ */
+/* FreeBSD revision: 217106 */
+/* $NetBSD: memset.S,v 1.3 2004/02/26 20:50:06 drochner Exp $ */
+/*
+ * Written by J.T. Conklin j...@netbsd.org.
+ * Public domain.
+ * Adapted for NetBSD/x86_64 by Frank van der Linden f...@wasabisystems.com
+ */
+
+#include machine/asm.h
+
+ENTRY(memset)
+   movq%rsi,%rax
+   andq$0xff,%rax
+   movq%rdx,%rcx
+   movq%rdi,%r11
+
+   cld /* set fill direction forward */
+
+   /*
+* if the string is too short, it's really not worth the overhead
+* of aligning to word boundries, etc.  So we jump to a plain
+* unaligned set.
+*/
+   cmpq$0x0f,%rcx
+   jle L1
+
+   movb%al,%ah /* copy char to all bytes in word */
+   movl%eax,%edx
+   sall$16,%eax
+   orl %edx,%eax
+
+   movl%eax,%edx
+   salq$32,%rax
+   orq %rdx,%rax
+
+   movq%rdi,%rdx   /* compute misalignment */
+   negq%rdx
+   andq$7,%rdx
+   movq%rcx,%r8
+   subq%rdx,%r8
+
+   movq%rdx,%rcx   /* set until word aligned */
+   rep
+   stosb
+
+   movq%r8,%rcx
+   shrq$3,%rcx /* set by words */
+   rep
+   stosq
+
+   movq%r8,%rcx/* set remainder by bytes */
+   andq$7,%rcx
+L1:rep
+   stosb
+   movq%r11,%rax
+
+   ret

-- 
Best Regards
Edd Barrett

http://www.theunixzoo.co.uk

Re: Merge uhts(4) into ums(4).

[Edd Barrett]

On Sat, Aug 10, 2013 at 12:33:12PM +0100, Edd Barrett wrote:
 On Fri, Aug 09, 2013 at 08:35:49AM +0200, Matthieu Herrb wrote:
  And you can also do the next step and tedu uhts 
 
 The following diff tedus uhts(4). This is the first driver I have
 tedued, so please check carefully.

Anyone? No knowledge of uhts(4) is required, just removing the (now
dead) code.

-- 
Best Regards
Edd Barrett

http://www.theunixzoo.co.uk

Re: Merge uhts(4) into ums(4).

[Edd Barrett]

-miny = 0  wsmc-maxy = 0 
-   wsmc-resx = 0  wsmc-resy = 0 
-   wsmc-minx  32768  wsmc-maxx  32768 
-   wsmc-miny  32768  wsmc-maxy  32768 
-   (wsmc-maxx - wsmc-minx) != 0 
-   (wsmc-maxy - wsmc-miny) != 0 
-   wsmc-resx  32768  wsmc-resy  32768 
-   wsmc-swapxy = 0  wsmc-swapxy = 1 
-   wsmc-samplelen = 0  wsmc-samplelen = 1))
-   return (EINVAL);
-
-   sc-sc_tsscale.minx = wsmc-minx;
-   sc-sc_tsscale.maxx = wsmc-maxx;
-   sc-sc_tsscale.miny = wsmc-miny;
-   sc-sc_tsscale.maxy = wsmc-maxy;
-   sc-sc_tsscale.swapxy = wsmc-swapxy;
-   sc-sc_tsscale.resx = wsmc-resx;
-   sc-sc_tsscale.resy = wsmc-resy;
-   sc-sc_rawmode = wsmc-samplelen;
-   break;
-   case WSMOUSEIO_GCALIBCOORDS:
-   wsmc-minx = sc-sc_tsscale.minx;
-   wsmc-maxx = sc-sc_tsscale.maxx;
-   wsmc-miny = sc-sc_tsscale.miny;
-   wsmc-maxy = sc-sc_tsscale.maxy;
-   wsmc-swapxy = sc-sc_tsscale.swapxy;
-   wsmc-resx = sc-sc_tsscale.resx;
-   wsmc-resy = sc-sc_tsscale.resy;
-   wsmc-samplelen = sc-sc_rawmode;
-   break;
-   default:
-   error = ENOTTY;
-   break;
-   }
-
-   return error;
-}
Index: sys/dev/usb/ums.c
===
RCS file: /cvs/src/sys/dev/usb/ums.c,v
retrieving revision 1.36
diff -u -p -r1.36 ums.c
--- sys/dev/usb/ums.c   9 Aug 2013 22:10:17 -   1.36
+++ sys/dev/usb/ums.c   10 Aug 2013 11:26:39 -
@@ -105,19 +105,13 @@ ums_match(struct device *parent, void *m
HID_USAGE2(HUP_GENERIC_DESKTOP, HUG_MOUSE)))
return (UMATCH_IFACECLASS);
 
-   /*
-* For now return a value higher than UMATCH_IFACECLASS to make sure
-* touchscreens and digitizers no longer attach to uhts(4).
-*/
if (hid_is_collection(desc, size, uha-reportid,
HID_USAGE2(HUP_DIGITIZERS, HUD_TOUCHSCREEN)))
-   return (UMATCH_IFACECLASS_IFACESUBCLASS); /* XXX */
-   /* return (UMATCH_IFACECLASS); */
+   return (UMATCH_IFACECLASS);
 
if (hid_is_collection(desc, size, uha-reportid,
HID_USAGE2(HUP_DIGITIZERS, HUD_PEN)))
-   return (UMATCH_IFACECLASS_IFACESUBCLASS); /* XXX */
-   /* return (UMATCH_IFACECLASS); */
+   return (UMATCH_IFACECLASS);
 
return (UMATCH_NONE);
 }

-- 
Best Regards
Edd Barrett

http://www.theunixzoo.co.uk

Re: Merge uhts(4) into ums(4).

[Edd Barrett]

On Fri, Jul 19, 2013 at 04:06:49PM +0100, Edd Barrett wrote:
 Cheers. Revised diff:

Right, now the tree is open again.

Matthieu, did you test this diff on your various devices for
regressions? Can this go in?

-- 
Best Regards
Edd Barrett

http://www.theunixzoo.co.uk

Re: Merge uhts(4) into ums(4).

[Edd Barrett]

On Thu, Jul 18, 2013 at 09:25:46PM +0059, Jason McIntyre wrote:
 you want a space before the full stop (above)

 and zap this blank line
 
 the Nd should match exactly, so either change suuport in the man page,
 or devices here

Cheers. Revised diff:

Index: share/man/man4/ums.4
===
RCS file: /cvs/src/share/man/man4/ums.4,v
retrieving revision 1.10
diff -u -p -r1.10 ums.4
--- share/man/man4/ums.426 Jun 2008 05:42:07 -  1.10
+++ share/man/man4/ums.419 Jul 2013 14:57:23 -
@@ -28,23 +28,30 @@
 .\ ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
 .\ POSSIBILITY OF SUCH DAMAGE.
 .\
-.Dd $Mdocdate: June 26 2008 $
+.Dd $Mdocdate: July 17 2013 $
 .Dt UMS 4
 .Os
 .Sh NAME
 .Nm ums
-.Nd USB mouse support
+.Nd USB HID mouse, touchscreen and digitiser devices
 .Sh SYNOPSIS
 .Cd ums* at uhidev?
 .Cd wsmouse* at ums? mux 0
 .Sh DESCRIPTION
 The
 .Nm
-driver provides support for USB mice.
-Access to the mouse is through the
+driver provides support for USB HID mice, touchscreens and digitisers.
+Access to these devices is through the
 .Xr wscons 4
 driver.
+.Pp
+If the touchscreen sensor is poorly aligned, then
+.Xr xtsscale 1
+should be used to provide calibration results to the
+.Nm
+driver.
 .Sh SEE ALSO
+.Xr xtsscale 1 ,
 .Xr uhidev 4 ,
 .Xr usb 4 ,
 .Xr wsmouse 4
@@ -54,3 +61,15 @@ The
 driver
 first appeared in
 .Ox 2.8 .
+.Sh AUTHORS
+.An -nosplit
+HID touchscreen and digitiser support was written by
+.An Robert Nagy
+and
+.An Matthieu Herrb
+then later merged into the generic
+.Xr ums 4
+driver by
+.An Edd Barrett .
+.Sh CAVEATS
+Touchscreen and digitiser pressure sensitivity is not yet implemented.
Index: share/man/man4/usb.4
===
RCS file: /cvs/src/share/man/man4/usb.4,v
retrieving revision 1.140
diff -u -p -r1.140 usb.4
--- share/man/man4/usb.41 Jun 2013 17:04:57 -   1.140
+++ share/man/man4/usb.419 Jul 2013 14:57:23 -
@@ -252,7 +252,7 @@ HID touchscreen support
 keyboards that follow the boot protocol
 .It Xr ums 4
 .Tn USB
-mouse devices
+HID mouse, touchscreen and digitiser devices
 .It Xr uoaklux 4
 Toradex OAK USB illuminance sensor
 .It Xr uoakrh 4
Index: sys/dev/usb/hidms.c
===
RCS file: /cvs/src/sys/dev/usb/hidms.c,v
retrieving revision 1.4
diff -u -p -r1.4 hidms.c
--- sys/dev/usb/hidms.c 19 Aug 2011 18:46:22 -  1.4
+++ sys/dev/usb/hidms.c 19 Jul 2013 14:57:28 -
@@ -194,6 +194,27 @@ hidms_setup(struct device *self, struct 
break;
ms-sc_num_buttons = i - 1;
 
+   if (hid_locate(desc, dlen, HID_USAGE2(HUP_DIGITIZERS,
+   HUD_TIP_SWITCH), id, hid_input,
+   ms-sc_loc_btn[ms-sc_num_buttons], NULL)){
+   ms-sc_flags |= HIDMS_TIP;
+   ms-sc_num_buttons++;
+   }
+
+   if (hid_locate(desc, dlen, HID_USAGE2(HUP_DIGITIZERS,
+   HUD_ERASER), id, hid_input,
+   ms-sc_loc_btn[ms-sc_num_buttons], NULL)){
+   ms-sc_flags |= HIDMS_ERASER;
+   ms-sc_num_buttons++;
+   }
+
+   if (hid_locate(desc, dlen, HID_USAGE2(HUP_DIGITIZERS,
+   HUD_BARREL_SWITCH), id, hid_input,
+   ms-sc_loc_btn[ms-sc_num_buttons], NULL)){
+   ms-sc_flags |= HIDMS_BARREL;
+   ms-sc_num_buttons++;
+   }
+
/*
 * The Microsoft Wireless Notebook Optical Mouse seems to be in worse
 * shape than the Wireless Intellimouse 2.0, as its X, Y, wheel, and
@@ -216,6 +237,11 @@ hidms_setup(struct device *self, struct 
/* Parse descriptors to get touch panel bounds */
d = hid_start_parse(desc, dlen, hid_input);
while (hid_get_item(d, h)) {
+   if (h.kind != hid_input ||
+   HID_GET_USAGE_PAGE(h.usage) != HUP_GENERIC_DESKTOP)
+   continue;
+   DPRINTF((hidms: usage=0x%x range %d..%d\n,
+   h.usage, h.logical_minimum, h.logical_maximum));
switch (HID_GET_USAGE(h.usage)) {
case HUG_X:
if (ms-sc_flags  HIDMS_ABSX) {
@@ -255,6 +281,14 @@ hidms_attach(struct hidms *ms, const str
printf(, Z and W dir);
break;
}
+
+   if (ms-sc_flags  HIDMS_TIP)
+   printf(, tip);
+   if (ms-sc_flags  HIDMS_BARREL)
+   printf(, barrel);
+   if (ms-sc_flags  HIDMS_ERASER)
+   printf(, eraser);
+
printf(\n);
 
 #ifdef HIDMS_DEBUG
Index: sys/dev/usb/hidmsvar.h
===
RCS file: /cvs/src/sys/dev/usb/hidmsvar.h,v
retrieving revision 1.2
diff -u -p -r1.2 hidmsvar.h
--- sys/dev/usb/hidmsvar.h  4 Mar 2011 23:57:52 -   1.2
+++ sys/dev/usb/hidmsvar.h  19 Jul 2013 14:57:28 -
@@ -43,14

Merge uhts(4) into ums(4).

[Edd Barrett]

Hi,

I have been working with mpi@ and matthieu@ to improve support for my
x230t, in particular the digitiser/pen. Last week I committed a small
change to uhts(4) which enables basic support for the digitiser.

During our discussions we noticed that uhts(4) is almost identical to
the code of ums(4).

The following diff merges uhts(4) into ums(4). There should be no
functional change. Please can people test for mouse regressions and
provide feedback. If this is good, then uhts(4) can disappear and the
commented lines in ums_match() can be restored.

I have CC'd people who may be interested.

Thanks

Index: share/man/man4/ums.4
===
RCS file: /cvs/src/share/man/man4/ums.4,v
retrieving revision 1.10
diff -u -p -r1.10 ums.4
--- share/man/man4/ums.426 Jun 2008 05:42:07 -  1.10
+++ share/man/man4/ums.418 Jul 2013 17:13:33 -
@@ -28,23 +28,30 @@
 .\ ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
 .\ POSSIBILITY OF SUCH DAMAGE.
 .\
-.Dd $Mdocdate: June 26 2008 $
+.Dd $Mdocdate: July 17 2013 $
 .Dt UMS 4
 .Os
 .Sh NAME
 .Nm ums
-.Nd USB mouse support
+.Nd USB HID mouse, touchscreen and digitiser support
 .Sh SYNOPSIS
 .Cd ums* at uhidev?
 .Cd wsmouse* at ums? mux 0
 .Sh DESCRIPTION
 The
 .Nm
-driver provides support for USB mice.
-Access to the mouse is through the
+driver provides support for USB HID mice, touchscreens and digitisers.
+Access to these devices is through the
 .Xr wscons 4
 driver.
+.Pp
+If the touchscreen sensor is poorly aligned, then
+.Xr xtsscale 1
+should be used to provide calibration results to the
+.Nm
+driver.
 .Sh SEE ALSO
+.Xr xtsscale 1 ,
 .Xr uhidev 4 ,
 .Xr usb 4 ,
 .Xr wsmouse 4
@@ -54,3 +61,16 @@ The
 driver
 first appeared in
 .Ox 2.8 .
+.Sh AUTHORS
+.An -nosplit
+HID touchscreen and digitiser support was written by
+.An Robert Nagy
+and
+.An Matthieu Herrb
+then later merged into the generic
+.Xr ums 4
+driver by
+.An Edd Barrett.
+.Sh CAVEATS
+Touchscreen and digitiser pressure sensitivity is not yet implemented.
+
Index: share/man/man4/usb.4
===
RCS file: /cvs/src/share/man/man4/usb.4,v
retrieving revision 1.140
diff -u -p -r1.140 usb.4
--- share/man/man4/usb.41 Jun 2013 17:04:57 -   1.140
+++ share/man/man4/usb.418 Jul 2013 17:13:33 -
@@ -252,7 +252,7 @@ HID touchscreen support
 keyboards that follow the boot protocol
 .It Xr ums 4
 .Tn USB
-mouse devices
+HID mouse, touchscreen and digitiser devices
 .It Xr uoaklux 4
 Toradex OAK USB illuminance sensor
 .It Xr uoakrh 4
Index: sys/dev/usb/hidms.c
===
RCS file: /cvs/src/sys/dev/usb/hidms.c,v
retrieving revision 1.4
diff -u -p -r1.4 hidms.c
--- sys/dev/usb/hidms.c 19 Aug 2011 18:46:22 -  1.4
+++ sys/dev/usb/hidms.c 18 Jul 2013 17:13:38 -
@@ -194,6 +194,27 @@ hidms_setup(struct device *self, struct 
break;
ms-sc_num_buttons = i - 1;
 
+   if (hid_locate(desc, dlen, HID_USAGE2(HUP_DIGITIZERS,
+   HUD_TIP_SWITCH), id, hid_input,
+   ms-sc_loc_btn[ms-sc_num_buttons], NULL)){
+   ms-sc_flags |= HIDMS_TIP;
+   ms-sc_num_buttons++;
+   }
+
+   if (hid_locate(desc, dlen, HID_USAGE2(HUP_DIGITIZERS,
+   HUD_ERASER), id, hid_input,
+   ms-sc_loc_btn[ms-sc_num_buttons], NULL)){
+   ms-sc_flags |= HIDMS_ERASER;
+   ms-sc_num_buttons++;
+   }
+
+   if (hid_locate(desc, dlen, HID_USAGE2(HUP_DIGITIZERS,
+   HUD_BARREL_SWITCH), id, hid_input,
+   ms-sc_loc_btn[ms-sc_num_buttons], NULL)){
+   ms-sc_flags |= HIDMS_BARREL;
+   ms-sc_num_buttons++;
+   }
+
/*
 * The Microsoft Wireless Notebook Optical Mouse seems to be in worse
 * shape than the Wireless Intellimouse 2.0, as its X, Y, wheel, and
@@ -216,6 +237,11 @@ hidms_setup(struct device *self, struct 
/* Parse descriptors to get touch panel bounds */
d = hid_start_parse(desc, dlen, hid_input);
while (hid_get_item(d, h)) {
+   if (h.kind != hid_input ||
+   HID_GET_USAGE_PAGE(h.usage) != HUP_GENERIC_DESKTOP)
+   continue;
+   DPRINTF((hidms: usage=0x%x range %d..%d\n,
+   h.usage, h.logical_minimum, h.logical_maximum));
switch (HID_GET_USAGE(h.usage)) {
case HUG_X:
if (ms-sc_flags  HIDMS_ABSX) {
@@ -255,6 +281,14 @@ hidms_attach(struct hidms *ms, const str
printf(, Z and W dir);
break;
}
+
+   if (ms-sc_flags  HIDMS_TIP)
+   printf(, tip);
+   if (ms-sc_flags  HIDMS_BARREL)
+   printf(, barrel);
+   if (ms-sc_flags  HIDMS_ERASER)
+   printf(, eraser);
+
printf(\n

Re: Stairstep mouse motion

[Edd Barrett]

Hi,

On Mon, Jul 08, 2013 at 08:26:56PM +0300, Henri Kemppainen wrote:
 Here's a diff that does just that.  If ws receives more than one
 delta along an axis, it will not sum these; each will go in a separate
 event.  But if it gets an X delta followed by an Y delta (or vice versa),
 these will be combined into a single event.

I have also been experiencing these jagged staircase lines on my x230t.
FWIW here are the outcomes of my experiments:

Prior to applying your diff (the most recent one):
Touchpad: smooth lines.
Nipple:   jagged lines.
Pen:  jagged lines.

After applying your diff:
Touchpad: smooth lines.
Nipple:   smooth lines.
Pen:  jagged lines.

I wonder if it is because the pen is an absolute pointing device.  You
probably need extra magic in the WSCONS_EVENT_MOUSE_ABSOLUTE_* cases.

-- 
Best Regards
Edd Barrett

http://www.theunixzoo.co.uk

Re: Wake from zzz causes panic on thinkpad x60

[Edd Barrett]

On Thu, Feb 28, 2013 at 04:59:12PM +, Edd Barrett wrote:
 Come to think of it those snaps are probably too old for TESTS. So when
 newer snaps hit the mirror I will re-run this test.

I can confirm that this is still a problem with Feb 28th amd64 snaps.

-- 
Best Regards
Edd Barrett

http://www.theunixzoo.co.uk

Wake from zzz causes panic on thinkpad x60

[Edd Barrett]

 1 int 16
Ricoh 5C832 Firewire rev 0x04 at pci3 dev 0 function 1 not configured
sdhc0 at pci3 dev 0 function 2 Ricoh 5C822 SD/MMC rev 0x21: apic 1 int 18
sdmmc0 at sdhc0
cardslot0 at cbb0 slot 0 flags 0
cardbus0 at cardslot0: bus 6 device 0 cacheline 0x0, lattimer 0xb0
pcmcia0 at cardslot0
pcib0 at pci0 dev 31 function 0 Intel 82801HEM LPC rev 0x03
pciide0 at pci0 dev 31 function 1 Intel 82801HBM IDE rev 0x03: DMA, channel 0 
configured to compatibility, channel 1 configured to compatibility
pciide0: channel 0 disabled (no drives)
pciide0: channel 1 ignored (disabled)
ahci0 at pci0 dev 31 function 2 Intel 82801HBM AHCI rev 0x03: msi, AHCI 1.1
scsibus0 at ahci0: 32 targets
sd0 at scsibus0 targ 0 lun 0: ATA, HITACHI HTS54258, BBBZ SCSI3 0/direct 
fixed naa.5000cca52fc8f3d9
sd0: 76319MB, 512 bytes/sector, 156301488 sectors
ichiic0 at pci0 dev 31 function 3 Intel 82801H SMBus rev 0x03: apic 1 int 23
iic0 at ichiic0
usb2 at uhci0: USB revision 1.0
uhub2 at usb2 Intel UHCI root hub rev 1.00/1.00 addr 1
usb3 at uhci1: USB revision 1.0
uhub3 at usb3 Intel UHCI root hub rev 1.00/1.00 addr 1
usb4 at uhci2: USB revision 1.0
uhub4 at usb4 Intel UHCI root hub rev 1.00/1.00 addr 1
usb5 at uhci3: USB revision 1.0
uhub5 at usb5 Intel UHCI root hub rev 1.00/1.00 addr 1
isa0 at pcib0
isadma0 at isa0
pckbc0 at isa0 port 0x60/5
pckbd0 at pckbc0 (kbd slot)
pckbc0: using irq 1 for kbd slot
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pms0 at pckbc0 (aux slot)
pckbc0: using irq 12 for aux slot
wsmouse0 at pms0 mux 0
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
aps0 at isa0 port 0x1600/31
mtrr: Pentium Pro MTRR support
rl0 at cardbus0 dev 0 function 0 Realtek 8139 rev 0x10: irq 10, address 
00:0a:cd:1d:24:c6
rlphy0 at rl0 phy 0: RTL internal PHY
ugen0 at uhub2 port 1 Broadcom Corp BCM2045B rev 2.00/1.00 addr 2
ugen1 at uhub2 port 2 STMicroelectronics Biometric Coprocessor rev 1.00/0.01 
addr 3
uhidev0 at uhub4 port 1 configuration 1 interface 0 Fujitsu Component Type 6 
Keyboard rev 1.00/1.01 addr 2
uhidev0: iclass 3/1
ukbd0 at uhidev0: 8 variable keys, 6 key codes, country code 32
wskbd1 at ukbd0 mux 1
wskbd1: connecting to wsdisplay0
uhidev1 at uhub4 port 2 configuration 1 interface 0 Logitech Optical USB 
Mouse rev 2.00/3.40 addr 3
uhidev1: iclass 3/1
ums0 at uhidev1: 3 buttons, Z dir
wsmouse1 at ums0 mux 0
vscsi0 at root
scsibus1 at vscsi0: 256 targets
softraid0 at root
scsibus2 at softraid0: 256 targets
root on sd0a (c135b3cdcf62ee05.a) swap on sd0b dump on sd0b

-- 
Best Regards
Edd Barrett

http://www.theunixzoo.co.uk

Re: iwn0 firmware errors

[Edd Barrett]

On Sun, Feb 12, 2012 at 09:24:17PM +0100, Sebastian Benoit wrote:
 i was using a x61s until a month ago. I had these errors too, but only with
 certain wifi networks (specifically 2 events with 30+ access points and 1000+
 wifi users) using cisco ap's. I never saw these errors somewhere else.

Hmm. I am seeing the error connecting to a soekris I set up myself. I am
the only client on this. It has a ral card in hostap mode.

It may be related to power saving? Pure speculation ofcourse -- I know
nothing about how these devices work internally.

-- 
Best Regards
Edd Barrett

http://www.theunixzoo.co.uk

Re: xf86-video-intel driver broken after 2011/11/29

[Edd Barrett]

On Sat, Feb 11, 2012 at 01:04:52AM +, Owain Ainsworth wrote:
 For some stupid reason the x driver is still trying to submit commands
 to the gpu while vt switched (this is verboten, and returns with EBUSY).
 What are you running in X at the time? I can't reproduce this issue to
 try and fix it.

I have the same issue.

I mailed it to x11@ a few days ago:
http://marc.info/?l=openbsd-x11m=132865830223969w=2

And yep, I use startx.

-- 
Best Regards
Edd Barrett

http://www.theunixzoo.co.uk

iwn0 firmware errors

[Edd Barrett]

 function 2 Ricoh 5C822 SD/MMC rev 0x21: apic 1 int 18
sdmmc0 at sdhc0
cardslot0 at cbb0 slot 0 flags 0
cardbus0 at cardslot0: bus 6 device 0 cacheline 0x0, lattimer 0xb0
pcmcia0 at cardslot0
pcib0 at pci0 dev 31 function 0 Intel 82801HEM LPC rev 0x03
pciide0 at pci0 dev 31 function 1 Intel 82801HBM IDE rev 0x03: DMA, channel 0 
configured to compatibility, channel 1 configured to compatibility
pciide0: channel 0 disabled (no drives)
pciide0: channel 1 ignored (disabled)
ahci0 at pci0 dev 31 function 2 Intel 82801HBM AHCI rev 0x03: msi, AHCI 1.1
scsibus0 at ahci0: 32 targets
sd0 at scsibus0 targ 0 lun 0: ATA, HITACHI HTS54258, BBBZ SCSI3 0/direct 
fixed naa.5000cca52fc8f3d9
sd0: 76319MB, 512 bytes/sector, 156301488 sectors
ichiic0 at pci0 dev 31 function 3 Intel 82801H SMBus rev 0x03: apic 1 int 23
iic0 at ichiic0
usb2 at uhci0: USB revision 1.0
uhub2 at usb2 Intel UHCI root hub rev 1.00/1.00 addr 1
usb3 at uhci1: USB revision 1.0
uhub3 at usb3 Intel UHCI root hub rev 1.00/1.00 addr 1
usb4 at uhci2: USB revision 1.0
uhub4 at usb4 Intel UHCI root hub rev 1.00/1.00 addr 1
usb5 at uhci3: USB revision 1.0
uhub5 at usb5 Intel UHCI root hub rev 1.00/1.00 addr 1
isa0 at pcib0
isadma0 at isa0
pckbc0 at isa0 port 0x60/5
pckbd0 at pckbc0 (kbd slot)
pckbc0: using irq 1 for kbd slot
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pms0 at pckbc0 (aux slot)
pckbc0: using irq 12 for aux slot
wsmouse0 at pms0 mux 0
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
aps0 at isa0 port 0x1600/31
npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
mtrr: Pentium Pro MTRR support
ugen0 at uhub2 port 1 Broadcom Corp BCM2045B rev 2.00/1.00 addr 2
ugen1 at uhub2 port 2 STMicroelectronics Biometric Coprocessor rev 1.00/0.01 
addr 3
vscsi0 at root
scsibus1 at vscsi0: 256 targets
softraid0 at root
scsibus2 at softraid0: 256 targets
root on sd0a (c135b3cdcf62ee05.a) swap on sd0b dump on sd0b
iwn0: fatal firmware error
firmware error log:
  error type  = NMI_INTERRUPT_WDG (0x0004)
  program counter = 0x046C
  source line = 0x00D0
  error data  = 0x00020203
  branch link = 0x2F3E04C2
  interrupt link  = 0x06DE2FCE
  time= 3303793537
driver status:
  tx ring  0: qid=0  cur=10  queued=0  
  tx ring  1: qid=1  cur=0   queued=0  
  tx ring  2: qid=2  cur=0   queued=0  
  tx ring  3: qid=3  cur=0   queued=0  
  tx ring  4: qid=4  cur=45  queued=0  
  tx ring  5: qid=5  cur=0   queued=0  
  tx ring  6: qid=6  cur=0   queued=0  
  tx ring  7: qid=7  cur=0   queued=0  
  tx ring  8: qid=8  cur=0   queued=0  
  tx ring  9: qid=9  cur=0   queued=0  
  tx ring 10: qid=10 cur=0   queued=0  
  tx ring 11: qid=11 cur=0   queued=0  
  tx ring 12: qid=12 cur=0   queued=0  
  tx ring 13: qid=13 cur=0   queued=0  
  tx ring 14: qid=14 cur=0   queued=0  
  tx ring 15: qid=15 cur=0   queued=0  
  rx ring: cur=11
  802.11 state 4

-- 
Best Regards
Edd Barrett

http://www.theunixzoo.co.uk

Re: fix ral (and maybe other cards) hostap mode

[Edd Barrett]

I will be willing to test any diffs relating to this. I have some soekris
with Ral cards which i intended to use in hostap mode.

Cheers
On Jan 16, 2012 12:13 PM, Steven Chamberlain ste...@pyro.eu.org wrote:

 On 16/01/12 09:47, Sebastian Reitenbach wrote:
  this is a followup on the misc@ problem with ral in hopstap mode on
 -current thread.

 Thank you!  I wasn't subscribed to that list but I mentioned this on
 bugs@ on 2011-12-10, rum: multiple issues.


  tcpdump -n -i ral0 -y IEEE802_11_RADIO -vvv
  ...
  17:24:49.225241 802.11: probe request, radiotap v0, tsf 366153760136,
 1Mbit/s, chan 1, 11g, antenna 1, signal 65dB
  17:24:49.225311 802.11: deauthentication, authentication expired,
 radiotap v0, 1Mbit/s, chan 1, 11g, antenna 1
  17:24:49.225347 802.11: deauthentication, authentication expired,
 radiotap v0, 1Mbit/s, chan 1, 11g, antenna 1

 Same thing I was seeing!  I think the flood of deauths from your AP
 implies the node cache is full, and for some reason it tries but fails
 to flush anything.  At that point no station can (re)associate.


  So adding this rc=1 on Friday evening, now over the whole weekend, up to
 this morning, my wireless is working stable now,
  as it was before with the 4.2.

 I don't understand how setting 'rc = 1' for beacons/proberesps helped
 (non-zero means yes, needs an rxnode);  I would have expected that to
 fill the node cache more quickly, and so trigger the bug more often.
 Figuring this out might be key to understanding some underlying problem...


  This should prevent entries of the form:
  nwid  chan 3 bssid 00:01:02:03:04:05 0dB 54M
  in ifconfig if0 scan output, like reported by Rivo Nurges.

 Have you seen anything like that yourself yet?


 I found that raising IEEE80211_CACHE_SIZE from its default of 100 in
 ieee80211_node.h reduces how often the problem occurs, but is not in any
 way a sensible fix.  When debugging the issue it would probably help to
 lower that value drastically so it is easier to trigger it.

 Regards,
 --
 Steven Chamberlain
 ste...@pyro.eu.org

Re: small change to the scandir(3) manual page

[Edd Barrett]

On Fri, Jan 20, 2012 at 02:34:51PM +0100, Tobias Ulmer wrote:
 - builds an array of pointers to variable-size directory entries using
   malloc(3)

^ Something like this could work. Perhaps also a note that we do this because
POSIX says so.

-- 
Best Regards
Edd Barrett

http://www.theunixzoo.co.uk

[panc...@nopcode.org: License]

[Edd Barrett]

Hi guys,

A port I am maintaining uses our file(1) implementation. A debian
dev who was packaging this thinks he has spotted a license bug.

Said I would forward his mail onto OpenBSD, so here it is.

Discuss.

- Forwarded message from pancake panc...@nopcode.org -

Date: Thu, 13 Oct 2011 01:19:26 +0200
From: pancake panc...@nopcode.org
To: Edd Barrett vex...@gmail.com
Subject: License
X-Mailer: iPhone Mail (8C148)

Debian packager has reported a bug in magic license.

COPYRIGHT file contains the 4th clause bsd which is gpl incompatible. The thing 
is that *.c files include the 3clause bsd license which is ok.

Can i remove the 4th clause from the copyright file? This should be reported to 
openbsd too as long as its inconsistent and can be problematic.

- End forwarded message -

-- 
Best Regards
Edd Barrett

http://www.theunixzoo.co.uk

Re: [panc...@nopcode.org: License]

[Edd Barrett]

On Fri, Oct 14, 2011 at 04:19:58PM -0400, Ted Unangst wrote:
  A port I am maintaining uses our file(1) implementation. A debian
  dev who was packaging this thinks he has spotted a license bug.
  
  Said I would forward his mail onto OpenBSD, so here it is.
  
  Discuss.
 
 What COPYRIGHT file?  There's no such file in my src/usr.bin/file.  And
 the *.c files are all 2 clause, not 3.

Yah, I am not sure what he is on about either now. I don't see a
COPYRIGHT file.

-- 
Best Regards
Edd Barrett

http://www.theunixzoo.co.uk

Re: fix a seg and minor improvements to config(8)

[Edd Barrett]

On Sun, Oct 02, 2011 at 07:22:07AM +0100, Nicholas Marriott wrote:
 Hi
 
 All but the stat bit looks fine. How do you reproduce the problems? It
 seems to fail just fine without it.
 
 $ config -f /x
 config: cannot read /x: No such file or directory

To reproduce these, you would use -e.

If you pass a non-existent file:

% config -e /missing_file
config: no supported exec type

If you pass in a non-kernel binary:

% file ~/a
/home/edd/a: ELF 32-bit LSB executable, Intel 80386, version 1, for
OpenBSD, dynamically linked (uses shared libs), not stripped
% config -e ~/a
(null)warning: no output file specified
WARNING this kernel doesn't contain all information needed!
WARNING the commands add and change might not work.
WARNING this kernel doesn't support pseudo devices.
WARNING this kernel doesn't support modification of BUFCACHEPERCENT.
WARNING this kernel doesn't support modification of NKMEMPAGES.
zsh: segmentation fault  config -e ~/a

Cheers

-- 
Best Regards
Edd Barrett

http://www.theunixzoo.co.uk

Re: fix a seg and minor improvements to config(8)

[Edd Barrett]

===
RCS file: /cvs/src/usr.sbin/config/main.c,v
retrieving revision 1.42
diff -u -r1.42 main.c
--- main.c  15 Apr 2011 02:48:14 -  1.42
+++ main.c  2 Oct 2011 14:32:27 -
@@ -44,13 +44,15 @@
 #include sys/types.h
 #include sys/stat.h
 #include sys/param.h
+
 #include ctype.h
+#include err.h
 #include errno.h
 #include stdio.h
-#include err.h
 #include stdlib.h
 #include string.h
 #include unistd.h
+
 #include config.h
 
 intfirstfile(const char *);
Index: misc.c
===
RCS file: /cvs/src/usr.sbin/config/misc.c,v
retrieving revision 1.8
diff -u -r1.8 misc.c
--- misc.c  27 Oct 2009 23:59:51 -  1.8
+++ misc.c  2 Oct 2011 14:32:27 -
@@ -26,9 +26,10 @@
  */
 
 #include sys/types.h
+
+#include ctype.h
 #include err.h
 #include stdio.h
-#include ctype.h
 #include stdlib.h
 #include string.h
 
Index: mkheaders.c
===
RCS file: /cvs/src/usr.sbin/config/mkheaders.c,v
retrieving revision 1.18
diff -u -r1.18 mkheaders.c
--- mkheaders.c 28 Jun 2003 04:55:07 -  1.18
+++ mkheaders.c 2 Oct 2011 14:32:27 -
@@ -42,11 +42,13 @@
  */
 
 #include sys/param.h
+
 #include ctype.h
 #include errno.h
 #include stdio.h
 #include stdlib.h
 #include string.h
+
 #include config.h
 
 static int emitcnt(struct nvlist *);
Index: mkioconf.c
===
RCS file: /cvs/src/usr.sbin/config/mkioconf.c,v
retrieving revision 1.30
diff -u -r1.30 mkioconf.c
--- mkioconf.c  16 Jul 2011 11:34:43 -  1.30
+++ mkioconf.c  2 Oct 2011 14:32:27 -
@@ -42,10 +42,12 @@
  */
 
 #include sys/param.h
+
 #include errno.h
 #include stdio.h
 #include stdlib.h
 #include string.h
+
 #include config.h
 
 /*
Index: mkmakefile.c
===
RCS file: /cvs/src/usr.sbin/config/mkmakefile.c,v
retrieving revision 1.35
diff -u -r1.35 mkmakefile.c
--- mkmakefile.c2 Jun 2010 20:42:17 -   1.35
+++ mkmakefile.c2 Oct 2011 14:32:27 -
@@ -42,12 +42,14 @@
  */
 
 #include sys/param.h
+
 #include ctype.h
 #include err.h
 #include errno.h
 #include stdio.h
 #include stdlib.h
 #include string.h
+
 #include config.h
 #include sem.h
 
Index: mkswap.c
===
RCS file: /cvs/src/usr.sbin/config/mkswap.c,v
retrieving revision 1.12
diff -u -r1.12 mkswap.c
--- mkswap.c28 Jun 2003 04:55:07 -  1.12
+++ mkswap.c2 Oct 2011 14:32:29 -
@@ -42,10 +42,12 @@
  */
 
 #include sys/param.h
+
 #include errno.h
 #include stdio.h
 #include stdlib.h
 #include string.h
+
 #include config.h
 #include sem.h
 
Index: pack.c
===
RCS file: /cvs/src/usr.sbin/config/pack.c,v
retrieving revision 1.15
diff -u -r1.15 pack.c
--- pack.c  4 Jan 2004 00:47:01 -   1.15
+++ pack.c  2 Oct 2011 14:32:29 -
@@ -42,8 +42,10 @@
  */
 
 #include sys/param.h
+
 #include stdlib.h
 #include string.h
+
 #include config.h
 
 /*
Index: sem.c
===
RCS file: /cvs/src/usr.sbin/config/sem.c,v
retrieving revision 1.31
diff -u -r1.31 sem.c
--- sem.c   24 Mar 2008 21:35:03 -  1.31
+++ sem.c   2 Oct 2011 14:32:29 -
@@ -42,11 +42,13 @@
  */
 
 #include sys/param.h
+
 #include ctype.h
+#include err.h
 #include stdio.h
 #include stdlib.h
 #include string.h
-#include err.h
+
 #include config.h
 #include sem.h
 
Index: ukc.c
===
RCS file: /cvs/src/usr.sbin/config/ukc.c,v
retrieving revision 1.17
diff -u -r1.17 ukc.c
--- ukc.c   2 Oct 2011 10:10:30 -   1.17
+++ ukc.c   2 Oct 2011 14:32:29 -
@@ -29,8 +29,8 @@
 #include sys/ioctl.h
 
 #include err.h
-#include kvm.h
 #include fcntl.h
+#include kvm.h
 #include limits.h
 #include nlist.h
 #include stdio.h
Index: ukcutil.c
===
RCS file: /cvs/src/usr.sbin/config/ukcutil.c,v
retrieving revision 1.19
diff -u -r1.19 ukcutil.c
--- ukcutil.c   6 Apr 2011 11:36:26 -   1.19
+++ ukcutil.c   2 Oct 2011 14:32:29 -
@@ -27,6 +27,7 @@
 #include sys/types.h
 #include sys/time.h
 #include sys/device.h
+
 #include limits.h
 #include nlist.h
 #include stdio.h
Index: util.c
===
RCS file: /cvs/src/usr.sbin/config/util.c,v
retrieving revision 1.12
diff -u -r1.12 util.c
--- util.c  28 Jun 2003 04:55:07 -  1.12
+++ util.c  2 Oct 2011 14:32:29 -
@@ -42,11 +42,13 @@
  */
 
 #include sys/types.h
+
 #include ctype.h
+#include stdarg.h
 #include stdio.h
 #include stdlib.h
 #include string.h
-#include stdarg.h
+
 #include config.h
 
 static void nomem(void);

-- 
Best Regards
Edd Barrett

http://www.theunixzoo.co.uk

fix a seg and minor improvements to config(8)

[Edd Barrett]

Evening,

When using `config -e`:
 * Don't print a NULL pointer if binary loaded is not a kernel.
 * Don't segfault of binary loaded is not a kernel.
 * Report non-existent kernel via a preliminary stat().
 * Make a warning look like the rest.

 OK?

Index: exec.c
===
RCS file: /cvs/src/usr.sbin/config/exec.c,v
retrieving revision 1.7
diff -u -r1.7 exec.c
--- exec.c  27 Oct 2009 23:59:51 -  1.7
+++ exec.c  28 Sep 2011 01:19:49 -
@@ -26,6 +26,8 @@
 
 #include err.h
 #include sys/types.h
+#include sys/stat.h
+#include fcntl.h
 #include stdio.h
 
 #ifdef AOUT_SUPPORT
@@ -109,6 +111,11 @@
 void
 loadkernel(char *file)
 {
+   struct stat st;
+
+   if (stat(file, st) == -1)
+   err(1, cannot stat '%s', file);
+
current_exec = -1;
 
 #ifdef AOUT_SUPPORT
Index: ukc.c
===
RCS file: /cvs/src/usr.sbin/config/ukc.c,v
retrieving revision 1.16
diff -u -r1.16 ukc.c
--- ukc.c   10 Dec 2009 22:07:19 -  1.16
+++ ukc.c   28 Sep 2011 01:19:49 -
@@ -114,10 +114,8 @@
}
}
 
-   printf(%s, adjust((caddr_t)nl[P_VERSION].n_value));
-
if (force == 0  outfile == NULL)
-   printf(warning: no output file specified\n);
+   printf(WARNING no output file specified\n);
 
if (nl[IA_EXTRALOC].n_type == 0 || nl[I_NEXTRALOC].n_type == 0 ||
nl[I_UEXTRALOC].n_type == 0 || nl[I_HISTLEN].n_type == 0 ||
@@ -155,6 +153,8 @@
process_history(histlen, history);
}
 
+   printf(%s, adjust((caddr_t)nl[P_VERSION].n_value));
+
if (config()) {
if (force == 0  outfile == NULL) {
fprintf(stderr, not forced\n);
@@ -184,7 +184,9 @@
struct winsize w;
 #endif
 
-   cd = get_cfdata(0); /* get first item */
+   if ((cd = get_cfdata(0)) == NULL)   /* get first item */
+   errx(1, failed to get first cfdata);
+
while (cd-cf_attach != 0) {
maxdev = i;
totdev = i;

-- 
Best Regards
Edd Barrett

file(1): prevent printing unknown magic filename

[Edd Barrett]

Hi,

An upstream of one of the ports I work on (radare2) has imported our file(1)
implementation and claims to have found bugs. This is the first:

'ms-file' will only be assigned to 'fn' after a call to apprentice_load() and
ultimately load_1(), so the file_magwarn() at line 274 would report the default
filename unknown.

We can trigger this behaviour by executing `file -c`:
unknown, 0: Warning: using regular magic file `/etc/magic'

Is it a bug?

Index: apprentice.c
===
RCS file: /cvs/src/usr.bin/file/apprentice.c,v
retrieving revision 1.29
diff -u -r1.29 apprentice.c
--- apprentice.c11 Nov 2009 16:21:51 -  1.29
+++ apprentice.c22 Sep 2011 14:27:17 -
@@ -258,6 +258,7 @@
return -1;
}
 
+   ms-file = fn;
if (action == FILE_COMPILE) {
rv = apprentice_load(ms, magic, nmagic, fn, action);
if (rv != 0)
-- 
Best Regards
Edd Barrett

http://www.theunixzoo.co.uk

watchdog timeouts on alc0

[Edd Barrett]

usb3 at uhci2: USB revision 1.0
uhub3 at usb3 Intel UHCI root hub rev 1.00/1.00 addr 1
usb4 at uhci3: USB revision 1.0
uhub4 at usb4 Intel UHCI root hub rev 1.00/1.00 addr 1
isa0 at pcib0
isadma0 at isa0
pckbc0 at isa0 port 0x60/5
pckbd0 at pckbc0 (kbd slot)
pckbc0: using irq 1 for kbd slot
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pms0 at pckbc0 (aux slot)
pckbc0: using irq 12 for aux slot
wsmouse0 at pms0 mux 0
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
mtrr: Pentium Pro MTRR support
urtwn0 at uhub0 port 3 Realtek 802.11n WLAN Adapter rev 2.00/2.00 addr 2
urtwn0: MAC/BB RTL8188CUS, RF 6052 1T1R, address ff:ff:ff:ff:ff:ff
uvideo0 at uhub0 port 4 configuration 1 interface 0 Y2B2D0JXB WebCam rev 
2.00/0.04 addr 3
video0 at uvideo0
vscsi0 at root
scsibus1 at vscsi0: 256 targets
softraid0 at root
scsibus2 at softraid0: 256 targets
root on sd0a (2d8f502a56cb1ab6.a) swap on sd0b dump on sd0b
alc0: watchdog timeout (missed link)
alc0: watchdog timeout
alc0: could not disable RxQ/TxQ (0x0008)!
alc0: could not disable Rx/Tx MAC(0x0008)!

-- 
Best Regards
Edd Barrett

http://www.theunixzoo.co.uk

Re: alc(4) support for Atheros AR815x

[Edd Barrett]

On Wed, May 04, 2011 at 09:32:47AM +0200, Gabriel Linder wrote:
 I have an alc device too, and would like to fix it. Starting from
 kevlo's diff I updated it some month ago to compile, and compared
 FreeBSD driver to add some more things, finding some bugs in their
 driver (reported and fixed in their tree). I now have a working alc,
 with and without cable at boot or after boot but I have to update my
 tree (lagging some months behind) and probably fix some conflicts
 before posting an up to date diff. It would help me if someone could
 answer my silly questions about differences between FreeBSD and
 OpenBSD internals, by the way. Slides at
 http://www.openbsd.org/papers/ were very useful but do not cover
 this :)

FYI, Marius just made a huge commit which includes some alc/PHY code. I
don't know if it is relevent.
http://svnweb.freebsd.org/base?view=revisionrevision=221407

-- 
Best Regards
Edd Barrett

http://www.theunixzoo.co.uk

Re: Network Interface Daemon and ifconfig header file

[Edd Barrett]

Perhaps the functions belong in a shared object?
On May 4, 2011 10:46 AM, Rafael Sadowski raf...@sizeofvoid.org wrote:
 Hello @tech and all honorable OpenBSD Developer,

 first of all, I happy about any help or helpful advice!

 Based on Edd Barrett (edd@) idea[1] to develop a Network Interface
 Daemon for OpenBSD, I'm currently hack on it.

 My first really huge problem is similar to Edd thoughts:

 I guess this would mean moving all of the functions apart from main()
 from ifconfig.c into another file (complete with header), so that we can
 call them from the new ifconfigd? I'm no expert

 My first initial solution was similar. I created ifconfig.h. This diff
 is just for example. It works fine with ifconfig but how can I use it
 from another directory like src/usr.sbin/ifconfigd.

 My first try with modify[2] PATH and -L and -I CFLAGS doesn't work. It
 break with suff like this (I understand the error but I not know any
 solution):


 cc -o ifconfigd parse.o log.o control.o ifconfigd.o ifconfigde.o
ifconfig.o bioctl.o pbkdf2.o -levent -lutil
 ifconfig.o(.text+0x2220): In function `usage':
 : multiple definition of `usage'[1;3B
 ifconfigd.o(.text+0x400): first defined here
 /usr/bin/ld: Warning: size of symbol `usage' changed from 38 in
ifconfigd.o to 35 in ifconfig.o
 ifconfig.o(.text+0xa440): In function `main':
 : multiple definition of `main'
 ifconfigd.o(.text+0x430): first defined here
 /usr/bin/ld: Warning: size of symbol `main' changed from 883 in
ifconfigd.o to 1790 in ifconfig.o
 bioctl.o(.text+0x1fa0): In function `usage':
 : multiple definition of `usage'
 ifconfigd.o(.text+0x400): first defined here
 /usr/bin/ld: Warning: size of symbol `usage' changed from 35 in
ifconfigd.o to 41 in bioctl.o
 bioctl.o(.text+0x1fd0): In function `main':
 : multiple definition of `main'
 ifconfigd.o(.text+0x430): first defined here
 /usr/bin/ld: Warning: size of symbol `main' changed from 1790 in
ifconfigd.o to 1151 in bioctl.o
 ifconfig.o(.text+0x6c7b): In function `getinfo':
 : undefined reference to `is_bridge'
 ifconfig.o(.text+0x968b): In function `status':
 : undefined reference to `is_bridge'
 ifconfig.o(.text+0x990a): In function `status':
 : undefined reference to `bridge_status'
 ifconfig.o(.text+0xaa20): In function `main':
 : undefined reference to `bridge_rule'
 ifconfig.o(.rodata+0x12d0): undefined reference to `bridge_add'

 ... (and more undefined reference to ...)

 collect2: ld returned 1 exit status
 *** Error code 1

 [1]
http://www.theunixzoo.co.uk/wiki/doku.php?id=edd:openbsd#network_interface_daemon_ifconfigd
 [2 Makefile Section:

 .PATH: ${.CURDIR} ${.CURDIR}/../../sbin/ifconfig
${.CURDIR}/../../sbin/bioctl

 PROG= ifconfigd SRCS= parse.y log.c control.c ifconfigd.c ifconfigde.c
 SRCS+= ifconfig.c bioctl.c pbkdf2.c

 LDADD+= -levent -lutil

 MAN= ifconfigd.8 ifconfigd.conf.5

 CFLAGS+= -DINET6 -I${.CURDIR}/../bioctl -I${.CURDIR}/../../sbin/ifconfig
 CFLAGS+= -L${.CURDIR}/../bioctl -L${.CURDIR}/../../sbin/ifconfig


 Index: ifconfig/ifconfig.c
 ===
 RCS file: /cvs/src/sbin/ifconfig/ifconfig.c,v
 retrieving revision 1.246
 diff -u -r1.246 ifconfig.c
 --- ifconfig/ifconfig.c 23 Mar 2011 18:36:41 - 1.246
 +++ ifconfig/ifconfig.c 4 May 2011 09:03:50 -
 @@ -104,22 +104,8 @@
 #include unistd.h
 #include ifaddrs.h

 -#include brconfig.h
 -#include pbkdf2.h
 +#include ifconfig.h

 -struct ifreq ifr, ridreq;
 -struct in_aliasreq in_addreq;
 -#ifdef INET6
 -struct in6_ifreq ifr6;
 -struct in6_ifreq in6_ridreq;
 -struct in6_aliasreq in6_addreq;
 -#endif /* INET6 */
 -struct sockaddr_in netmask;
 -
 -#ifndef SMALL
 -struct ifaliasreq addreq;
 -struct netrange at_nr; /* AppleTalk net range */
 -#endif /* SMALL */

 char name[IFNAMSIZ];
 int flags, xflags, setaddr, setipdst, doalias;
 @@ -137,440 +123,9 @@
 int shownet80211chans;
 int shownet80211nodes;

 -void notealias(const char *, int);
 -void setifaddr(const char *, int);
 -void setifrtlabel(const char *, int);
 -void setiflladdr(const char *, int);
 -void setifdstaddr(const char *, int);
 -void setifflags(const char *, int);
 -void setifxflags(const char *, int);
 -void setifbroadaddr(const char *, int);
 -void setifmtu(const char *, int);
 -void setifnwid(const char *, int);
 -void setifbssid(const char *, int);
 -void setifnwkey(const char *, int);
 -void setifwpa(const char *, int);
 -void setifwpaprotos(const char *, int);
 -void setifwpaakms(const char *, int);
 -void setifwpaciphers(const char *, int);
 -void setifwpagroupcipher(const char *, int);
 -void setifwpakey(const char *, int);
 -void setifchan(const char *, int);
 -void setifscan(const char *, int);
 -void setiftxpower(const char *, int);
 -void setifnwflag(const char *, int);
 -void unsetifnwflag(const char *, int);
 -void setifnetmask(const char *, int);
 -void setifprefixlen(const char *, int);
 -void setatrange(const char *, int);
 -void setatphase(const char *, int);
 -void settunnel(const char

Re: alc(4) support for Atheros AR815x

[Edd Barrett]

On Mon, May 02, 2011 at 11:02:41AM +0100, Stuart Henderson wrote:
 On 2011/05/02 01:16, Edd Barrett wrote:
  On Sun, May 01, 2011 at 08:10:56PM +0100, Stuart Henderson wrote:
   On 2011/05/01 18:35, Edd Barrett wrote:
I have acquired a netboot (packard bell dot s), which I think uses this 
NIC. Is
there an updated diff?
   
   Yes I just took the 2 minutes it took to apply it and fix
   the minor conflicts and linewrapping issue with the diff.
   Untested beyond it builds.
  
  Stu's diff seems to work,
 
 kevlo's diff really..
 
  although the first time i booted my bsd.rd I was
  unable to install due to: 
  
  alc0: watchdog timeout (missed link)
 
 I had a report of a system with alc(4) which only works if the
 cable is connected at boot. Is that what happens for you too?
 If so, try this, similar to freebsd r214542.

This change was already included in kevlo's diff. It does seem like it could
still be related to the link state. I managed to get another error by:

 * booting with no cable plugged in.
 * once the system is up, connect a cable
 * run dhclient alc0

 Then as DHREQUESTs were sent some kernel messages:

alc0: watchdog timeout
alc0: could not disable RxQ/TxQ (0x0008)!
alc0: could not disable RxQ/TxQ MAC(0x0008)!

Might give some clues?

After those messages, the interface does infact recieve a DHCP address and the
interface does work. So I would not let this hold back the commit.

-- 
Best Regards
Edd Barrett

http://www.theunixzoo.co.uk

Re: alc(4) support for Atheros AR815x

[Edd Barrett]

On Sun, May 01, 2011 at 08:10:56PM +0100, Stuart Henderson wrote:
 On 2011/05/01 18:35, Edd Barrett wrote:
  I have acquired a netboot (packard bell dot s), which I think uses this 
  NIC. Is
  there an updated diff?
 
 Yes I just took the 2 minutes it took to apply it and fix
 the minor conflicts and linewrapping issue with the diff.
 Untested beyond it builds.

Stu's diff seems to work, although the first time i booted my bsd.rd I was
unable to install due to: 

alc0: watchdog timeout (missed link)

I rebooted and tried again and it all went smoothly. The system booted
multiuser and I am able to install packages over the wire.

The BCM4313 wireless is unsupported, but that is another story. If anyone knows
anything about support for this card can they mail me off-list.

Cheers

OpenBSD 4.9-current (GENERIC.MP) #0: Mon May  2 00:51:41 BST 2011
root@ire.config:/usr/src/sys/arch/i386/compile/GENERIC.MP
cpu0: Intel(R) Atom(TM) CPU N455 @ 1.66GHz (GenuineIntel 686-class) 1.67 GHz
cpu0: 
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,EST,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE
real mem  = 1061302272 (1012MB)
avail mem = 1033764864 (985MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 01/10/11, SMBIOS rev. 2.6 @ 0xe8080 (36 
entries)
bios0: vendor Packard Bell version V3.14(DDR3) date 01/10/2011
bios0: Packard Bell DOTS E2
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP HPET APIC MCFG SLIC BOOT SSDT WDAT
acpi0: wakeup devices UHC1(S3) UHC2(S3) UHC3(S3) UHC4(S3) ECHI(S3) EXP1(S4) 
EXP2(S0) EXP3(S4) EXP4(S4) AZAL(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 14318179 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: apic clock running at 166MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Atom(TM) CPU N455 @ 1.66GHz (GenuineIntel 686-class) 1.67 GHz
cpu1: 
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,EST,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE
ioapic0 at mainbus0: apid 4 pa 0xfec0, version 20, 24 pins
ioapic0: misconfigured as apic 0, remapped to apid 4
acpimcfg0 at acpi0 addr 0xe000, bus 0-255
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (EXP1)
acpiprt2 at acpi0: bus 2 (EXP2)
acpiprt3 at acpi0: bus -1 (EXP3)
acpiprt4 at acpi0: bus -1 (EXP4)
acpiec0 at acpi0
acpicpu0 at acpi0: C3, C2, C1, PSS
acpicpu1 at acpi0: C3, C2, C1, PSS
acpipwrres0 at acpi0: FN00
acpitz0 at acpi0: critical temperature 100 degC
acpibtn0 at acpi0: PWRB
acpibtn1 at acpi0: SLPB
acpibtn2 at acpi0: LID0
acpibat0 at acpi0: BAT0 model 13848628933250113 type Lion oem SANYO 
acpiac0 at acpi0: AC unit online
acpivideo0 at acpi0: OVGA
acpivout0 at acpivideo0: DD02
bios0: ROM list: 0xc/0xda00! 0xce000/0x1000
cpu0: Enhanced SpeedStep 1663 MHz: speeds: 1666, 1333, 1000 MHz
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 Intel Pineview DMI rev 0x00
vga1 at pci0 dev 2 function 0 Intel Pineview Video rev 0x00
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
intagp0 at vga1
agp0 at intagp0: aperture at 0x4000, size 0x1000
inteldrm0 at vga1: apic 4 int 16
drm0 at inteldrm0
Intel Pineview Video rev 0x00 at pci0 dev 2 function 1 not configured
azalia0 at pci0 dev 27 function 0 Intel 82801GB HD Audio rev 0x02: apic 4 int 
19
azalia0: codecs: Realtek ALC272
audio0 at azalia0
ppb0 at pci0 dev 28 function 0 Intel 82801GB PCIE rev 0x02: apic 4 int 16
pci1 at ppb0 bus 1
alc0 at pci1 dev 0 function 0 Attansic Technology L2C rev 0xc1: apic 4 int 
16, address 1c:75:08:d5:53:c4
atphy0 at alc0 phy 0: F2 10/100 PHY, rev. 4
ppb1 at pci0 dev 28 function 1 Intel 82801GB PCIE rev 0x02: apic 4 int 17
pci2 at ppb1 bus 2
Broadcom BCM4313 rev 0x01 at pci2 dev 0 function 0 not configured
uhci0 at pci0 dev 29 function 0 Intel 82801GB USB rev 0x02: apic 4 int 18
uhci1 at pci0 dev 29 function 1 Intel 82801GB USB rev 0x02: apic 4 int 20
uhci2 at pci0 dev 29 function 2 Intel 82801GB USB rev 0x02: apic 4 int 21
uhci3 at pci0 dev 29 function 3 Intel 82801GB USB rev 0x02: apic 4 int 22
ehci0 at pci0 dev 29 function 7 Intel 82801GB USB rev 0x02: apic 4 int 22
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 Intel EHCI root hub rev 2.00/1.00 addr 1
ppb2 at pci0 dev 30 function 0 Intel 82801BAM Hub-to-PCI rev 0xe2
pci3 at ppb2 bus 5
pcib0 at pci0 dev 31 function 0 Intel Tigerpoint LPC rev 0x02
ahci0 at pci0 dev 31 function 2 Intel 82801GR AHCI rev 0x02: apic 4 int 17, 
AHCI 1.1
ahci0: PHY offline on port 1
scsibus0 at ahci0: 32 targets
sd0 at scsibus0 targ 0 lun 0: ATA, Hitachi HTS54502, PB2O SCSI3 0/direct 
fixed naa.5000cca62bf2b42f
sd0: 238475MB, 512 bytes/sec, 488397168 sec total
ichiic0 at pci0 dev 31 function 3 Intel 82801GB SMBus rev 0x02: apic 4 int 17
iic0 at ichiic0
spdmem0

Re: alc(4) support for Atheros AR815x

[Edd Barrett]

On Mon, May 02, 2011 at 01:16:55AM +0100, Edd Barrett wrote:
 On Sun, May 01, 2011 at 08:10:56PM +0100, Stuart Henderson wrote:
  On 2011/05/01 18:35, Edd Barrett wrote:
   I have acquired a netboot (packard bell dot s), which I think uses this 
   NIC. Is
   there an updated diff?
  
  Yes I just took the 2 minutes it took to apply it and fix
  the minor conflicts and linewrapping issue with the diff.
  Untested beyond it builds.
 
 Stu's diff seems to work, although the first time i booted my bsd.rd I was
 unable to install due to: 
 
 alc0: watchdog timeout (missed link)

^ this seems to happen quite frequently. I just had the same issue again on the
installed system.

-- 
Best Regards
Edd Barrett

http://www.theunixzoo.co.uk

Re: Thank you for making p2k9 possible!

[Edd Barrett]

On Sun, Oct 11, 2009 at 04:56:00PM +0200, Robert Nagy wrote:
 I'd also like to thank NIIF and Sun Microsystems Hungary for lending
 us a nice hackroom and hardware for the hackathon.

Thanks to Robert for hosting this event.  Also I would like to say a
word of thanks to the porting team for having me here at p2k9 and to
Naddy for creating my account. Thankyou all.

But if I hear any more 'g|nther and the sunshine girls', I may never make
it home. It melts the brain...

-- 
Best Regards
Edd Barrett

http://students.dec.bmth.ac.uk/ebarrett

Re: broken X/sparc64

[Edd Barrett]

On Thu, Sep 10, 2009 at 09:33:39PM +0200, Matthieu Herrb wrote:
 Known problem. I'm working on it. The autoconfiguration code in xserver
 1.6 has changed slightly and needs a bit more work for OpenBSD.
 
 In the mean time you can probably get your system running with a proper
 xorg.conf, whith just the device section that you need.

Thanks, ping me a mail when you think it is fixed and I can remove my
xorg.conf and report the results.

-- 

Best Regards

Edd Barrett
(Freelance software developer / technical writer / open-source developer)

http://students.dec.bmth.ac.uk/ebarrett

Re: Expert3D-Lite driver breakage

[Edd Barrett]

On Thu, Sep 03, 2009 at 06:04:25PM +0100, Edd Barrett wrote:
 Hi,
 
 I went digging and found my:
 ifb0 at pci0 dev 2 function 0 Intergraph Expert3D rev 0x00
 ifb0: Expert3D-Lite (SUNW,375-0116), 1280x1024

And I should have got an Xorg.0.log while the card was still in :\

-- 

Best Regards

Edd Barrett
(Freelance software developer / technical writer / open-source developer)

http://students.dec.bmth.ac.uk/ebarrett

Re: [heads up] X snapshots now contain libxcb

[Edd Barrett]

On Fri, Aug 7, 2009 at 4:42 AM, Christiano Farina
Haesbaertchristiano...@gmail.com wrote:
 On Thu, Aug 06, 2009 at 01:00:23PM +0100, Edd Barrett wrote:
 On Tue, Aug 4, 2009 at 2:38 PM, David Coppadco...@gmail.com wrote:
  For awesome 3, we need also a working port of cmake 2.6.X

 Is anyone working on that?

 I might do it if I have some spare time, never done a port though :/.

It may not be a good one to start with as I suspect all the find_*
routines (for example when finding qt4) will most likely need
patching.


-- 
Best Regards

Edd Barrett
(Freelance software developer / technical writer / open-source developer)

http://students.dec.bournemouth.ac.uk/ebarrett

Re: cwmrc(5) color options

[Edd Barrett]

On Fri, Aug 07, 2009 at 02:18:50PM +0159, Simon Nicolussi wrote:
 Hello,
 
 this patch adds the possibility to specify colors for the menu and
 its font in the cwmrc(5). Thanks to Thomas Pfaff for brief testing
 and further suggestions.

Works i386, will try sparc64 at some point. Really great! I have wanted
to change the colors for ages!

How do the menu item foreground and background relate? Are they just
inverted? It would be better to have an explicit option for each.

Also note that the sub-pixel hinting looks awful:
http://www.flickr.com/photos/vext01/3797404275/sizes/o/

Perhaps a change of default font or turning off hinting (if possible)
would help?

Thanks

-- 

Best Regards

Edd Barrett
(Freelance software developer / technical writer / open-source developer)

http://students.dec.bmth.ac.uk/ebarrett

Re: cwmrc(5) color options

[Edd Barrett]

On Fri, Aug 07, 2009 at 07:30:47PM +0100, Edd Barrett wrote:
 Anyway, it works on sparc64 too. Good work :)

No it doesnt. Oops :)

When moving windows in cwm (with the mouse) on a blade 1000, bits of
other window borders get stuck over the window you are dragging.

See screenshot:
http://www.flickr.com/photos/vext01/3798156549/sizes/o/

I have an expert3d card with the firmware loaded.

-- 

Best Regards

Edd Barrett
(Freelance software developer / technical writer / open-source developer)

http://students.dec.bmth.ac.uk/ebarrett