date:20140209

Re: Add Intel Centrino Wireless-N 2230 support in iwn(4)

2014-02-09 Thread Benoit Lecocq

On 02/08/14 23:34, Mark Kettenis wrote:

 Hi tech@,

 the diff below adds support for the Intel Centrino Wireless-N 2230 
 card found in my Lenovo E330 to iwn(4). 

 iwn0 at pci2 dev 0 function 0 Intel Centrino Wireless-N 2230 rev 0xc4: 
 msi, MIMO 2T2R, BGN, address 60:6c:66:3b:ea:39

 This is the 0x0888 version.

 I've got most changes from
 https://github.com/seanbruno/freebsd-iwl/commit/53e6056c2df7355650abab77068943ac097a70c6#diff-7a5322b995ac8545b4f5d9096c3b5a5aR5445
  
 which (i think) mostly landed in freebsd as part of
 http://svnweb.freebsd.org/base?view=revisionrevision=258035

 This is the only iwn(4) device i have, so hopefully i did not broke 
 another supported device.
 Any feedback and tests are welcome.

 Regards,
 Fabian Raetz
 
 Hi Fabian,
 
 Finally had some time to look at this.  I cleaned your diff up a bit.
 Also noticed that the sensitivy limits didn't match the Linux driver I
 was looking at.  Does the diff below still result in working hardware
 for you?
 
 Thanks,
 
 Mark
 
 

Hi,

With your patch the network card is detected :

iwn0 at pci3 dev 0 function 0 Intel Centrino Wireless-N 2030 rev 0xc4:
msi, MIMO 2T2R, BGN, address 68:5d:43:20:8b:68

But I have the following message :

iwn0: fatal firmware error
firmware error log:
  error type  = UNKNOWN (0x1038)
  program counter = 0x0002A698
  source line = 0x1014
  error data  = 0x1014
  branch link = 0x0002A5B40002A5B4
  interrupt link  = 0xEC7A
  time= 969333536
driver status:
  tx ring  0: qid=0  cur=6   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=36  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
  tx ring 16: qid=16 cur=0   queued=0
  tx ring 17: qid=17 cur=0   queued=0
  tx ring 18: qid=18 cur=0   queued=0
  tx ring 19: qid=19 cur=0   queued=0
  rx ring: cur=22
  802.11 state 4

I have not the same issue with the patch from Fabian.

