Re: audioctl: display variables periodically
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", &rname.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, &rstatus) == -1) > - err(1, "AUDIO_GETSTATUS"); > - if (ioctl(fd, AUDIO_GETDEV, &rname) == -1) > - err(1, "AUDIO_GETDEV"); > - if (ioctl(fd, AUDIO_GETPAR, &rpar) == -1) > - err(1, "AUDIO_GETPAR"); > - if (ioctl(fd, AUDIO_GETPOS, &rpos) == -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"); > -
Re: audioctl: display variables periodically
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
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
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
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
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
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
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
at 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
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
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
nprintf(buf, MAX_AUDIO_DESCR_LEN, "%s/0x%04x", + 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",&rname.name,NULL, STR}, + {"descr", &rname.descr, NULL, STR}, {"mode",&rstatus.mode, NULL, MODE}, {"pause", &rstatus.pause, NULL, NUM}, {"active", &rstatus.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
ed if (val) c->val_mask = ~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, &d->sioctl.hdl); - if (d->sio.hdl == NULL) { - if (mode != (SIO_PLAY | SIO_REC)) - return 0; - d->sio.hdl = dev_sio_openlist(d, SIO_PLAY, &d->sioctl.hdl); - if (d->sio.hdl != NULL) - mode = SIO_PLAY; - else { - d->sio.hdl = dev_sio_openlist(d, - SIO_REC, &d->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, &d->sio.hdl, &d->sioctl.hdl, &d->mode)) + return 0; + sio_initpar(&par); 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(&dev_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), &ctlhdl); - if (hdl == NULL) { - if (log_level >= 1) { - dev_log(d); - log_puts(": couldn't open an alternate device\n"); - } + if (!dev_sio_openlist(d, &hdl, &ctlhdl, &mode)) return 0; - } sio_initpar(&par); 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
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
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 = &dev->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 = &dev->ifaces[idx]; + return (USBD_NORMAL_COMPLETION); + } + } + return (USBD_INVAL); } /* use altno */ -- Best Regards Edd Barrett http://www.theunixzoo.co.uk
Re: search usbd_interfaces in case of non-compliant device
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 = &dev->ifaces[ifaceno]; - return (USBD_NORMAL_COMPLETION); + if (ifaceno < dev->cdesc->bNumInterfaces && + dev->ifaces[ifaceno].idesc->bInterfaceNumber == ifaceno) { + *iface = &dev->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 = &dev->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
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 = &dev->ifaces[ifaceno]; - return (USBD_NORMAL_COMPLETION); + if (ifaceno < dev->cdesc->bNumInterface && + dev->ifaces[ifaceno].idesc->bInterfaceNumber == ifaceno) { + *iface = &dev->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 = &dev->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
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)
= 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: cpu utilisation bars for top(1)
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)
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)
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)
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)
.Ql ^\e ) still have an effect. This is the default on a dumb 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
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 +, 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
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
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
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
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(&info, 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
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
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
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
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
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
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
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
uest is down, hit enter and you are back at the host's shell: + + +[EOT] +# cp /bsd . +# vi /etc/vm.conf # 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
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
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
Re: removing wsmouse_input [2]: zts, hilms, uts
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&m=146504820529987&w=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
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 device with K-9 Mail. Please excuse my brevity.
schizo0: safari error
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: SCSI3 0/direct fixed naa.2014c303de67 sd0 at scsibus0 targ 0 lun 0: SCSI3 0/direct fixed naa.2014c303de67 sd0: 140014MB, 512 bytes/sector, 286749488 sectors sym1 at scsibus3 targ 2 lun 0: SCSI3 0/direct fixed naa.2018623c7bd4 sd1 at scsibus0 targ 1 lun 0: 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)
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)
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, &siz, 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, &siz, 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. @@ -3
Allow top(1) to search arguments (again)
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 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
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
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
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
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
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
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
i0 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 ahci0: port 0: 6.0Gb/s ahci0: port 1: 1.5Gb/s scsibus1 at ahci0: 32 targets sd0 at scsibus1 targ 0 lun 0: SCSI3 0/direct fixed naa.500a0751093c44b5 sd0: 228936MB, 512 bytes/sector, 468862128 sectors, thin cd0 at scsibus1 targ 1 lun 0: 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
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
diff(1) performance
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
Revisiting the HDMI2 bug with i915 and docking stations.
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 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
Re: Allow top(1) to search arguments
+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
Allow top(1) to search arguments
s 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
Re: Firefox, malloc(3) and threads
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.
ut=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 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
Re: USB panic
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 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,MWA
USB panic
tid 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 WARNING: / was not properly unmounted 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 sd1 at scsibus4 targ 1 lun 0: SCSI2 0/direct removable sd1: 3847MB, 512 bytes/sector, 7880544 sectors sd2 at scsibus4 targ 1 lun 1: SCSI2 0/direct removable -- Best Regards Edd Barrett http://www.theunixzoo.co.uk
Non-functional USB ports on thinkpad x230t/OpenBSD
rm0 at vga1 drm0 at inteldrm0 drm: Memory usable by graphics device = 2048M inteldrm0: 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: 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: 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
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
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
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
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
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
memset.S for amd64
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=217106&view=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 . + * Public domain. + * Adapted for NetBSD/x86_64 by Frank van der Linden + */ + +#include + +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: memset.S for amd64
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
Re: Merge uhts(4) into ums(4).
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).
_calibcoords *wsmc = (struct wsmouse_calibcoords *)data; - int rc, error = 0; - - DPRINTF(("uhts_ioctl(%d, '%c', %d)\n", - IOCPARM_LEN(cmd), IOCGROUP(cmd), cmd & 0xff)); - - rc = uhidev_ioctl(&sc->sc_hdev, cmd, data, flag, p); - if (rc != -1) - return rc; - - switch (cmd) { - case WSMOUSEIO_GTYPE: - *(u_int *)data = WSMOUSE_TYPE_TPANEL; - return (0); - case WSMOUSEIO_SCALIBCOORDS: - if (!(wsmc->minx >= 0 && wsmc->maxx >= 0 && - wsmc->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).
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).
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 ===
Re: Stairstep mouse motion
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
Merge uhts(4) into ums(4).
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) + prin
Re: Wake from zzz causes panic on thinkpad x60
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
hci1: USB revision 2.0 uhub1 at usb1 "Intel EHCI root hub" rev 2.00/1.00 addr 1 ppb2 at pci0 dev 30 function 0 "Intel 82801BAM Hub-to-PCI" rev 0xf3 pci3 at ppb2 bus 5 cbb0 at pci3 dev 0 function 0 "Ricoh 5C476 CardBus" rev 0xba: apic 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: 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
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
urtwn0 does not recover from suspend
801H USB" rev 0x03: apic 1 int 17 ehci1 at pci0 dev 29 function 7 "Intel 82801H USB" rev 0x03: apic 1 int 19 usb1 at ehci1: USB revision 2.0 uhub1 at usb1 "Intel EHCI root hub" rev 2.00/1.00 addr 1 ppb2 at pci0 dev 30 function 0 "Intel 82801BAM Hub-to-PCI" rev 0xf3 pci3 at ppb2 bus 5 cbb0 at pci3 dev 0 function 0 "Ricoh 5C476 CardBus" rev 0xba: apic 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: 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 urtwn0 at uhub1 port 2 "Realtek 802.11n WLAN Adapter" rev 2.00/2.00 addr 2 urtwn0: MAC/BB RTL8188CUS, RF 6052 1T1R, address 00:1f:1f:fe:c1:02 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 WARNING: / was not properly unmounted ugen0 detached ugen0 at uhub2 port 1 "Broadcom Corp BCM2045B" rev 2.00/1.00 addr 2 urtwn0: could not send firmware command 5 urtwn0: could not send firmware command 5 urtwn0: device timeout urtwn0: could not send firmware command 5 urtwn0: could not send firmware command 5 urtwn0: could not send firmware command 5 urtwn0: could not send firmware command 5 urtwn0: could not send firmware command 5 urtwn0: could not send firmware command 5 urtwn0: could not send firmware command 5 urtwn0: device timeout urtwn0: could not send firmware command 5 urtwn0: could not send firmware command 5 urtwn0: could not send firmware command 5 urtwn0: could not send firmware command 5 urtwn0: could not send firmware command 5 urtwn0: could not send firmware command 5 urtwn0: could not send firmware command 5 -- Best Regards Edd Barrett http://www.theunixzoo.co.uk
iwn0 firmware errors
1 ppb2 at pci0 dev 30 function 0 "Intel 82801BAM Hub-to-PCI" rev 0xf3 pci3 at ppb2 bus 5 cbb0 at pci3 dev 0 function 0 "Ricoh 5C476 CardBus" rev 0xba: apic 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: 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: xf86-video-intel driver broken after 2011/11/29
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-x11&m=132865830223969&w=2 And yep, I use startx. -- Best Regards Edd Barrett http://www.theunixzoo.co.uk
Re: small change to the scandir(3) manual page
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
Re: fix ral (and maybe other cards) hostap mode
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" 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, 1Mbit/s, chan 1, 11g, antenna 1, signal 65dB> > > 17:24:49.225311 802.11: deauthentication, authentication expired, > > > 17:24:49.225347 802.11: deauthentication, authentication expired, > > > 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
I see. There are clues in dir(5) actually, so perhaps a note in scandir(3) is vacuous. On Jan 19, 2012 6:59 PM, "Joerg Sonnenberger" wrote: > On Thu, Jan 19, 2012 at 06:32:45PM +, Edd Barrett wrote: > > On Thu, Jan 19, 2012 at 10:17:02AM -0800, Philip Guenther wrote: > > > On Thu, Jan 19, 2012 at 4:18 AM, Edd Barrett wrote: > > > > I recently got caught out by scandir's quirky memory allocation. > Should > > > > we add a note so that others don't have to go through this pain too? > > > > > > Could you elaborate on how this affected your code? I'm trying to > > > think of some way for code to depend on this that isn't undefined > > > behavior by the POSIX standard and (sorry) just a bad idea in > > > practice... > > > > I tried to memcpy() one of these dirents into a new buffer: > > > > memcpy(dest, src, sizeof(struct dirent)); > > > > This overran the read buffer, as most dirents allocated by scandir() are > > not this big. > > POSIX explicitly says that d_name has unspecified size. > > Joerg
Re: small change to the scandir(3) manual page
On Thu, Jan 19, 2012 at 10:17:02AM -0800, Philip Guenther wrote: > On Thu, Jan 19, 2012 at 4:18 AM, Edd Barrett wrote: > > I recently got caught out by scandir's quirky memory allocation. Should > > we add a note so that others don't have to go through this pain too? > > Could you elaborate on how this affected your code? I'm trying to > think of some way for code to depend on this that isn't undefined > behavior by the POSIX standard and (sorry) just a bad idea in > practice... I tried to memcpy() one of these dirents into a new buffer: memcpy(dest, src, sizeof(struct dirent)); This overran the read buffer, as most dirents allocated by scandir() are not this big. -- Best Regards Edd Barrett http://www.theunixzoo.co.uk
small change to the scandir(3) manual page
Hi, I recently got caught out by scandir's quirky memory allocation. Should we add a note so that others don't have to go through this pain too? Index: scandir.3 === RCS file: /cvs/src/lib/libc/gen/scandir.3,v retrieving revision 1.10 diff -u -p -u -r1.10 scandir.3 --- scandir.3 26 Mar 2010 19:30:40 - 1.10 +++ scandir.3 19 Jan 2012 12:08:15 - @@ -27,7 +27,7 @@ .\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF .\" SUCH DAMAGE. .\" -.Dd $Mdocdate: March 26 2010 $ +.Dd $Mdocdate: January 19 2012 $ .Dt SCANDIR 3 .Os .Sh NAME @@ -53,6 +53,24 @@ It returns the number of entries in the A pointer to the array of directory entries is stored in the location referenced by .Fa namelist . +.Pp +Note that after a call to +.Fn scandir +the allocation size of each +.Fa dirent +structure within the +.Fa namelist +array is not necessarily +.Fa sizeof(struct direct) . +For each directory entry, +.Fn scandir +will allocate space for the integer fields plus as many bytes as is +required to store the NULL-terminated string +.Fa d_name +rounded up to a 4-byte boundary. See +.Xr dir 5 +for the exact layout of +.Fa struct dirent . .Pp The .Fa select -- Best Regards Edd Barrett http://www.theunixzoo.co.uk
Re: [panc...@nopcode.org: License]
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
[panc...@nopcode.org: License]
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 - Date: Thu, 13 Oct 2011 01:19:26 +0200 From: pancake To: Edd Barrett 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: fix a seg and minor improvements to config(8)
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 + +#include #include #include -#include #include #include 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 + #include #include #include #include #include + #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 + #include #include #include #include + #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 + #include #include #include #include #include #include + #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 + #include #include #include #include + #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 + #include #include + #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 + #include +#include #include #include #include -#include + #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 #include -#include #include +#include #include #include #include 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 #include #include + #include #include #include 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 + #include +#include #include #include #include -#include + #include "config.h" static void nomem(void); -- Best Regards Edd Barrett http://www.theunixzoo.co.uk
Re: fix a seg and minor improvements to config(8)
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
fix a seg and minor improvements to config(8)
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 #include +#include +#include #include #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
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
ic0 at ichiic0 spdmem0 at iic0 addr 0x50: 1GB DDR3 SDRAM PC3-10600 SO-DIMM usb1 at uhci0: USB revision 1.0 uhub1 at usb1 "Intel UHCI root hub" rev 1.00/1.00 addr 1 usb2 at uhci1: USB revision 1.0 uhub2 at usb2 "Intel UHCI root hub" rev 1.00/1.00 addr 1 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
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=revision&revision=221407 -- Best Regards Edd Barrett http://www.theunixzoo.co.uk
Re: Network Interface Daemon and ifconfig header file
Perhaps the functions belong in a shared object? On May 4, 2011 10:46 AM, "Rafael Sadowski" 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 > #include > > -#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(co
Re: alc(4) support for Atheros AR815x
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
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: alc(4) support for Atheros AR815x
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,
Re: alc(4) support for Atheros AR815x
On Thu, Apr 28, 2011 at 07:21:16AM +1000, Jonathan Gray wrote: > On Tue, Jan 25, 2011 at 06:24:28PM +0800, Kevin Lo wrote: > > Hi, > > > > The following diff adds support for Atheros AR8151/AR8152 chipsets; > > mostly from FreeBSD. It also fixes an issue i386/6311. > > Tested on Acer AOD255E. > > Is there an updated diff for this? It seems this never made it > into the tree. I have acquired a netboot (packard bell dot s), which I think uses this NIC. Is there an updated diff? Dmesg: OpenBSD 4.9-current (RAMDISK_CD) #41: Thu Apr 21 00:17:13 MDT 2011 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/RAMDISK_CD 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 = 1061335040 (1012MB) avail mem = 1036996608 (988MB) 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 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: apic clock running at 166MHz cpu at mainbus0: not configured ioapic0 at mainbus0: apid 4 pa 0xfec0, version 20, 24 pins ioapic0: misconfigured as apic 0, remapped to apid 4 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) bios0: ROM list: 0xc/0xda00! 0xce000/0x1000 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) "Intel Pineview Video" rev 0x00 at pci0 dev 2 function 1 not configured "Intel 82801GB HD Audio" rev 0x02 at pci0 dev 27 function 0 not configured ppb0 at pci0 dev 28 function 0 "Intel 82801GB PCIE" rev 0x02: apic 4 int 16 (irq 255) pci1 at ppb0 bus 1 "Attansic Technology L2C" rev 0xc1 at pci1 dev 0 function 0 not configured ppb1 at pci0 dev 28 function 1 "Intel 82801GB PCIE" rev 0x02: apic 4 int 17 (irq 255) 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 (irq 11) uhci1 at pci0 dev 29 function 1 "Intel 82801GB USB" rev 0x02: apic 4 int 20 (irq 10) uhci2 at pci0 dev 29 function 2 "Intel 82801GB USB" rev 0x02: apic 4 int 21 (irq 11) uhci3 at pci0 dev 29 function 3 "Intel 82801GB USB" rev 0x02: apic 4 int 22 (irq 11) ehci0 at pci0 dev 29 function 7 "Intel 82801GB USB" rev 0x02: apic 4 int 22 (irq 11) 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 (irq 10), AHCI 1.1 ahci0: PHY offline on port 1 scsibus0 at ahci0: 32 targets sd0 at scsibus0 targ 0 lun 0: SCSI3 0/direct fixed naa.5000cca62bf2b42f sd0: 238475MB, 512 bytes/sec, 488397168 sec total "Intel 82801GB SMBus" rev 0x02 at pci0 dev 31 function 3 not configured usb1 at uhci0: USB revision 1.0 uhub1 at usb1 "Intel UHCI root hub" rev 1.00/1.00 addr 1 usb2 at uhci1: USB revision 1.0 uhub2 at usb2 "Intel UHCI root hub" rev 1.00/1.00 addr 1 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 npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16 rd0: fixed, 3872 blocks "Y2B2D0JXB WebCam" rev 2.00/0.04 addr 2 at uhub0 port 4 not configured softraid0 at root PXE boot MAC address 1c:75:08:d5:53:c4, interface unknown root on rd0a swap on rd0b dump on rd0b umass0 at uhub1 port 2 configuration 1 interface 0 "vendor 0x0204 product 0x6025" rev 1.10/1.00 addr 2 umass0: using SCSI over Bulk-Only scsibus1 at umass0: 2 targets, initiator 0 sd1 at scsibus1 targ 1 lun 0: SCSI2 0/direct removable sd1: 486MB, 512 bytes/sec, 996415 sec total -- Best Regards Edd Barrett http://www.theunixzoo.co.uk
Re: Thank you for making p2k9 possible!
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