Re: urndis issues

[Jonathan Armani]

Hi,

Thanks I was cooking the same diff.

Ok armani@

Le mar. 11 juil. 2017 à 12:32, Mike Belopuhov  a écrit :

> On Sun, Jul 09, 2017 at 09:57 +0300, Artturi Alm wrote:
> > Hi,
> >
> > anyone else having issues w/urndis(android)?
> > victim of circumstances, i have to rely on it at times during the summer.
> > When i plug phone into usb, and enable usb tethering or w/e it is called,
> > i never get ip on first try, i have nothing but "dhcp"
> > in /etc/hostname.urndis0, so i just ^C on the first i"ksh /etc/netstart"
> > and get ip pretty much as expected in seconds on the successive run
> > right after ^C, the first dhclient would end up sleeping if not ^C'ed..
> >
> > this is what i see in dmesg:
> > urndis0 at uhub0 port 1 configuration 1 interface 0 "SAMSUNG
> SAMSUNG_Android" rev 2.00/ff.ff addr 2
> > urndis0: using RNDIS, address 02:56:66:63:30:3c
> > urndis0: ctrl message error: unknown event 0x7
> >
> > no dmesg, as i've ran into this issue on every installation of OpenBSD
> > i have tried w/.
> > unrelated issue is this spam i get which i haven't noticed to affect
> > anything:
> > urndis0: urndis_decap invalid buffer len 1 < minimum header 44
> >
> > for which i ended up w/diff below.
> > -Artturi
> >
>
> What happens if you apply the diff below w/o your modifications?
>
> diff --git sys/dev/usb/if_urndis.c sys/dev/usb/if_urndis.c
> index 4af6b55cf05..bdca361713d 100644
> --- sys/dev/usb/if_urndis.c
> +++ sys/dev/usb/if_urndis.c
> @@ -88,10 +88,12 @@ u_int32_t urndis_ctrl_handle_init(struct urndis_softc
> *,
>  const struct rndis_comp_hdr *);
>  u_int32_t urndis_ctrl_handle_query(struct urndis_softc *,
>  const struct rndis_comp_hdr *, void **, size_t *);
>  u_int32_t urndis_ctrl_handle_reset(struct urndis_softc *,
>  const struct rndis_comp_hdr *);
> +u_int32_t urndis_ctrl_handle_status(struct urndis_softc *,
> +const struct rndis_comp_hdr *);
>
>  u_int32_t urndis_ctrl_init(struct urndis_softc *);
>  u_int32_t urndis_ctrl_halt(struct urndis_softc *);
>  u_int32_t urndis_ctrl_query(struct urndis_softc *, u_int32_t, void *,
> size_t,
>  void **, size_t *);
> @@ -233,10 +235,14 @@ urndis_ctrl_handle(struct urndis_softc *sc, struct
> rndis_comp_hdr *hdr,
> case REMOTE_NDIS_KEEPALIVE_CMPLT:
> case REMOTE_NDIS_SET_CMPLT:
> rval = letoh32(hdr->rm_status);
> break;
>
> +   case REMOTE_NDIS_INDICATE_STATUS_MSG:
> +   rval = urndis_ctrl_handle_status(sc, hdr);
> +   break;
> +
> default:
> printf("%s: ctrl message error: unknown event
> 0x%x\n",
> DEVNAME(sc), letoh32(hdr->rm_type));
> rval = RNDIS_STATUS_FAILURE;
> }
> @@ -400,10 +406,48 @@ urndis_ctrl_handle_reset(struct urndis_softc *sc,
>
> return rval;
>  }
>
>  u_int32_t
> +urndis_ctrl_handle_status(struct urndis_softc *sc,
> +const struct rndis_comp_hdr *hdr)
> +{
> +   const struct rndis_status_msg   *msg;
> +   u_int32_trval;
> +
> +   msg = (struct rndis_status_msg *)hdr;
> +
> +   rval = letoh32(msg->rm_status);
> +
> +   DPRINTF(("%s: urndis_ctrl_handle_status: len %u status 0x%x "
> +   "stbuflen %u\n",
> +   DEVNAME(sc),
> +   letoh32(msg->rm_len),
> +   rval,
> +   letoh32(msg->rm_stbuflen)));
> +
> +   switch (rval) {
> +   case RNDIS_STATUS_MEDIA_CONNECT:
> +   printf("%s: link up\n", DEVNAME(sc));
> +   break;
> +
> +   case RNDIS_STATUS_MEDIA_DISCONNECT:
> +   printf("%s: link down\n", DEVNAME(sc));
> +   break;
> +
> +   /* Ignore these */
> +   case RNDIS_STATUS_OFFLOAD_CURRENT_CONFIG:
> +   break;
> +
> +   default:
> +   printf("%s: unknown status 0x%x\n", DEVNAME(sc),
> rval);
> +   }
> +
> +   return RNDIS_STATUS_SUCCESS;
> +}
> +
> +u_int32_t
>  urndis_ctrl_init(struct urndis_softc *sc)
>  {
> struct rndis_init_req   *msg;
> u_int32_trval;
> struct rndis_comp_hdr   *hdr;
>
>

Re: malloc: 1st small step in long way to multiple pools

[Jonathan Armani]

On Wed, Mar 09, 2016 at 10:06:15AM +0100, Otto Moerbeek wrote:
> Hi,
> 
> a future goal for malloc is to use multiple pools in threaded environments,
> to reduce lock contention. 
> 
> This is a small first step towards that goal: move two globals to the
> pool-specific struct dir_info. Currently there's only a single pool,
> but that will change one day.
> 
> Lightly tested by myself on amd64, you can help by reviewing and
> testing this.
> 

Hi otto,

Diff looks good and I have been running it for a few days without
problem.

Re: audioctl: expose counters returned by AUDIO{I,O}OFFS

[Jonathan Armani]

On Sun, May 24, 2015 at 03:39:21AM +0200, Alexandre Ratchov wrote:
 This exposes the counters returned by AUDIO_GET{I,O}OFFS ioctls,
 they correspond to the number of bytes processed by the device.
 
 The main usefulness of these counters is to check whether the
 kernel is missing interrupts (by verifying that play.bytes and
 record.bytes are the same).
 
 If we expose them, the {play,record}.samples (aka the ones returned
 by AUDIO_GETINFO) are not useful anymore and could be removed to
 avoid confusion.
 
 OK?
 

Hi,

You're the one who will be analysing bugs report using audioctl and
I think your approach is rational.

ok armani@

Re: remove dsp bits from libossaudio

[Jonathan Armani]

On Fri, Apr 17, 2015 at 12:34:00PM +0200, Alexandre Ratchov wrote:
 No code uses the SNDCLT_DSP_* ioctls anymore (the last port using
 them was removed few months ago), so they could be removed now. As
 there's no ABI change, no shlib_version crank is necessary.
 
 The motivation of removing these ioctls is to ease
 simplifications and development of the audio(4) driver.
 
 OK?
 

ok armani@

Re: remove oss support from linux compat (i386 only)

[Jonathan Armani]

On Fri, Apr 17, 2015 at 12:25:13PM +0200, Alexandre Ratchov wrote:
 This was discussed and nobody steps up to save it:
 
 http://comments.gmane.org/gmane.os.openbsd.misc/217005
 
 removing oss emulation, will remove dependency on obscure audio(4)
 features we don't use since ~2009, and in turn will ease audio(4)
 driver cleanup without breaking the build.
 
 Tested on i386.
 
 OK?
 

ok armani@

Re: urndis(4) fix

[Jonathan Armani]

On Sat, Nov 29, 2014 at 09:42:51PM +0100, Mark Kettenis wrote:
 Recent Oracle SPARC machines have a USB gadget to talk to the Service
 Processor (ILOM).  This gadget supports both RNDIS and CDC Ethernet.
 The RNDIS bits uncovered a bug in urndis(4).  When urndis_ctrl_set()
 sets up the REMOTE_NDIS_SET_MSG command it sets up msg-rm_infobuflen,
 it subsequently overwrites its contents.  Apparently many RNDIS
 devices don't care, but this hardware sends a response back that
 indicates the command wasn't accepted.  Diff below fixes this problem.
 It matches what Linux does.
 
 Unfortunately, this isn't enough to make the gadget work in RNDIS mode.
 
 I'd appreciate it if people using urndis(4) could test this diff.
 

Makes sense, ok armani@ (over urndis)

Reinforce uvideo_reqbufs

[Jonathan Armani]

Hi,

In v4l2 VIDIOC_REQBUFS ioctl, a count value of zero frees all buffers.
We do not support it, and worse, it triggers a kernel panic.

Return EINVAL in this case so app can detect we do not allow it. While 
there change the easily triggerable panic by a printf and return EINVAL.

With that gstreamer1 correcly fallback and works.

ok ? comments ?

Index: uvideo.c
===
RCS file: /cvs/src/sys/dev/usb/uvideo.c,v
retrieving revision 1.176
diff -u -p -r1.176 uvideo.c
--- uvideo.c18 Oct 2014 08:01:34 -  1.176
+++ uvideo.c18 Oct 2014 09:01:04 -
@@ -3092,8 +3092,14 @@ uvideo_reqbufs(void *v, struct v4l2_requ
 
DPRINTF(1, %s: %s: count=%d\n, DEVNAME(sc), __func__, rb-count);
 
-   if (sc-sc_mmap_count  0 || sc-sc_mmap_buffer != NULL)
-   panic(%s: mmap buffers already allocated, __func__);
+   /* We do not support freeing buffers via raqbufs(0) */
+   if (rb-count == 0)
+   return (EINVAL);
+
+   if (sc-sc_mmap_count  0 || sc-sc_mmap_buffer != NULL) {
+   printf(%s: mmap buffers already allocated\n, __func__);
+   return (EINVAL);
+   }
 
/* limit the buffers */
if (rb-count  UVIDEO_MAX_BUFFERS)

Re: delete kernel audio conversions code

[Jonathan Armani]

On Tue, Oct 14, 2014 at 09:09:26PM +0200, Alexandre Ratchov wrote:
 Since end 2011 we have complete audio format conversions code
 enabled by default that runs in user-mode (from any to any
 encoding, rate, and channel number combination). So there's no
 reason to keep the incomplete kernel conversions code, which is not
 reachable by default, and not properly used by all drivers.
 
 Furthermore the kernel code to setup conversions is duplicated in
 every single low-level driver, depite being ugly, this complicates
 evolution of the mi code as it forces to update  retest every
 single driver whenever the mi code changes. Finally there's no
 fundamental reason for doing cpu-intensive conversions in the
 kernel and holding the kernel_lock for longer than necessary.
 
 What the diff does:
 
 in all set_params() driver functions:
   - remove handling of encodings that sets sw_code, in this case
 either return EINVAL or (better) use another encoding.
   - rather than tweaking code to set the encoding to
 AUDIO_ENCODING_[SU]LINEAR, remove it as only
 AUDIO_ENCODING_[SU]LINEAR_{LE,BE} are used.
   - play and rec encodings are always the same. So remove code to
 handle different play and rec encodings rather that tweaking it
 and introducing errors
 
 in all query_encoding() driver functions:
   - remove entries corrsponding to emulated encodings
   - if necessary, renumber indices to remove holes
 
 in all other driver functions:
   - replace the factor field by 1
   - remove unused variables resulting from above steps
 
 For now the linear-mulaw conversions is still needed for am7930
 as it supports mu-law only. The diff moves it in audio.c, which
 will be simplified later. Except for am7930, the diff is
 mechanical, still testing never hurts ;)
 
 Objections? OKs?
 

Hi,

Tested on azalia amd64 desktop  laptop and snapper on macppc, no
regression.

Diff looks good and I like this cleanning a lot. ok armani@ 

Add Logitech C310 to usbdevs

[Jonathan Armani]

Hi,

Diff add my Logitech Webcam C310 to usbdevs.
 
Bus 000 Device 003: ID 046d:081b Logitech, Inc. Webcam C310

ok ?


Index: usbdevs
===
RCS file: /cvs/src/sys/dev/usb/usbdevs,v
retrieving revision 1.637
diff -u -p -r1.637 usbdevs
--- usbdevs 5 Oct 2014 08:32:39 -   1.637
+++ usbdevs 9 Oct 2014 20:56:21 -
@@ -2493,6 +2493,7 @@ product LOGITECH QUICKCAMWEB  0x0801  Quic
 product LOGITECH WEBCAMC2000x0802  Webcam C200
 product LOGITECH WEBCAMC5000x0807  Webcam C500
 product LOGITECH QUICKCAMPRO   0x0810  QuickCam Pro
+product LOGITECH WEBCAMC3100x081b  Webcam C310
 product LOGITECH HDPROC910 0x0821  HD Pro Webcam C910
 product LOGITECH QUICKCAMEXP   0x0840  QuickCam Express
 product LOGITECH QUICKCAM  0x0850  QuickCam
Index: usbdevs.h
===
RCS file: /cvs/src/sys/dev/usb/usbdevs.h,v
retrieving revision 1.649
diff -u -p -r1.649 usbdevs.h
--- usbdevs.h   5 Oct 2014 08:33:13 -   1.649
+++ usbdevs.h   9 Oct 2014 20:56:23 -
@@ -1,4 +1,4 @@
-/* $OpenBSD: usbdevs.h,v 1.649 2014/10/05 08:33:13 mpi Exp $   */
+/* $OpenBSD$   */
 
 /*
  * THIS FILE IS AUTOMATICALLY GENERATED.  DO NOT EDIT.
@@ -2500,6 +2500,7 @@
 #defineUSB_PRODUCT_LOGITECH_WEBCAMC200 0x0802  /* Webcam C200 
*/
 #defineUSB_PRODUCT_LOGITECH_WEBCAMC500 0x0807  /* Webcam C500 
*/
 #defineUSB_PRODUCT_LOGITECH_QUICKCAMPRO0x0810  /* 
QuickCam Pro */
+#defineUSB_PRODUCT_LOGITECH_WEBCAMC310 0x081b  /* Webcam C310 
*/
 #defineUSB_PRODUCT_LOGITECH_HDPROC910  0x0821  /* HD Pro 
Webcam C910 */
 #defineUSB_PRODUCT_LOGITECH_QUICKCAMEXP0x0840  /* 
QuickCam Express */
 #defineUSB_PRODUCT_LOGITECH_QUICKCAM   0x0850  /* QuickCam */
Index: usbdevs_data.h
===
RCS file: /cvs/src/sys/dev/usb/usbdevs_data.h,v
retrieving revision 1.643
diff -u -p -r1.643 usbdevs_data.h
--- usbdevs_data.h  5 Oct 2014 08:33:13 -   1.643
+++ usbdevs_data.h  9 Oct 2014 20:56:25 -
@@ -1,4 +1,4 @@
-/* $OpenBSD: usbdevs_data.h,v 1.643 2014/10/05 08:33:13 mpi Exp $  */
+/* $OpenBSD$   */
 
 /*
  * THIS FILE IS AUTOMATICALLY GENERATED.  DO NOT EDIT.
@@ -5488,6 +5488,10 @@ const struct usb_known_product usb_known
{
USB_VENDOR_LOGITECH, USB_PRODUCT_LOGITECH_QUICKCAMPRO,
QuickCam Pro,
+   },
+   {
+   USB_VENDOR_LOGITECH, USB_PRODUCT_LOGITECH_WEBCAMC310,
+   Webcam C310,
},
{
USB_VENDOR_LOGITECH, USB_PRODUCT_LOGITECH_HDPROC910,

Add Logitech C310 to uvideo(4)

[Jonathan Armani]

Hi,

The Logitech Webcam C310 just works, diff add it to uvideo(4).

ok ?


Index: uvideo.4
===
RCS file: /cvs/src/share/man/man4/uvideo.4,v
retrieving revision 1.35
diff -u -p -r1.35 uvideo.4
--- uvideo.417 Sep 2012 11:04:24 -  1.35
+++ uvideo.49 Oct 2014 20:58:27 -
@@ -77,6 +77,8 @@ Logitech QuickCam Ultra Vision
 .It
 Logitech Webcam C200
 .It
+Logitech Webcam C310
+.It
 Logitech Webcam C500
 .It
 Microsoft LifeCam NX-6000

Re: Add Logitech C310 to usbdevs

[Jonathan Armani]

Before

uvideo0 at uhub0 port 4 configuration 1 interface 0 Logitech product
0x081b rev 2.00/0.12 addr 4

After

uvideo0 at uhub0 port 4 configuration 1 interface 0 Logitech Webcam C310
rev 2.00/0.12 addr 3

2014-10-09 23:20 GMT+02:00 Martin Pieuchot mpieuc...@nolizard.org:

 On 09/10/14(Thu) 22:58, Jonathan Armani wrote:
  Hi,
 
  Diff add my Logitech Webcam C310 to usbdevs.
 
  Bus 000 Device 003: ID 046d:081b Logitech, Inc. Webcam C310

 What do you see in your dmesg when you don't have this entry in usbdevs?
 Is it understandable?

 I'm asking, because generally USB device names can be read from the
 device descriptor.  My point is that, if you don't need to use this
 define to whitelist a specific device in a driver, adding it to the
 list just makes the kernel bigger.

 Since most of the devices attaching to uvideo(4) are matched by
 interface, I think that we should simply remove the unused defines of
 the Webcams: there's no point in maintaining an unmaintainable list :)

  Index: usbdevs
  ===
  RCS file: /cvs/src/sys/dev/usb/usbdevs,v
  retrieving revision 1.637
  diff -u -p -r1.637 usbdevs
  --- usbdevs   5 Oct 2014 08:32:39 -   1.637
  +++ usbdevs   9 Oct 2014 20:56:21 -
  @@ -2493,6 +2493,7 @@ product LOGITECH QUICKCAMWEB0x0801  Quic
   product LOGITECH WEBCAMC200  0x0802  Webcam C200
   product LOGITECH WEBCAMC500  0x0807  Webcam C500
   product LOGITECH QUICKCAMPRO 0x0810  QuickCam Pro
  +product LOGITECH WEBCAMC310  0x081b  Webcam C310
   product LOGITECH HDPROC910   0x0821  HD Pro Webcam C910
   product LOGITECH QUICKCAMEXP 0x0840  QuickCam Express
   product LOGITECH QUICKCAM0x0850  QuickCam
  Index: usbdevs.h
  ===
  RCS file: /cvs/src/sys/dev/usb/usbdevs.h,v
  retrieving revision 1.649
  diff -u -p -r1.649 usbdevs.h
  --- usbdevs.h 5 Oct 2014 08:33:13 -   1.649
  +++ usbdevs.h 9 Oct 2014 20:56:23 -
  @@ -1,4 +1,4 @@
  -/*   $OpenBSD: usbdevs.h,v 1.649 2014/10/05 08:33:13 mpi Exp $   */
  +/*   $OpenBSD$   */
 
   /*
* THIS FILE IS AUTOMATICALLY GENERATED.  DO NOT EDIT.
  @@ -2500,6 +2500,7 @@
   #define  USB_PRODUCT_LOGITECH_WEBCAMC200 0x0802  /* Webcam
 C200 */
   #define  USB_PRODUCT_LOGITECH_WEBCAMC500 0x0807  /* Webcam
 C500 */
   #define  USB_PRODUCT_LOGITECH_QUICKCAMPRO0x0810  /*
 QuickCam Pro */
  +#define  USB_PRODUCT_LOGITECH_WEBCAMC310 0x081b  /* Webcam
 C310 */
   #define  USB_PRODUCT_LOGITECH_HDPROC910  0x0821  /* HD Pro
 Webcam C910 */
   #define  USB_PRODUCT_LOGITECH_QUICKCAMEXP0x0840  /*
 QuickCam Express */
   #define  USB_PRODUCT_LOGITECH_QUICKCAM   0x0850  /*
 QuickCam */
  Index: usbdevs_data.h
  ===
  RCS file: /cvs/src/sys/dev/usb/usbdevs_data.h,v
  retrieving revision 1.643
  diff -u -p -r1.643 usbdevs_data.h
  --- usbdevs_data.h5 Oct 2014 08:33:13 -   1.643
  +++ usbdevs_data.h9 Oct 2014 20:56:25 -
  @@ -1,4 +1,4 @@
  -/*   $OpenBSD: usbdevs_data.h,v 1.643 2014/10/05 08:33:13 mpi Exp $  */
  +/*   $OpenBSD$   */
 
   /*
* THIS FILE IS AUTOMATICALLY GENERATED.  DO NOT EDIT.
  @@ -5488,6 +5488,10 @@ const struct usb_known_product usb_known
{
USB_VENDOR_LOGITECH, USB_PRODUCT_LOGITECH_QUICKCAMPRO,
QuickCam Pro,
  + },
  + {
  + USB_VENDOR_LOGITECH, USB_PRODUCT_LOGITECH_WEBCAMC310,
  + Webcam C310,
},
{
USB_VENDOR_LOGITECH, USB_PRODUCT_LOGITECH_HDPROC910,
 

Re: audioctl: drop useless fields

[Jonathan Armani]

ok armani@

2014-09-10 19:31 GMT+02:00 Alexandre Ratchov a...@caoua.org:

 audioctl output is full of useless, misleading and/or unreliable
 fields. Let's keep the usable ones only. The plan is to remove them
 from the kernel as well.

 OK?

 Index: audioctl.c
 ===
 RCS file: /cvs/src/usr.bin/audioctl/audioctl.c,v
 retrieving revision 1.23
 diff -u -p -u -p -r1.23 audioctl.c
 --- audioctl.c  13 Nov 2013 18:50:05 -  1.23
 +++ audioctl.c  10 Sep 2014 12:15:06 -
 @@ -80,17 +80,10 @@ struct field {
 u_int oldval;
  } fields[] = {
 { name,   adev.name, STRING, READONLY
 },
 -   { version,adev.version,  STRING, READONLY },
 -   { config, adev.config,   STRING, READONLY },
 { encodings,  encbuf, STRING, READONLY },
 { properties, properties,PROPS,  READONLY },
 -   { full_duplex,fullduplex,UINT,   0 },
 -   { fullduplex, fullduplex,UINT,   0 },
 -   { blocksize,  info.blocksize,UINT,   0 },
 { hiwat,  info.hiwat,UINT,   0 },
 { lowat,  info.lowat,UINT,   0 },
 -   { output_muted,   info.output_muted, UCHAR,  0 },
 -   { monitor_gain,   info.monitor_gain, UINT,   0 },
 { mode,   info.mode, P_R,READONLY },
 { play.rate,  info.play.sample_rate, UINT,   0 },
 { play.sample_rate,   info.play.sample_rate, UINT,   ALIAS },
 @@ -99,19 +92,9 @@ struct field {
 { play.bps,   info.play.bps, UINT,   0 },
 { play.msb,   info.play.msb, UINT,   0 },
 { play.encoding,  info.play.encoding,ENC,0 },
 -   { play.gain,  info.play.gain,UINT,   0 },
 -   { play.balance,   info.play.balance, UCHAR,  0 },
 -   { play.port,  info.play.port,XINT,   0 },
 -   { play.avail_ports,   info.play.avail_ports, XINT,   0 },
 -   { play.seek,  info.play.seek,UINT,   READONLY },
 { play.samples,   info.play.samples, UINT,   READONLY },
 -   { play.eof,   info.play.eof, UINT,   READONLY },
 { play.pause, info.play.pause,   UCHAR,  0 },
 -   { play.error, info.play.error,   UCHAR,  READONLY },
 -   { play.waiting,   info.play.waiting, UCHAR,  READONLY },
 -   { play.open,  info.play.open,UCHAR,  READONLY },
 { play.active,info.play.active,  UCHAR,  READONLY },
 -   { play.buffer_size,   info.play.buffer_size, UINT,   0 },
 { play.block_size,info.play.block_size,  UINT,   0 },
 { play.errors,perrors,   INT,READONLY },
 { record.rate,info.record.sample_rate,UINT,  0 },
 @@ -121,19 +104,9 @@ struct field {
 { record.bps, info.record.bps,   UINT,   0 },
 { record.msb, info.record.msb,   UINT,   0 },
 { record.encoding,info.record.encoding,  ENC,0 },
 -   { record.gain,info.record.gain,  UINT,   0 },
 -   { record.balance, info.record.balance,   UCHAR,  0 },
 -   { record.port,info.record.port,  XINT,   0 },
 -   { record.avail_ports, info.record.avail_ports,XINT,  0 },
 -   { record.seek,info.record.seek,  UINT,   READONLY },
 { record.samples, info.record.samples,   UINT,   READONLY },
 -   { record.eof, info.record.eof,   UINT,   READONLY },
 { record.pause,   info.record.pause, UCHAR,  0 },
 -   { record.error,   info.record.error, UCHAR,  READONLY },
 -   { record.waiting, info.record.waiting,   UCHAR,  READONLY },
 -   { record.open,info.record.open,  UCHAR,  READONLY },
 { record.active,  info.record.active,UCHAR,  READONLY },
 -   { record.buffer_size, info.record.buffer_size,UINT,  0 },
 { record.block_size,  info.record.block_size,UINT,   0 },
 { record.errors,  rerrors,   INT,READONLY },
 { 0 }

Re: PATCH: acpibat - expose capacity as sensor

[Jonathan Armani]

Hi,

I have a similar diff in my tree. I think design capacity could be more
clear for the sensor description.

apart from that, ok armani@ fwiw


2014-05-19 23:58 GMT+02:00 Landry Breuil lan...@rhaalovely.net:

 On Sun, May 18, 2014 at 08:56:15AM +0200, Landry Breuil wrote:
  On Sat, May 17, 2014 at 06:32:10PM +0200, Fabian Raetz wrote:
   Hi,
  
   i want to expose capacity (full capacity design)
   as a sensor like the rest.
  
   This sensor will be used in an upcoming diff to upower to
   expose energy-full-design and capacity properties if
   this patch gets merged.
  
   Both patches together will fix wrong notifications about
   broken batteries in KDE4.
 
  Interesting - i've done a similar thing in the past to enable the 'lid
  open' sysctl status, so i'd welcome this kind of patch. Can you also
  show the diff for upower, and exactly what it fixes for KDE4 ? For
  example, the difference in upower -d output with and without that patch
  ?  What's the exact difference between energy-full-design and capacity
  for upower ?

 i've successfully tested this on i386 (5 years old msi wind U100
 netbook) and amd64 (x200s), with sensors and the upower patch, and i
 think this provides valuable information on the device status. Mike,
 Mark, can you have a look at it ? I'd okay this but that's not my area.

 amd64:

 hw.sensors.acpibtn0.indicator0=On (lid open)
 hw.sensors.acpibat0.power0=19.28 W (rate)
 hw.sensors.acpibat0.watthour0=64.07 Wh (last full capacity)
 hw.sensors.acpibat0.watthour1=3.20 Wh (warning capacity)
 hw.sensors.acpibat0.watthour2=0.20 Wh (low capacity)
 hw.sensors.acpibat0.watthour3=59.04 Wh (remaining capacity), OK
 hw.sensors.acpibat0.watthour4=84.24 Wh (capacity)
 hw.sensors.acpibat0.raw0=2 (battery charging), OK
 hw.sensors.acpiac0.indicator0=On (power supply)


 (upower -d)

 energy:  61.06 Wh
 energy-empty:0.2 Wh
 energy-full: 64.07 Wh
 energy-full-design:  84.24 Wh
 energy-rate: 16.273 W
 voltage: 12.48 V
 percentage:  95%
 capacity:76.0565%

 i386:

 hw.sensors.acpiac0.indicator0=On (power supply)
 hw.sensors.acpibat0.current0=0.56 A (rate)
 hw.sensors.acpibat0.amphour0=2.03 Ah (last full capacity)
 hw.sensors.acpibat0.amphour1=0.00 Ah (warning capacity)
 hw.sensors.acpibat0.amphour2=0.00 Ah (low capacity)
 hw.sensors.acpibat0.amphour3=1.71 Ah (remaining capacity), OK
 hw.sensors.acpibat0.amphour4=4.40 Ah (capacity)
 hw.sensors.acpibat0.raw0=2 (battery charging), OK
 hw.sensors.acpibtn0.indicator0=On (lid open)

 (upower -d)

 state:   fully-charged
 warning-level:   none
 energy:  25.335 Wh
 energy-empty:0 Wh
 energy-full: 25.3599 Wh
 energy-full-design:  54.8592 Wh
 energy-rate: 0 W
 voltage: 12.468 V
 percentage:  99%
 capacity:46.2273%

Re: Fuse (and sshfs) support for OpenBSD

[Jonathan Armani]

On Tue, Mar 05, 2013 at 03:24:06PM +0100, Sylvestre Gallon wrote:

 I am not quite sure but I think that only libfuse and sshfs are GPL
 licenced. The patches for those two items are only present in ports.
 
 All the code present in src is ISC licenced. The kernel communicate with
 libfuse througth a device (ie /dev/fuse) and only share a header with the
 libfuse (fuse_kernel.h) which is BSD licenced. FreeBSD used the same way to
 implement it. (I do not know if it is a good example)
 

Hi Sylvestre,

Nice to see that someone is working on this.

I think the problem here is that the kernel will provide a service that only
ports can use. If we want to use it in the basesystem, we will have to 
rewrite a BSD licenced libfuse.

Other possibility is to make it a loadable kernel module, but I don't know 
the current state of our support.
 

Re: vmmap replacement -- please test

[Jonathan Armani]

On Sat, Feb 18, 2012 at 05:09:02PM +0100, Ariane van der Steldt wrote:
 Hi,
 
 Just to prove my point that vmmap testing is still relevant: today a bug
 got found and fixed, where grepping a 1.7GB file on i386 tripped an
 assertion (I love assertions).
 
 This brings the latest versions to:
 http://www.stack.nl/~ariane/vmmap_sys.diff.65
   (apply against /usr/src/sys)
 http://www.stack.nl/~ariane/vmmap_userland.diff.30
   (apply against /usr/src)
 
 Testing is still welcome. :)
 -- 
 Ariane
 

I use this diff on i386, amd64 and macppc without problem.

Thanks !

Re: vgafb(4) cleaning #3

[Jonathan Armani]

On Thu, Feb 23, 2012 at 06:12:51PM +0100, Martin Pieuchot wrote:
 Diff below is a rewrite the vgafb_pci_probe(). The idea is to save the
 different PCI bars in the device structure for later access in drm(4).
 It also simplifies the code to make it looks more like vga(4).
 
 Ok?
 
 Martin
 

Hi,

No problem running this diff.

hw.model=7447A (Revision 0x101)
vgafb0 at pci0 dev 16 function 0 ATI Radeon Mobility 9200 rev 0x01,
mmio

Re: ALPS Touchpads and pms0: not in sync yet

[Jonathan Armani]

On Thu, Feb 23, 2012 at 06:20:17PM +0100, Martin Pieuchot wrote:
 On 31/01/12(Tue) 16:52, Martin Pieuchot wrote:
  Diff below add support for the missing ALPS Dualpoint touchpads to the
  pms(4) driver. Most of the work has been done by shadchin@ and should
  fix issues you may have seen since pms(4) supports others ALPS devices
  (2011/10).
  
  It adds support for a slightly different version of the ALPS protocol,
  which send 'interleaved' PS2 packets in between absolute ALPS packets.
  Dell laptops (E6xxx and E5500 at least) have this kind of touchpad.
  
  You may have notice the problem if you see pms0: not in sync yet as
  soon as you move your clitpad.
  
  Please report any breakage to shadchin@ and myself.
 
 I've got only two reports, nobody has a Dell E6x00, E5500 or Precision
 M4400?
 
 Any breakage with your already supported synaptics/alps/psm pointer?
 
 Martin
 

Hi,

No regress here.

bios0: Dell Inc. Latitude E4200
pms0: ALPS Glidepoint, version 0x7321

Re: X Intel driver update. [TESTING NEEDED]

[Jonathan Armani]

On Mon, 12 Sep 2011 00:31:46 +0100
Owain Ainsworth zer...@googlemail.com wrote:

 I've been sitting on various stages of this update for far too long,
 about time i sent it out.
 
 This updates the rendering code in the in-tree intel driver to much more
 recent versions of the upstream intel driver, while retaining user
 modesetting code (backporting work by me as well as a few openbsd
 specific changes). This fixes many bugs and provides a large speed
 improvement (especially text rendering) on 965 and above chipsets.
 
 A few bugfixes from kettenis@ are also present fixing some nagging
 issues.
 
 This is a prerequisite for support for sandybridge chipsets so it would
 be good to get it into the tree soon. Testing would be much appreciated.
 Instructions follow:
 
 Download the tarball at http://xenocara.org/src/intel_update.tgz
 
 move /usr/xenocara/driver/xf86-video-intel out of the way and untar the
 tgz from xenocara/drivers
 
 cd xf86-video-intel
 make -f Makefile.bsd-wrapper obj
 make -f Makefile.bsd-wrapper build
 
 Please let me know if you find any issues, otherwise reports of which
 hardware this was testing on to me privately please.
 
 Cheers,
 
 -0-
 -- 
 I was playing poker the other night ... with Tarot cards. I got a full
 house and four people died.
   -- Steven Wright
 
 

Hi,

Works fine on my i386 laptop :
 
vga1 at pci0 dev 2 function 0 Intel GM45 Video rev 0x07
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 0xe000, size 0x1000
inteldrm0 at vga1: apic 2 int 16
drm0 at inteldrm0

Thanks.

-- 
Jonathan Armani

Re: hotplug(4) r1.10 ignoring hotplug_put_event() prior to hotplugopen() [Was: hotplugd(8) ignoring devices attached before boot]

[Jonathan Armani]

On Mon, 13 Dec 2010 14:28:42 +0100, MERIGHI Marcus
mcmer-open...@tor.at wrote:
 mark.kette...@xs4all.nl (Mark Kettenis), 2010.12.13 (Mon) 13:41 (CET):
  Date: Mon, 13 Dec 2010 12:48:55 +0100
  From: MERIGHI Marcus mcmer-open...@tor.at
   That sounds good.  I was aware of the change, but didn't think anybody
   would notice. :)

 A bit late to the game, but I don't really agree with Tedu that the
 changed behaviour is an improvement.  Say I have configured
 hotplugd(8) such that it automatically mounts things when I plug in my
 camera.  Now I reboot my machine, without unplugging the camera.
 Previously hotplugd(8) would remount things upon boot.  Now suddenly
 it doesn't and I have to unplug and replug the camera.
 
 I've had similar usage patterns and I'm gonna miss them.
 

Maybe a bit aggressive, but why not something like this in put_event :

if (!opened  event.type == DETACH) {
 foreach (ev in event_queue)
if (ev.type == ATTACH  ev.devclass == event.devclass 
   ev.devname == event.devname)
remove(ev);
} 

So we remove all attached then detached devices before hotplugd is
started.

  Index: share/man/man4/hotplug.4
  ===
  RCS file: /cvs/src/share/man/man4/hotplug.4,v
  retrieving revision 1.3
  diff -u -r1.3 hotplug.4
  --- share/man/man4/hotplug.4   31 May 2007 19:19:50 -  1.3
  +++ share/man/man4/hotplug.4   13 Dec 2010 11:29:30 -
  @@ -31,7 +31,8 @@
   .Nm
   pseudo-device passes device attachment and detachment events to
   userland.
  -When a device attaches or detaches, the corresponding event is queued.
  +Once the device is opened by userland, when a device attaches or detaches,
  +the corresponding event is queued.
   The events can then be obtained from the queue through the
   .Xr read 2
   call on the

 That looks like an improvement to me.

  Index: usr.sbin/hotplugd/hotplugd.8
  ===
  RCS file: /cvs/src/usr.sbin/hotplugd/hotplugd.8,v
  retrieving revision 1.10
  diff -u -r1.10 hotplugd.8
  --- usr.sbin/hotplugd/hotplugd.8   20 Mar 2009 17:53:14 -  1.10
  +++ usr.sbin/hotplugd/hotplugd.8   13 Dec 2010 11:26:51 -
  @@ -26,9 +26,11 @@
   .Sh DESCRIPTION
   The
   .Nm
  -daemon monitors the
  +daemon opens the
   .Xr hotplug 4
  -pseudo-device, acting on signaled events by executing the scripts in the
  +pseudo-device and thus enables event signaling.
  +It then monitors the device, acting on signaled events by executing the
  +scripts in the
   .Pa /etc/hotplug
   directory.
   By default it uses the

 But this just seems to change the wording without actually changing
 the meaning.  I think the existing wording is better.
 
 I thought it would make clear that only starting hotplugd enables the
 entire hotplug queueing. (As opposed to the old behaviour.)
 
  Index: sys/dev/hotplug.c
  ===
  RCS file: /cvs/src/sys/dev/hotplug.c,v
  retrieving revision 1.10
  diff -u -r1.10 hotplug.c
  --- sys/dev/hotplug.c  2 Dec 2010 04:12:35 -   1.10
  +++ sys/dev/hotplug.c  13 Dec 2010 11:41:59 -
  @@ -89,6 +89,13 @@
 printf(hotplug: event lost, queue full\n);
 return (1);
 }
  +
  +  /*
  +   * Do not queue events prior to hotplugopen anymore. This prevents
  +   * problems where the device is both attached and detached before
  +   * the device is opened.
  +   */

 Adding comments like this, describing historical behaviour really
 isn't such a good idea.
 
 That is beyond my competence.

Re: ACPI C-States diff

[Jonathan Armani]

The patch makes my dell d430 reboot at boot (just after acpi stuff).

jor...@peereboom.us a icrit :

Sending out an initial attempt at implementing C-states for APCI CPUs.
The C-states are used to implement the CPU idle loop per CPU.

Please send dmesgs of booting using this patch.

Index: acpicpu.c
===
RCS file: /cvs/src/sys/dev/acpi/acpicpu.c,v
retrieving revision 1.53
diff -u -p -u -p -b -r1.53 acpicpu.c
--- acpicpu.c   24 Feb 2009 13:20:02 -  1.53
+++ acpicpu.c   7 Jun 2009 19:47:34 -
@@ -41,6 +41,10 @@ int  acpicpu_match(struct device *, void
 void   acpicpu_attach(struct device *, struct device *, void *);
 intacpicpu_notify(struct aml_node *, int, void *);
 void   acpicpu_setperf(int);
+voidacpicpu_idle(void);
+
+#define C2_OVERHEAD4
+#define C3_OVERHEAD4

 #define ACPI_STATE_C0  0x00
 #define ACPI_STATE_C1  0x01
@@ -65,14 +69,20 @@ voidacpicpu_setperf(int);
 /* Make sure throttling bits are valid,a=addr,o=offset,w=width */
 #define valid_throttle(o,w,a)  (a  w  (o+w)=31  (o4 || (o+w)=4))

+TAILQ_HEAD(acpi_cstatehead, acpi_cstate);
+
 struct acpi_cstate
 {
int  type;
int  latency;
int  power;
int  address;
+   int  enter;
+
+   int  pthr, dthr;
+   int  pcount, dcount;

-   SLIST_ENTRY(acpi_cstate) link;
+   TAILQ_ENTRY(acpi_cstate) link;
 };

 struct acpicpu_softc {
@@ -85,7 +95,9 @@ struct acpicpu_softc {
int sc_pblk_len;
int sc_flags;

-   SLIST_HEAD(,acpi_cstate) sc_cstates;
+   int  sc_prevsleep;
+   struct acpi_cstate  *sc_cx;
+   struct acpi_cstatehead   sc_cstates;

bus_space_tag_t sc_iot;
bus_space_handle_t  sc_ioh;
@@ -121,6 +133,8 @@ int acpicpu_getpct(struct acpicpu_softc
 intacpicpu_getpss(struct acpicpu_softc *);
 struct acpi_cstate *acpicpu_add_cstate(struct acpicpu_softc *, int, int,
int,
 int);
+u_int   acpicpu_ticks(struct acpicpu_softc *, u_int, u_int);
+int acpicpu_get_cstaddr(union acpi_resource *, void *);
 #if 0
 voidacpicpu_set_throttle(struct acpicpu_softc *, int);
 struct acpi_cstate *acpicpu_find_cstate(struct acpicpu_softc *, int);
@@ -163,31 +177,36 @@ acpicpu_find_cstate(struct acpicpu_softc
 {
struct acpi_cstate  *cx;

-   SLIST_FOREACH(cx, sc-sc_cstates, link)
+   TAILQ_FOREACH(cx, sc-sc_cstates, link) {
if (cx-type == type)
return cx;
+   }
return (NULL);
 }
 #endif

 struct acpi_cstate *
-acpicpu_add_cstate(struct acpicpu_softc *sc, int type, int latency, int
power,
+acpicpu_add_cstate(struct acpicpu_softc *sc,
+int type, int latency, int power,
 int address)
 {
struct acpi_cstate  *cx;

+   printf(C%d: latency:%d power:%d addr:%.4x\n,
+   type, latency, power, address);
+
dnprintf(10, C%d: latency:.%4x power:%.4x addr:%.8x\n,
type, latency, power, address);

switch (type) {
case ACPI_STATE_C2:
if (latency  ACPI_MAX_C2_LATENCY || !address ||
-   (sc-sc_flags  FLAGS_NO_C2))
+   sc-sc_flags  FLAGS_NO_C2)
goto bad;
break;
case ACPI_STATE_C3:
if (latency  ACPI_MAX_C3_LATENCY || !address ||
-   (sc-sc_flags  FLAGS_NO_C3))
+   sc-sc_flags  FLAGS_NO_C3)
goto bad;
break;
}
@@ -199,7 +218,19 @@ acpicpu_add_cstate(struct acpicpu_softc
cx-latency = latency;
cx-address = address;

-   SLIST_INSERT_HEAD(sc-sc_cstates, cx, link);
+   if (type == ACPI_STATE_C1)
+   cx-pthr = 10;
+   else if (type == ACPI_STATE_C2) {
+   cx-dthr = 1;
+   cx-pthr = 4;
+   }
+   else if (type == ACPI_STATE_C3)
+   cx-dthr = 1;
+
+   TAILQ_INSERT_TAIL(sc-sc_cstates, cx, link);
+
+   if (sc-sc_cx == NULL)
+   sc-sc_cx = cx;

return (cx);
  bad:
@@ -207,21 +238,34 @@ acpicpu_add_cstate(struct acpicpu_softc
return (NULL);
 }

+int
+acpicpu_get_cstaddr(union acpi_resource *crs, void *arg)
+{
+   struct acpi_gas *gas = arg;
+
+   if (AML_CRSTYPE(crs) == LR_GENREGISTER)
+   memcpy(gas, crs-pad+3, sizeof(*gas));
+   return 0;
+}
+
 /* Found a _CST object, add new cstate for each entry */
 void
 acpicpu_add_cstatepkg(struct aml_value *val, void *arg)
 {
struct acpicpu_softc*sc = arg;
+   struct acpi_gas gas;

-#if defined(ACPI_DEBUG)  !defined(SMALL_KERNEL)
-   aml_showvalue(val, 0);
-#endif
if (val-type != AML_OBJTYPE_PACKAGE || val-length != 4)
return;

+   memset(gas, 0, sizeof(gas));
+