Cheers,
benoit


 Index: if_iwn.c
 ===
 RCS file: /cvs/src/sys/dev/pci/if_iwn.c,v
 retrieving revision 1.127
 diff -u -p -r1.127 if_iwn.c
 --- if_iwn.c  6 Dec 2013 21:03:04 -   1.127
 +++ if_iwn.c  8 Feb 2014 22:31:37 -
 @@ -94,6 +94,8 @@ static const struct pci_matchid iwn_devi
   { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_WL_130_2 },
   { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_WL_6235_1 },
   { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_WL_6235_2 },
 + { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_WL_2030_1 },
 + { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_WL_2030_2 },
  };
  
  int  iwn_match(struct device *, void *, void *);
 @@ -244,6 +246,7 @@ int   iwn5000_send_calibration(struct iwn
  int  iwn5000_send_wimax_coex(struct iwn_softc *);
  int  iwn5000_crystal_calib(struct iwn_softc *);
  int  iwn5000_temp_offset_calib(struct iwn_softc *);
 +int  iwn2000_temp_offset_calib(struct iwn_softc *);
  int  iwn4965_post_alive(struct iwn_softc *);
  int  iwn5000_post_alive(struct iwn_softc *);
  int  iwn4965_load_bootcode(struct iwn_softc *, const uint8_t *,
 @@ -651,6 +654,11 @@ iwn5000_attach(struct iwn_softc *sc, pci
   } else
   sc-fwname = iwn-6005;
   break;
 + case IWN_HW_REV_TYPE_2030:
 + sc-limits = iwn2000_sensitivity_limits;
 + sc-fwname = iwn-2030;
 + sc-sc_flags |= IWN_FLAG_ADV_BT_COEX;
 + break;
   default:
   printf(: adapter type %d not supported\n, sc-hw_type);
   return ENOTSUP;
 @@ -1529,6 +1537,14 @@ iwn5000_read_eeprom(struct iwn_softc *sc
   hdr.version, hdr.pa_type, letoh16(hdr.volt)));
   sc-calib_ver = hdr.version;
  
 + if (sc-hw_type == IWN_HW_REV_TYPE_2030) {
 + sc-eeprom_voltage = letoh16(hdr.volt);
 + iwn_read_prom_data(sc, base + IWN5000_EEPROM_TEMP, val, 2);
 + sc-eeprom_temp = letoh16(val);
 + iwn_read_prom_data(sc, base + IWN2000_EEPROM_RAWTEMP, val, 2);
 + sc-eeprom_rawtemp = letoh16(val);
 + }
 +
   if (sc-hw_type == IWN_HW_REV_TYPE_5150) {
   /* Compute temperature offset. */
   iwn_read_prom_data(sc, base + IWN5000_EEPROM_TEMP, val, 2);
 @@ -2095,7 +2111,8 @@ iwn5000_rx_calib_results(struct iwn_soft
  
   switch (calib-code) {
   case IWN5000_PHY_CALIB_DC:
 - if (sc-hw_type == IWN_HW_REV_TYPE_5150)
 + if (sc-hw_type ==

dd status output

2014-02-09 Thread Alexander Bluhm

Hi,

Our dd always prints these status lines to stderr after transfer.  
2+0 records in
2+0 records out
1024 bytes transferred in 0.000 secs (39384615 bytes/sec)

The output is annoying in some situations, so people redirect stderr
to /dev/null.  This approach also suppresses the error messages and
bugs in shell scripts remain undetected.

GNU dd has the status=noxfer and status=none switch to make it
quiet.  Their status=none disables some more warnings, we can add
that later if we want.

I would like to get rid of some 2/dev/null.
Do we want the status=... feature in OpenBSD?

bluhm

Index: bin/dd/args.c
===
RCS file: /data/mirror/openbsd/cvs/src/bin/dd/args.c,v
retrieving revision 1.21
diff -u -p -u -p -r1.21 args.c
--- bin/dd/args.c   11 Nov 2013 23:07:28 -  1.21
+++ bin/dd/args.c   9 Feb 2014 09:21:54 -
@@ -59,6 +59,7 @@ static void   f_obs(char *);
 static voidf_of(char *);
 static voidf_seek(char *);
 static voidf_skip(char *);
+static voidf_status(char *);
 static size_t  get_bsz(char *);
 static off_t   get_off(char *);
 
@@ -78,6 +79,7 @@ static const struct arg {
{ of, f_of,   C_OF,C_OF },
{ seek,   f_seek, C_SEEK,  C_SEEK },
{ skip,   f_skip, C_SKIP,  C_SKIP },
+   { status, f_status,   C_STATUS,C_STATUS },
 };
 
 static char *oper;
@@ -247,6 +249,18 @@ f_skip(char *arg)
 {
 
in.offset = get_off(arg);
+}
+
+static void
+f_status(char *arg)
+{
+
+   if (strcmp(arg, none) == 0)
+   ddflags |= C_NOINFO;
+   else if (strcmp(arg, noxfer) == 0)
+   ddflags |= C_NOXFER;
+   else
+   errx(1, unknown status %s, arg);
 }
 
 
Index: bin/dd/dd.1
===
RCS file: /data/mirror/openbsd/cvs/src/bin/dd/dd.1,v
retrieving revision 1.26
diff -u -p -u -p -r1.26 dd.1
--- bin/dd/dd.1 2 Feb 2014 22:43:40 -   1.26
+++ bin/dd/dd.1 9 Feb 2014 09:56:55 -
@@ -139,6 +139,21 @@ For all other devices, the correct numbe
 distinguishing between a partial or complete block being read.
 .It Xo
 .Sm off
+.Cm status= Ar value
+.Sm on
+.Xc
+Where
+.Ar value
+is one of the symbols from the following list.
+.Bl -tag -width unblock
+.It Cm noxfer
+Do not print the transfer statistics as the last line of status output.
+.It Cm none
+Do not print the status output.
+Error messages are shown, but no informational messages.
+.El
+.It Xo
+.Sm off
 .Cm conv= Ar value Oo ,
 .Sm on
 .Ar value ... Oc
Index: bin/dd/dd.h
===
RCS file: /data/mirror/openbsd/cvs/src/bin/dd/dd.h,v
retrieving revision 1.5
diff -u -p -u -p -r1.5 dd.h
--- bin/dd/dd.h 2 Jun 2003 23:32:07 -   1.5
+++ bin/dd/dd.h 9 Feb 2014 09:16:03 -
@@ -93,3 +93,6 @@ typedef struct {
 #defineC_UCASE 0x4
 #defineC_UNBLOCK   0x8
 #defineC_OSYNC 0x10
+#defineC_STATUS0x20
+#defineC_NOXFER0x40
+#defineC_NOINFO0x80
Index: bin/dd/misc.c
===
RCS file: /data/mirror/openbsd/cvs/src/bin/dd/misc.c,v
retrieving revision 1.17
diff -u -p -u -p -r1.17 misc.c
--- bin/dd/misc.c   16 Apr 2013 22:13:43 -  1.17
+++ bin/dd/misc.c   9 Feb 2014 09:27:25 -
@@ -58,6 +58,9 @@ summary(void)
double microsecs;
int i = 0;
 
+   if (ddflags  C_NOINFO)
+   return;
+
(void)gettimeofday(nowtv, (struct timezone *)NULL);
timersub(nowtv, st.startv, nowtv);
microsecs = ((double)nowtv.tv_sec * 100) + nowtv.tv_usec;
@@ -85,13 +88,15 @@ summary(void)
iov[i].iov_base = buf[2];
iov[i++].iov_len = strlen(buf[2]);
}
-   (void)snprintf(buf[3], sizeof(buf[3]),
-   %qd bytes transferred in %lld.%03ld secs (%0.0f bytes/sec)\n,
-   (long long)st.bytes, (long long)nowtv.tv_sec, nowtv.tv_usec / 1000,
-   ((double)st.bytes * 100) / microsecs);
-
-   iov[i].iov_base = buf[3];
-   iov[i++].iov_len = strlen(buf[3]);
+   if (!(ddflags  C_NOXFER)) {
+   (void)snprintf(buf[3], sizeof(buf[3]),
+   %qd bytes transferred in %lld.%03ld secs 
+   (%0.0f bytes/sec)\n, (long long)st.bytes,
+   (long long)nowtv.tv_sec, nowtv.tv_usec / 1000,
+   ((double)st.bytes * 100) / microsecs);
+   iov[i].iov_base = buf[3];
+   iov[i++].iov_len = strlen(buf[3]);
+   }
 
(void)writev(STDERR_FILENO, iov, i);
 }

Re: dd status output

2014-02-09 Thread Mark Kettenis

 Date: Sun, 9 Feb 2014 12:08:04 +0100
 From: Alexander Bluhm alexander.bl...@gmx.net
 
 Hi,
 
 Our dd always prints these status lines to stderr after transfer.  
 2+0 records in
 2+0 records out
 1024 bytes transferred in 0.000 secs (39384615 bytes/sec)
 
 The output is annoying in some situations, so people redirect stderr
 to /dev/null.  This approach also suppresses the error messages and
 bugs in shell scripts remain undetected.
 
 GNU dd has the status=noxfer and status=none switch to make it
 quiet.  Their status=none disables some more warnings, we can add
 that later if we want.
 
 I would like to get rid of some 2/dev/null.
 Do we want the status=... feature in OpenBSD?

As a general rule we don't want these non-portable extensions unless
they're widely implemented.  Do Solaris, FreeBSD or NetBSD implement
this option?

 Index: bin/dd/args.c
 ===
 RCS file: /data/mirror/openbsd/cvs/src/bin/dd/args.c,v
 retrieving revision 1.21
 diff -u -p -u -p -r1.21 args.c
 --- bin/dd/args.c 11 Nov 2013 23:07:28 -  1.21
 +++ bin/dd/args.c 9 Feb 2014 09:21:54 -
 @@ -59,6 +59,7 @@ static void f_obs(char *);
  static void  f_of(char *);
  static void  f_seek(char *);
  static void  f_skip(char *);
 +static void  f_status(char *);
  static size_tget_bsz(char *);
  static off_t get_off(char *);
  
 @@ -78,6 +79,7 @@ static const struct arg {
   { of, f_of,   C_OF,C_OF },
   { seek,   f_seek, C_SEEK,  C_SEEK },
   { skip,   f_skip, C_SKIP,  C_SKIP },
 + { status, f_status,   C_STATUS,C_STATUS },
  };
  
  static char *oper;
 @@ -247,6 +249,18 @@ f_skip(char *arg)
  {
  
   in.offset = get_off(arg);
 +}
 +
 +static void
 +f_status(char *arg)
 +{
 +
 + if (strcmp(arg, none) == 0)
 + ddflags |= C_NOINFO;
 + else if (strcmp(arg, noxfer) == 0)
 + ddflags |= C_NOXFER;
 + else
 + errx(1, unknown status %s, arg);
  }
  
  
 Index: bin/dd/dd.1
 ===
 RCS file: /data/mirror/openbsd/cvs/src/bin/dd/dd.1,v
 retrieving revision 1.26
 diff -u -p -u -p -r1.26 dd.1
 --- bin/dd/dd.1   2 Feb 2014 22:43:40 -   1.26
 +++ bin/dd/dd.1   9 Feb 2014 09:56:55 -
 @@ -139,6 +139,21 @@ For all other devices, the correct numbe
  distinguishing between a partial or complete block being read.
  .It Xo
  .Sm off
 +.Cm status= Ar value
 +.Sm on
 +.Xc
 +Where
 +.Ar value
 +is one of the symbols from the following list.
 +.Bl -tag -width unblock
 +.It Cm noxfer
 +Do not print the transfer statistics as the last line of status output.
 +.It Cm none
 +Do not print the status output.
 +Error messages are shown, but no informational messages.
 +.El
 +.It Xo
 +.Sm off
  .Cm conv= Ar value Oo ,
  .Sm on
  .Ar value ... Oc
 Index: bin/dd/dd.h
 ===
 RCS file: /data/mirror/openbsd/cvs/src/bin/dd/dd.h,v
 retrieving revision 1.5
 diff -u -p -u -p -r1.5 dd.h
 --- bin/dd/dd.h   2 Jun 2003 23:32:07 -   1.5
 +++ bin/dd/dd.h   9 Feb 2014 09:16:03 -
 @@ -93,3 +93,6 @@ typedef struct {
  #define  C_UCASE 0x4
  #define  C_UNBLOCK   0x8
  #define  C_OSYNC 0x10
 +#define  C_STATUS0x20
 +#define  C_NOXFER0x40
 +#define  C_NOINFO0x80
 Index: bin/dd/misc.c
 ===
 RCS file: /data/mirror/openbsd/cvs/src/bin/dd/misc.c,v
 retrieving revision 1.17
 diff -u -p -u -p -r1.17 misc.c
 --- bin/dd/misc.c 16 Apr 2013 22:13:43 -  1.17
 +++ bin/dd/misc.c 9 Feb 2014 09:27:25 -
 @@ -58,6 +58,9 @@ summary(void)
   double microsecs;
   int i = 0;
  
 + if (ddflags  C_NOINFO)
 + return;
 +
   (void)gettimeofday(nowtv, (struct timezone *)NULL);
   timersub(nowtv, st.startv, nowtv);
   microsecs = ((double)nowtv.tv_sec * 100) + nowtv.tv_usec;
 @@ -85,13 +88,15 @@ summary(void)
   iov[i].iov_base = buf[2];
   iov[i++].iov_len = strlen(buf[2]);
   }
 - (void)snprintf(buf[3], sizeof(buf[3]),
 - %qd bytes transferred in %lld.%03ld secs (%0.0f bytes/sec)\n,
 - (long long)st.bytes, (long long)nowtv.tv_sec, nowtv.tv_usec / 1000,
 - ((double)st.bytes * 100) / microsecs);
 -
 - iov[i].iov_base = buf[3];
 - iov[i++].iov_len = strlen(buf[3]);
 + if (!(ddflags  C_NOXFER)) {
 + (void)snprintf(buf[3], sizeof(buf[3]),
 + %qd bytes transferred in %lld.%03ld secs 
 + (%0.0f bytes/sec)\n, (long long)st.bytes,
 + (long long)nowtv.tv_sec, nowtv.tv_usec / 1000,
 + ((double)st.bytes * 100) / microsecs);
 + iov[i].iov_base = buf[3];
 + iov[i++].iov_len =

Re: Add Intel Centrino Wireless-N 2230 support in iwn(4)

2014-02-09 Thread Mark Kettenis

 Date: Sun, 09 Feb 2014 10:34:04 +0100
 From: Benoit Lecocq b...@arcane-labs.net
 
 On 02/08/14 23:34, Mark Kettenis wrote:
 
  Hi tech@,
 
  the diff below adds support for the Intel Centrino Wireless-N 2230 
  card found in my Lenovo E330 to iwn(4). 
 
  iwn0 at pci2 dev 0 function 0 Intel Centrino Wireless-N 2230 rev 0xc4: 
  msi, MIMO 2T2R, BGN, address 60:6c:66:3b:ea:39
 
  This is the 0x0888 version.
 
  I've got most changes from
  https://github.com/seanbruno/freebsd-iwl/commit/53e6056c2df7355650abab77068943ac097a70c6#diff-7a5322b995ac8545b4f5d9096c3b5a5aR5445
   
  which (i think) mostly landed in freebsd as part of
  http://svnweb.freebsd.org/base?view=revisionrevision=258035
 
  This is the only iwn(4) device i have, so hopefully i did not broke 
  another supported device.
  Any feedback and tests are welcome.
 
  Regards,
  Fabian Raetz
  
  Hi Fabian,
  
  Finally had some time to look at this.  I cleaned your diff up a bit.
  Also noticed that the sensitivy limits didn't match the Linux driver I
  was looking at.  Does the diff below still result in working hardware
  for you?
  
  Thanks,
  
  Mark
  
  
 
 Hi,
 
 With your patch the network card is detected :
 
 iwn0 at pci3 dev 0 function 0 Intel Centrino Wireless-N 2030 rev 0xc4:
 msi, MIMO 2T2R, BGN, address 68:5d:43:20:8b:68
 
 But I have the following message :
 
 iwn0: fatal firmware error
 firmware error log:
   error type  = UNKNOWN (0x1038)
   program counter = 0x0002A698
   source line = 0x1014
   error data  = 0x1014
   branch link = 0x0002A5B40002A5B4
   interrupt link  = 0xEC7A
   time= 969333536
 driver status:
   tx ring  0: qid=0  cur=6   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=36  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
   tx ring 16: qid=16 cur=0   queued=0
   tx ring 17: qid=17 cur=0   queued=0
   tx ring 18: qid=18 cur=0   queued=0
   tx ring 19: qid=19 cur=0   queued=0
   rx ring: cur=22
   802.11 state 4
 
 I have not the same issue with the patch from Fabian.

Does the interface work despite this message?

Does the following diff work better?


Index: if_iwn.c
===
RCS file: /cvs/src/sys/dev/pci/if_iwn.c,v
retrieving revision 1.127
diff -u -p -r1.127 if_iwn.c
--- if_iwn.c6 Dec 2013 21:03:04 -   1.127
+++ if_iwn.c9 Feb 2014 11:18:29 -
@@ -94,6 +94,8 @@ static const struct pci_matchid iwn_devi
{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_WL_130_2 },
{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_WL_6235_1 },
{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_WL_6235_2 },
+   { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_WL_2030_1 },
+   { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_WL_2030_2 },
 };
 
 intiwn_match(struct device *, void *, void *);
@@ -244,6 +246,7 @@ int iwn5000_send_calibration(struct iwn
 intiwn5000_send_wimax_coex(struct iwn_softc *);
 intiwn5000_crystal_calib(struct iwn_softc *);
 intiwn5000_temp_offset_calib(struct iwn_softc *);
+intiwn2000_temp_offset_calib(struct iwn_softc *);
 intiwn4965_post_alive(struct iwn_softc *);
 intiwn5000_post_alive(struct iwn_softc *);
 intiwn4965_load_bootcode(struct iwn_softc *, const uint8_t *,
@@ -651,6 +654,11 @@ iwn5000_attach(struct iwn_softc *sc, pci
} else
sc-fwname = iwn-6005;
break;
+   case IWN_HW_REV_TYPE_2030:
+   sc-limits = iwn2000_sensitivity_limits;
+   sc-fwname = iwn-2030;
+   sc-sc_flags |= IWN_FLAG_ADV_BT_COEX;
+   break;
default:
printf(: adapter type %d not supported\n, sc-hw_type);
return ENOTSUP;
@@ -1529,6 +1537,14 @@ iwn5000_read_eeprom(struct iwn_softc *sc
hdr.version, hdr.pa_type, letoh16(hdr.volt)));
sc-calib_ver = hdr.version;
 
+   if (sc-hw_type == IWN_HW_REV_TYPE_2030) {
+   sc-eeprom_voltage = letoh16(hdr.volt);
+   iwn_read_prom_data(sc, base + IWN5000_EEPROM_TEMP, val, 2);
+   sc-eeprom_temp = letoh16(val);
+   iwn_read_prom_data(sc, base + IWN2000_EEPROM_RAWTEMP, val, 2);
+   sc-eeprom_rawtemp = letoh16(val);
+   }
+
if (sc-hw_type == IWN_HW_REV_TYPE_5150) {
/* Compute temperature offset. */
iwn_read_prom_data(sc, base +

Re: dd status output

2014-02-09 Thread Alexander Bluhm

On Sun, Feb 09, 2014 at 12:21:35PM +0100, Mark Kettenis wrote:
  Date: Sun, 9 Feb 2014 12:08:04 +0100
  From: Alexander Bluhm alexander.bl...@gmx.net

  I would like to get rid of some 2/dev/null.
  Do we want the status=... feature in OpenBSD?

 As a general rule we don't want these non-portable extensions unless
 they're widely implemented.

I know and feel the same way.  But I consider 2/dev/null in shell
scripts more evil.  Instead of inventing something new, I used GNU.

 Do Solaris, FreeBSD or NetBSD implement this option?

According to their man page, Solaris and FreeBSD don't have it.
NetBSD has msgfmt=quiet which allows much more funky extensions.

bluhm

churn in pkg_add code

2014-02-09 Thread Marc Espie

hopefully, things should be back to normal.
last commit was

revision 1.37 of PackageLocation.pm
date: 2014/02/09 11:13:59;  author: espie;  state: Exp;  lines: +4 -3;
do a better job in wipe_info: close files and reap children.
also wipe every state variable... fixes reget update_info in fringe
cases (this should fix nigel@'s problems...)


pkg_add memory usage is back down to reasonable levels, after two large
fixes, and a heck of a lot of small changes... with tidying up and minor
bug fixes along the way (well, some of them probably not so minor).

Just to put things in perspective, my big testcase backed down from
480M to 280M... and in more normal cases, usage stops growing.

The two large fixes were to prevent ProgressMeter/Term.pm from capturing
full plists (with their sha values and all that long post the peremption
date) and to limit the number of locally opened IO::Uncompress::Gunzip handles
to 3 (issue was already there for fork()d gunzip, but as extra processes
hanging around...).  Small fixes include shrinking conflict representation,
bringing full packing-lists in only AFTER solving dependencies, not storing
full objects for simple shared dirs, and a lot lot of work on caching
disk access better (PackageLocation/Repository cleanup fixes).

Kuddoes to pirofti@  for suggesting some awesome introspection tools
(Devel::Leak::Object, Devel::BackRef, Devel::Gladiator. That stuff rocks).


So if you notice suspicious things and you have the current version, report
them asap... there's precious little time to fix them before the release.

Re: churn in pkg_add code

2014-02-09 Thread Marc Espie

On Sun, Feb 09, 2014 at 01:16:38PM +0100, Marc Espie wrote:
 hopefully, things should be back to normal.
 last commit was
 
 revision 1.37 of PackageLocation.pm
 date: 2014/02/09 11:13:59;  author: espie;  state: Exp;  lines: +4 -3;
 do a better job in wipe_info: close files and reap children.
 also wipe every state variable... fixes reget update_info in fringe
 cases (this should fix nigel@'s problems...)

And of course, I fucked something obvious up...

So the good commit is revision 1.38

Re: dd status output

2014-02-09 Thread Mark Kettenis

 Date: Sun, 9 Feb 2014 12:57:40 +0100
 From: Alexander Bluhm alexander.bl...@gmx.net

 On Sun, Feb 09, 2014 at 12:21:35PM +0100, Mark Kettenis wrote:
   Date: Sun, 9 Feb 2014 12:08:04 +0100
   From: Alexander Bluhm alexander.bl...@gmx.net

   I would like to get rid of some 2/dev/null.
   Do we want the status=... feature in OpenBSD?

  As a general rule we don't want these non-portable extensions unless
  they're widely implemented.

 I know and feel the same way.  But I consider 2/dev/null in shell
 scripts more evil.  Instead of inventing something new, I used GNU.

Perhaps we should ask ourselves the question why this gets printed on
stderr instead of stdout?

Re: dd status output

2014-02-09 Thread Alexander Bluhm

On Sun, Feb 09, 2014 at 01:51:30PM +0100, Mark Kettenis wrote:
 Perhaps we should ask ourselves the question why this gets printed on
 stderr instead of stdout?

Per default dd writes the file data to stdout already.

Re: Add Intel Centrino Wireless-N 2230 support in iwn(4)

2014-02-09 Thread Fabian Raetz

On Sun, Feb 09, 2014 at 01:51:19PM +0100, Benoit Lecocq wrote:
 On 02/09/14 12:30, Mark Kettenis wrote:
  Date: Sun, 09 Feb 2014 10:34:04 +0100
  From: Benoit Lecocq b...@arcane-labs.net
 
  On 02/08/14 23:34, Mark Kettenis wrote:
 
  Hi tech@,
 
  the diff below adds support for the Intel Centrino Wireless-N 2230 
  card found in my Lenovo E330 to iwn(4). 
 
  iwn0 at pci2 dev 0 function 0 Intel Centrino Wireless-N 2230 rev 0xc4: 
  msi, MIMO 2T2R, BGN, address 60:6c:66:3b:ea:39
 
  This is the 0x0888 version.
 
  I've got most changes from
  https://github.com/seanbruno/freebsd-iwl/commit/53e6056c2df7355650abab77068943ac097a70c6#diff-7a5322b995ac8545b4f5d9096c3b5a5aR5445
   
  which (i think) mostly landed in freebsd as part of
  http://svnweb.freebsd.org/base?view=revisionrevision=258035
 
  This is the only iwn(4) device i have, so hopefully i did not broke 
  another supported device.
  Any feedback and tests are welcome.
 
  Regards,
  Fabian Raetz
 
  Hi Fabian,
 
  Finally had some time to look at this.  I cleaned your diff up a bit.
  Also noticed that the sensitivy limits didn't match the Linux driver I
  was looking at.  Does the diff below still result in working hardware
  for you?
 
  Thanks,
 
  Mark
 
 
 
  Hi,
 
  With your patch the network card is detected :
 
  iwn0 at pci3 dev 0 function 0 Intel Centrino Wireless-N 2030 rev 0xc4:
  msi, MIMO 2T2R, BGN, address 68:5d:43:20:8b:68
 
  But I have the following message :
 
  iwn0: fatal firmware error
  firmware error log:
error type  = UNKNOWN (0x1038)
program counter = 0x0002A698
source line = 0x1014
error data  = 0x1014
branch link = 0x0002A5B40002A5B4
interrupt link  = 0xEC7A
time= 969333536
  driver status:
tx ring  0: qid=0  cur=6   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=36  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
tx ring 16: qid=16 cur=0   queued=0
tx ring 17: qid=17 cur=0   queued=0
tx ring 18: qid=18 cur=0   queued=0
tx ring 19: qid=19 cur=0   queued=0
rx ring: cur=22
802.11 state 4
 
  I have not the same issue with the patch from Fabian.
  
  Does the interface work despite this message?
  
  Does the following diff work better?
  
 
 Yes the interface work despite the message.
 
 Same messages with the new diff :
 
 iwn0: fatal firmware error
 firmware error log:
   error type  = UNKNOWN (0x1967)
   program counter = 0x99C4
   source line = 0x009F
   error data  = 0x00FF0013
   branch link = 0x99BA99BA
   interrupt link  = 0xEC7A
   time= 254992438
 driver status:
   tx ring  0: qid=0  cur=70  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=36  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
   tx ring 16: qid=16 cur=0   queued=0
   tx ring 17: qid=17 cur=0   queued=0
   tx ring 18: qid=18 cur=0   queued=0
   tx ring 19: qid=19 cur=0   queued=0
   rx ring: cur=22
   802.11 state 4
 
 
Hi,

i'm seeing the firmware error too with both of your diffs
and i'm pretty sure i fixed this firmware error in my
last diff send to this thread by handling IWN_FW_TLV_SENS and
IWN_FW_TLV_PHY_CALIB in iwn_read_firmware_tlv()

Except the firmware error, the card is working fine.

Regards,
Fabian

Re: Add Intel Centrino Wireless-N 2230 support in iwn(4)

2014-02-09 Thread Mark Kettenis

 Date: Sun, 9 Feb 2014 14:07:53 +0100
 From: Fabian Raetz fabian.ra...@gmail.com
 
 On Sun, Feb 09, 2014 at 01:51:19PM +0100, Benoit Lecocq wrote:
  On 02/09/14 12:30, Mark Kettenis wrote:
   Date: Sun, 09 Feb 2014 10:34:04 +0100
   From: Benoit Lecocq b...@arcane-labs.net
  
   On 02/08/14 23:34, Mark Kettenis wrote:
  
   Hi tech@,
  
   the diff below adds support for the Intel Centrino Wireless-N 2230 
   card found in my Lenovo E330 to iwn(4). 
  
   iwn0 at pci2 dev 0 function 0 Intel Centrino Wireless-N 2230 rev 
   0xc4: msi, MIMO 2T2R, BGN, address 60:6c:66:3b:ea:39
  
   This is the 0x0888 version.
  
   I've got most changes from
   https://github.com/seanbruno/freebsd-iwl/commit/53e6056c2df7355650abab77068943ac097a70c6#diff-7a5322b995ac8545b4f5d9096c3b5a5aR5445

   which (i think) mostly landed in freebsd as part of
   http://svnweb.freebsd.org/base?view=revisionrevision=258035
  
   This is the only iwn(4) device i have, so hopefully i did not broke 
   another supported device.
   Any feedback and tests are welcome.
  
   Regards,
   Fabian Raetz
  
   Hi Fabian,
  
   Finally had some time to look at this.  I cleaned your diff up a bit.
   Also noticed that the sensitivy limits didn't match the Linux driver I
   was looking at.  Does the diff below still result in working hardware
   for you?
  
   Thanks,
  
   Mark
  
  
  
   Hi,
  
   With your patch the network card is detected :
  
   iwn0 at pci3 dev 0 function 0 Intel Centrino Wireless-N 2030 rev 0xc4:
   msi, MIMO 2T2R, BGN, address 68:5d:43:20:8b:68
  
   But I have the following message :
  
   iwn0: fatal firmware error
   firmware error log:
 error type  = UNKNOWN (0x1038)
 program counter = 0x0002A698
 source line = 0x1014
 error data  = 0x1014
 branch link = 0x0002A5B40002A5B4
 interrupt link  = 0xEC7A
 time= 969333536
   driver status:
 tx ring  0: qid=0  cur=6   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=36  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
 tx ring 16: qid=16 cur=0   queued=0
 tx ring 17: qid=17 cur=0   queued=0
 tx ring 18: qid=18 cur=0   queued=0
 tx ring 19: qid=19 cur=0   queued=0
 rx ring: cur=22
 802.11 state 4
  
   I have not the same issue with the patch from Fabian.
   
   Does the interface work despite this message?
   
   Does the following diff work better?
   
  
  Yes the interface work despite the message.
  
  Same messages with the new diff :
  
  iwn0: fatal firmware error
  firmware error log:
error type  = UNKNOWN (0x1967)
program counter = 0x99C4
source line = 0x009F
error data  = 0x00FF0013
branch link = 0x99BA99BA
interrupt link  = 0xEC7A
time= 254992438
  driver status:
tx ring  0: qid=0  cur=70  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=36  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
tx ring 16: qid=16 cur=0   queued=0
tx ring 17: qid=17 cur=0   queued=0
tx ring 18: qid=18 cur=0   queued=0
tx ring 19: qid=19 cur=0   queued=0
rx ring: cur=22
802.11 state 4
  
  
 Hi,
 
 i'm seeing the firmware error too with both of your diffs
 and i'm pretty sure i fixed this firmware error in my
 last diff send to this thread by handling IWN_FW_TLV_SENS and
 IWN_FW_TLV_PHY_CALIB in iwn_read_firmware_tlv()

Hmm, my cleanup was based on the version you send out on December
31st.  Can you send me the latest version of your diff?

Re: Add Intel Centrino Wireless-N 2230 support in iwn(4)

2014-02-09 Thread Fabian Raetz

 
 Hmm, my cleanup was based on the version you send out on December
 31st.  Can you send me the latest version of your diff?
 

On Tue, Jan 07, 2014 at 12:08:02PM +0100, Martin Pieuchot wrote:
 On 03/01/14(Fri) 14:24, Fabian Raetz wrote:
  Hi tech@,
  
  here is an updated patch.
  
  it seems like Intel Centrino Wireless-N 2030 and
  Intel Centrino Wireless-N 2230 have the same pciids...
  
  this makes patch apply again with newest pcidevs changes.
 
 Please also make sure to use tab and not space when appropriate ;)  You
 can check style(9) if in doubt !
 
ups :)
attached is a diff
- which follows style(9) (hopefully) and
- fixes a firmware error by handling IWN_FW_TLV_ENH_SENS and
  IWN_FW_TLV_PHY_CALIB in iwn_read_firmware_tlv().

@mike, only style changes since the last patch i send you.

Regards,
Fabian


Index: if_iwn.c
===
RCS file: /cvs/src/sys/dev/pci/if_iwn.c,v
retrieving revision 1.127
diff -u -p -r1.127 if_iwn.c
--- if_iwn.c6 Dec 2013 21:03:04 -   1.127
+++ if_iwn.c7 Jan 2014 20:51:38 -
@@ -94,6 +94,8 @@ static const struct pci_matchid iwn_devi
{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_WL_130_2 },
{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_WL_6235_1 },
{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_WL_6235_2 },
+   { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_WL_2x30_1 },
+   { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_WL_2x30_2 },
 };
 
 intiwn_match(struct device *, void *, void *);
@@ -244,6 +246,7 @@ int iwn5000_send_calibration(struct iwn
 intiwn5000_send_wimax_coex(struct iwn_softc *);
 intiwn5000_crystal_calib(struct iwn_softc *);
 intiwn5000_temp_offset_calib(struct iwn_softc *);
+intiwn5000_temp_offset_calibv2(struct iwn_softc *);
 intiwn4965_post_alive(struct iwn_softc *);
 intiwn5000_post_alive(struct iwn_softc *);
 intiwn4965_load_bootcode(struct iwn_softc *, const uint8_t *,
@@ -605,6 +608,8 @@ iwn5000_attach(struct iwn_softc *sc, pci
sc-fw_data_maxsz = IWN5000_FW_DATA_MAXSZ;
sc-fwsz = IWN5000_FWSZ;
sc-sched_txfact_addr = IWN5000_SCHED_TXFACT;
+   sc-reset_noise_gain = IWN5000_PHY_CALIB_RESET_NOISE_GAIN;
+   sc-noise_gain = IWN5000_PHY_CALIB_NOISE_GAIN;
 
switch (sc-hw_type) {
case IWN_HW_REV_TYPE_5100:
@@ -651,6 +656,11 @@ iwn5000_attach(struct iwn_softc *sc, pci
} else
sc-fwname = iwn-6005;
break;
+   case IWN_HW_REV_TYPE_2030:
+   sc-limits = iwn2030_sensitivity_limits;
+   sc-fwname = iwn-2030;
+   sc-sc_flags |= IWN_FLAG_ADV_BT_COEX;
+   break;
default:
printf(: adapter type %d not supported\n, sc-hw_type);
return ENOTSUP;
@@ -1529,6 +1539,14 @@ iwn5000_read_eeprom(struct iwn_softc *sc
hdr.version, hdr.pa_type, letoh16(hdr.volt)));
sc-calib_ver = hdr.version;
 
+   if (sc-hw_type == IWN_HW_REV_TYPE_2030) {
+   sc-eeprom_voltage = letoh16(hdr.volt);
+   iwn_read_prom_data(sc, base + IWN5000_EEPROM_TEMP, val, 2);
+   sc-eeprom_temp_high = letoh16(val);
+   iwn_read_prom_data(sc, base + IWN5000_EEPROM_VOLT, val, 2);
+   sc-eeprom_temp = letoh16(val);
+   }
+
if (sc-hw_type == IWN_HW_REV_TYPE_5150) {
/* Compute temperature offset. */
iwn_read_prom_data(sc, base + IWN5000_EEPROM_TEMP, val, 2);
@@ -2095,7 +2113,8 @@ iwn5000_rx_calib_results(struct iwn_soft
 
switch (calib-code) {
case IWN5000_PHY_CALIB_DC:
-   if (sc-hw_type == IWN_HW_REV_TYPE_5150)
+   if (sc-hw_type == IWN_HW_REV_TYPE_5150 ||
+   sc-hw_type == IWN_HW_REV_TYPE_2030)
idx = 0;
break;
case IWN5000_PHY_CALIB_LO:
@@ -3822,7 +3841,7 @@ iwn5000_init_gains(struct iwn_softc *sc)
struct iwn_phy_calib cmd;
 
memset(cmd, 0, sizeof cmd);
-   cmd.code = IWN5000_PHY_CALIB_RESET_NOISE_GAIN;
+   cmd.code = sc-reset_noise_gain;
cmd.ngroups = 1;
cmd.isvalid = 1;
DPRINTF((setting initial differential gains\n));
@@ -3872,7 +3891,7 @@ iwn5000_set_gains(struct iwn_softc *sc)
div = (sc-hw_type == IWN_HW_REV_TYPE_6050) ? 20 : 30;
 
memset(cmd, 0, sizeof cmd);
-   cmd.code = IWN5000_PHY_CALIB_NOISE_GAIN;
+   cmd.code = sc-noise_gain;
cmd.ngroups = 1;
cmd.isvalid = 1;
/* Get first available RX antenna as referential. */
@@ -4161,28 +4180,51 @@ iwn_send_advanced_btcoex(struct iwn_soft
0xc0004000, 0x4000, 0xf0005000, 0xf0005000,
};
struct iwn6000_btcoex_config btconfig;
+   struct iwn2000_btcoex_config btconfig2k;
struct iwn_btcoex_priotable btprio;
struct iwn_btcoex_prot btprot;

Re: churn in pkg_add code

2014-02-09 Thread Marc Espie

On Sun, Feb 09, 2014 at 01:16:38PM +0100, Marc Espie wrote:
 hopefully, things should be back to normal.
 last commit was
 
 revision 1.37 of PackageLocation.pm
 date: 2014/02/09 11:13:59;  author: espie;  state: Exp;  lines: +4 -3;
 do a better job in wipe_info: close files and reap children.
 also wipe every state variable... fixes reget update_info in fringe
 cases (this should fix nigel@'s problems...)

And a second fix... revision 1.39 is the right one...

Sending an mail to say  problem fixed always works. If you don't do it,
the bugs stay hidden in the woodwork :)

Re: churn in pkg_add code

2014-02-09 Thread Antoine Jacoutot

On Sun, Feb 09, 2014 at 03:26:56PM +0100, Marc Espie wrote:
 On Sun, Feb 09, 2014 at 01:16:38PM +0100, Marc Espie wrote:
  hopefully, things should be back to normal.
  last commit was
  
  revision 1.37 of PackageLocation.pm
  date: 2014/02/09 11:13:59;  author: espie;  state: Exp;  lines: +4 -3;
  do a better job in wipe_info: close files and reap children.
  also wipe every state variable... fixes reget update_info in fringe
  cases (this should fix nigel@'s problems...)
 
 And a second fix... revision 1.39 is the right one...
 
 Sending an mail to say  problem fixed always works. If you don't do it,
 the bugs stay hidden in the woodwork :)

I will wait for r1.40 then...

-- 
Antoine

Re: Add Intel Centrino Wireless-N 2230 support in iwn(4)

2014-02-09 Thread Fabian Raetz

On Sun, Feb 09, 2014 at 10:40:57AM -0500, Brad Smith wrote:
 On Sun, Feb 09, 2014 at 02:23:18PM +0100, Fabian Raetz wrote:
   
   Hmm, my cleanup was based on the version you send out on December
   31st.  Can you send me the latest version of your diff?
   
  
  On Tue, Jan 07, 2014 at 12:08:02PM +0100, Martin Pieuchot wrote:
   On 03/01/14(Fri) 14:24, Fabian Raetz wrote:
Hi tech@,

here is an updated patch.

it seems like Intel Centrino Wireless-N 2030 and
Intel Centrino Wireless-N 2230 have the same pciids...

this makes patch apply again with newest pcidevs changes.
   
   Please also make sure to use tab and not space when appropriate ;)  You
   can check style(9) if in doubt !
   
  ups :)
  attached is a diff
  - which follows style(9) (hopefully) and
  - fixes a firmware error by handling IWN_FW_TLV_ENH_SENS and
IWN_FW_TLV_PHY_CALIB in iwn_read_firmware_tlv().
  
  @mike, only style changes since the last patch i send you.
  
  Regards,
  Fabian
  
 Post the diff again but remove the pcidevs change.
  

Index: if_iwn.c
===
RCS file: /cvs/src/sys/dev/pci/if_iwn.c,v
retrieving revision 1.127
diff -u -p -r1.127 if_iwn.c
--- if_iwn.c6 Dec 2013 21:03:04 -   1.127
+++ if_iwn.c9 Feb 2014 16:41:10 -
@@ -94,6 +94,8 @@ static const struct pci_matchid iwn_devi
{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_WL_130_2 },
{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_WL_6235_1 },
{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_WL_6235_2 },
+   { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_WL_2030_1 },
+   { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_WL_2030_2 },
 };
 
 intiwn_match(struct device *, void *, void *);
@@ -244,6 +246,7 @@ int iwn5000_send_calibration(struct iwn
 intiwn5000_send_wimax_coex(struct iwn_softc *);
 intiwn5000_crystal_calib(struct iwn_softc *);
 intiwn5000_temp_offset_calib(struct iwn_softc *);
+intiwn5000_temp_offset_calibv2(struct iwn_softc *);
 intiwn4965_post_alive(struct iwn_softc *);
 intiwn5000_post_alive(struct iwn_softc *);
 intiwn4965_load_bootcode(struct iwn_softc *, const uint8_t *,
@@ -605,6 +608,8 @@ iwn5000_attach(struct iwn_softc *sc, pci
sc-fw_data_maxsz = IWN5000_FW_DATA_MAXSZ;
sc-fwsz = IWN5000_FWSZ;
sc-sched_txfact_addr = IWN5000_SCHED_TXFACT;
+   sc-reset_noise_gain = IWN5000_PHY_CALIB_RESET_NOISE_GAIN;
+   sc-noise_gain = IWN5000_PHY_CALIB_NOISE_GAIN;
 
switch (sc-hw_type) {
case IWN_HW_REV_TYPE_5100:
@@ -651,6 +656,11 @@ iwn5000_attach(struct iwn_softc *sc, pci
} else
sc-fwname = iwn-6005;
break;
+   case IWN_HW_REV_TYPE_2030:
+   sc-limits = iwn2030_sensitivity_limits;
+   sc-fwname = iwn-2030;
+   sc-sc_flags |= IWN_FLAG_ADV_BT_COEX;
+   break;
default:
printf(: adapter type %d not supported\n, sc-hw_type);
return ENOTSUP;
@@ -1529,6 +1539,14 @@ iwn5000_read_eeprom(struct iwn_softc *sc
hdr.version, hdr.pa_type, letoh16(hdr.volt)));
sc-calib_ver = hdr.version;
 
+   if (sc-hw_type == IWN_HW_REV_TYPE_2030) {
+   sc-eeprom_voltage = letoh16(hdr.volt);
+   iwn_read_prom_data(sc, base + IWN5000_EEPROM_TEMP, val, 2);
+   sc-eeprom_temp_high = letoh16(val);
+   iwn_read_prom_data(sc, base + IWN5000_EEPROM_VOLT, val, 2);
+   sc-eeprom_temp = letoh16(val);
+   }
+
if (sc-hw_type == IWN_HW_REV_TYPE_5150) {
/* Compute temperature offset. */
iwn_read_prom_data(sc, base + IWN5000_EEPROM_TEMP, val, 2);
@@ -2095,7 +2113,8 @@ iwn5000_rx_calib_results(struct iwn_soft
 
switch (calib-code) {
case IWN5000_PHY_CALIB_DC:
-   if (sc-hw_type == IWN_HW_REV_TYPE_5150)
+   if (sc-hw_type == IWN_HW_REV_TYPE_5150 ||
+   sc-hw_type == IWN_HW_REV_TYPE_2030)
idx = 0;
break;
case IWN5000_PHY_CALIB_LO:
@@ -3822,7 +3841,7 @@ iwn5000_init_gains(struct iwn_softc *sc)
struct iwn_phy_calib cmd;
 
memset(cmd, 0, sizeof cmd);
-   cmd.code = IWN5000_PHY_CALIB_RESET_NOISE_GAIN;
+   cmd.code = sc-reset_noise_gain;
cmd.ngroups = 1;
cmd.isvalid = 1;
DPRINTF((setting initial differential gains\n));
@@ -3872,7 +3891,7 @@ iwn5000_set_gains(struct iwn_softc *sc)
div = (sc-hw_type == IWN_HW_REV_TYPE_6050) ? 20 : 30;
 
memset(cmd, 0, sizeof cmd);
-   cmd.code = IWN5000_PHY_CALIB_NOISE_GAIN;
+   cmd.code = sc-noise_gain;
cmd.ngroups = 1;
cmd.isvalid = 1;
/* Get first available RX antenna as referential. */
@@ -4161,28 +4180,51 @@ iwn_send_advanced_btcoex(struct iwn_soft

Re: Add Intel Centrino Wireless-N 2230 support in iwn(4)

2014-02-09 Thread Benoit Lecocq

On 02/09/14 21:32, Mark Kettenis wrote:
 Date: Sun, 9 Feb 2014 14:23:18 +0100
 From: Fabian Raetz fabian.ra...@gmail.com

 Hmm, my cleanup was based on the version you send out on December
 31st.  Can you send me the latest version of your diff?


 On Tue, Jan 07, 2014 at 12:08:02PM +0100, Martin Pieuchot wrote:
 On 03/01/14(Fri) 14:24, Fabian Raetz wrote:
 Hi tech@,

 here is an updated patch.

 it seems like Intel Centrino Wireless-N 2030 and
 Intel Centrino Wireless-N 2230 have the same pciids...

 this makes patch apply again with newest pcidevs changes.

 Please also make sure to use tab and not space when appropriate ;)  You
 can check style(9) if in doubt !

 ups :)
 attached is a diff
 - which follows style(9) (hopefully) and
 - fixes a firmware error by handling IWN_FW_TLV_ENH_SENS and
   IWN_FW_TLV_PHY_CALIB in iwn_read_firmware_tlv().

 @mike, only style changes since the last patch i send you.
 
 Thanks.  I incorporated the changes in my cleaned up version.
 
 The change does affect other hardware types now, but I've tested this
 on a couple of systems:
 
 iwn0 at pci3 dev 0 function 0 Intel WiFi Link 5300 rev 0x00: msi, MIMO 
 3T3R, MoW
 
 iwn0 at pci3 dev 0 function 0 Intel Centrino Ultimate-N 6300 rev 0x35: msi, 
 MIMO 3T3R, MoW
 
 iwn0 at pci2 dev 0 function 0 Intel Centrino Advanced-N 6205 rev 0x34: msi, 
 MIMO 2T2R, MoW
 
 So if this one works for you and Benoit, I'll go ahead and commit this.
 

ok for me, works fine !

 
 Index: if_iwn.c
 ===
 RCS file: /cvs/src/sys/dev/pci/if_iwn.c,v
 retrieving revision 1.127
 diff -u -p -r1.127 if_iwn.c
 --- if_iwn.c  6 Dec 2013 21:03:04 -   1.127
 +++ if_iwn.c  9 Feb 2014 20:25:41 -
 @@ -94,6 +94,8 @@ static const struct pci_matchid iwn_devi
   { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_WL_130_2 },
   { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_WL_6235_1 },
   { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_WL_6235_2 },
 + { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_WL_2030_1 },
 + { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_WL_2030_2 },
  };
  
  int  iwn_match(struct device *, void *, void *);
 @@ -243,7 +245,8 @@ int   iwn5000_query_calibration(struct iw
  int  iwn5000_send_calibration(struct iwn_softc *);
  int  iwn5000_send_wimax_coex(struct iwn_softc *);
  int  iwn5000_crystal_calib(struct iwn_softc *);
 -int  iwn5000_temp_offset_calib(struct iwn_softc *);
 +int  iwn6000_temp_offset_calib(struct iwn_softc *);
 +int  iwn2000_temp_offset_calib(struct iwn_softc *);
  int  iwn4965_post_alive(struct iwn_softc *);
  int  iwn5000_post_alive(struct iwn_softc *);
  int  iwn4965_load_bootcode(struct iwn_softc *, const uint8_t *,
 @@ -651,6 +654,11 @@ iwn5000_attach(struct iwn_softc *sc, pci
   } else
   sc-fwname = iwn-6005;
   break;
 + case IWN_HW_REV_TYPE_2030:
 + sc-limits = iwn2000_sensitivity_limits;
 + sc-fwname = iwn-2030;
 + sc-sc_flags |= IWN_FLAG_ADV_BT_COEX;
 + break;
   default:
   printf(: adapter type %d not supported\n, sc-hw_type);
   return ENOTSUP;
 @@ -1529,6 +1537,14 @@ iwn5000_read_eeprom(struct iwn_softc *sc
   hdr.version, hdr.pa_type, letoh16(hdr.volt)));
   sc-calib_ver = hdr.version;
  
 + if (sc-hw_type == IWN_HW_REV_TYPE_2030) {
 + sc-eeprom_voltage = letoh16(hdr.volt);
 + iwn_read_prom_data(sc, base + IWN5000_EEPROM_TEMP, val, 2);
 + sc-eeprom_temp = letoh16(val);
 + iwn_read_prom_data(sc, base + IWN2000_EEPROM_RAWTEMP, val, 2);
 + sc-eeprom_rawtemp = letoh16(val);
 + }
 +
   if (sc-hw_type == IWN_HW_REV_TYPE_5150) {
   /* Compute temperature offset. */
   iwn_read_prom_data(sc, base + IWN5000_EEPROM_TEMP, val, 2);
 @@ -2095,7 +2111,8 @@ iwn5000_rx_calib_results(struct iwn_soft
  
   switch (calib-code) {
   case IWN5000_PHY_CALIB_DC:
 - if (sc-hw_type == IWN_HW_REV_TYPE_5150)
 + if (sc-hw_type == IWN_HW_REV_TYPE_5150 ||
 + sc-hw_type == IWN_HW_REV_TYPE_2030)
   idx = 0;
   break;
   case IWN5000_PHY_CALIB_LO:
 @@ -3822,7 +3839,7 @@ iwn5000_init_gains(struct iwn_softc *sc)
   struct iwn_phy_calib cmd;
  
   memset(cmd, 0, sizeof cmd);
 - cmd.code = IWN5000_PHY_CALIB_RESET_NOISE_GAIN;
 + cmd.code = sc-reset_noise_gain;
   cmd.ngroups = 1;
   cmd.isvalid = 1;
   DPRINTF((setting initial differential gains\n));
 @@ -3872,7 +3889,7 @@ iwn5000_set_gains(struct iwn_softc *sc)
   div = (sc-hw_type == IWN_HW_REV_TYPE_6050) ? 20 : 30;
  
   memset(cmd, 0, sizeof cmd);
 - cmd.code = IWN5000_PHY_CALIB_NOISE_GAIN;
 + cmd.code = sc-noise_gain;
   cmd.ngroups = 1;
   cmd.isvalid = 1;
   /* Get first available RX antenna

Re: Add Intel Centrino Wireless-N 2230 support in iwn(4)

2014-02-09 Thread Fabian Raetz

On Sun, Feb 09, 2014 at 09:32:15PM +0100, Mark Kettenis wrote:
  Date: Sun, 9 Feb 2014 14:23:18 +0100
  From: Fabian Raetz fabian.ra...@gmail.com

   Hmm, my cleanup was based on the version you send out on December
   31st.  Can you send me the latest version of your diff?

  On Tue, Jan 07, 2014 at 12:08:02PM +0100, Martin Pieuchot wrote:
   On 03/01/14(Fri) 14:24, Fabian Raetz wrote:
Hi tech@,

here is an updated patch.

it seems like Intel Centrino Wireless-N 2030 and
Intel Centrino Wireless-N 2230 have the same pciids...

this makes patch apply again with newest pcidevs changes.

   Please also make sure to use tab and not space when appropriate ;)  You
   can check style(9) if in doubt !

  ups :)
  attached is a diff
  - which follows style(9) (hopefully) and
  - fixes a firmware error by handling IWN_FW_TLV_ENH_SENS and
IWN_FW_TLV_PHY_CALIB in iwn_read_firmware_tlv().

  @mike, only style changes since the last patch i send you.

 Thanks.  I incorporated the changes in my cleaned up version.

 The change does affect other hardware types now, but I've tested this
 on a couple of systems:

 iwn0 at pci3 dev 0 function 0 Intel WiFi Link 5300 rev 0x00: msi, MIMO 
 3T3R, MoW

 iwn0 at pci3 dev 0 function 0 Intel Centrino Ultimate-N 6300 rev 0x35: msi, 
 MIMO 3T3R, MoW

 iwn0 at pci2 dev 0 function 0 Intel Centrino Advanced-N 6205 rev 0x34: msi, 
 MIMO 2T2R, MoW

 So if this one works for you and Benoit, I'll go ahead and commit this.

works for me too. Thanks!

iwn0 at pci2 dev 0 function 0 Intel Centrino Wireless-N 2030 rev 0xc4: msi, 
MIMO 2T2R, BGN

Re: dd status output

2014-02-09 Thread Dmitrij D. Czarkoff

Mark Kettenis said:
 Perhaps we should ask ourselves the question why this gets printed on
 stderr instead of stdout?

FWIW this is how it is defined in POSIX.

-- 
Dmitrij D. Czarkoff

Re: fail to boot snapshot 5.5 on MBPro8,2 - solved, X also working.

2014-02-09 Thread Volker Nowarra

short update / hint:
if for the very first time after the install the system does not boot, go to a 
running system and try to configure the 55 bsd kernel:

config -o bsd.fix -e bsd

and remove the radeondrm module (find and disable are your friends, type help 
at the UKC prompt).
Then boot with boot hd0a:/bsd.fix.

rgds,
Volker

 Von: Volker Nowarra volker.nowa...@me.com
 Betreff: Aw: fail to boot snapshot 5.5 on MBPro8,2 - solved, X also working.
 Datum: 10. Februar 2014 00:07:56 MEZ
 An: tech@openbsd.org
 
 Hi,
 
 Reference: http://marc.info/?l=openbsd-techm=139175497630924w=4
 
 bsd55 does not start per default from snapshots. 
 Thx to Joerg, I could now successfully boot MBPro 8,2 with snapshot 
 (bsd55-beta).
 Main topic is to get the radeondrm firmware, my procedure was this:
 
 I booted bsd55.rd, and installed from http (CDROM not recognized, internal 
 wireless not working, but bge0 works).
 Then get src.tar.gz and sys.tar.gz installed, and cvs up to -current. 
 Also installed ports and xenocara, and updated to -current, as in Building 
 the System from Source (http://openbsd.org/faq/faq5.html).
 
 Then update the radeon firmware as described in following current 
 (http://openbsd.org/faq/current.html).
 I had to use fw_update. To use pkg_add, the environment variable should point 
 to the right direction. 
 
 pkg_add'd icewm and firefox, started X with icewm, all works well.
 
 DMESG:
 OpenBSD 5.5-beta (GENERIC) #243: Wed Feb  5 14:48:36 MST 2014
t...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC
 RTC BIOS diagnostic error 
 ffclock_battery,ROM_cksum,config_unit,memory_size,fixed_disk,invalid_time
 real mem = 4185079808 (3991MB)
 avail mem = 4065501184 (3877MB)
 mainbus0 at root
 ...

Re: Add Intel Centrino Wireless-N 2230 support in iwn(4)

dd status output

Re: dd status output

Re: Add Intel Centrino Wireless-N 2230 support in iwn(4)

Re: dd status output

churn in pkg_add code

Re: churn in pkg_add code

Re: dd status output

Re: dd status output

Re: Add Intel Centrino Wireless-N 2230 support in iwn(4)

Re: Add Intel Centrino Wireless-N 2230 support in iwn(4)

Re: Add Intel Centrino Wireless-N 2230 support in iwn(4)

Re: churn in pkg_add code

Re: churn in pkg_add code

Re: Add Intel Centrino Wireless-N 2230 support in iwn(4)

Re: Add Intel Centrino Wireless-N 2230 support in iwn(4)

Re: Add Intel Centrino Wireless-N 2230 support in iwn(4)

Re: dd status output

Re: fail to boot snapshot 5.5 on MBPro8,2 - solved, X also working.

19 matches

Site Navigation

Mail list logo

Footer information