Re: load additional armv7 memory space into uvm

2015-05-10 Thread Jonathan Gray
On Thu, Jan 15, 2015 at 12:56:07PM +1100, Jonathan Gray wrote:
 The following Bitrig commit seems to be required for
 the Compulab Utilite and doesn't cause any problems on bbb.
 
 commit 6ea8cdd3daffb2edde3eadf87d3fea6d2f47384c   
   
 Author: Patrick Wildt patr...@blueri.se 
   
 Date:   Sat Dec 7 15:04:09 2013 +0100 
   
   
   
 Load additional memory space into UVM.
   
   
   
 Also bump the amount of 'space' to 2.  More space has not 
   
 been observed yet.
   
   
   
 ok drahn@

Dealing with the novena overflow reminded me of this diff so here is an
updated version with an overflow check that limits the amount of
segments loaded to VM_PHYSSEG_MAX.

Going by dmesg output the utilite u-boot reports two 1GB regions of
physical memory.

Index: armv7/armv7_machdep.c
===
RCS file: /cvs/src/sys/arch/armv7/armv7/armv7_machdep.c,v
retrieving revision 1.20
diff -u -p -r1.20 armv7_machdep.c
--- armv7/armv7_machdep.c   10 May 2015 15:56:28 -  1.20
+++ armv7/armv7_machdep.c   11 May 2015 03:52:12 -
@@ -383,8 +383,7 @@ copy_io_area_map(pd_entry_t *new_pd)
 u_int
 initarm(void *arg0, void *arg1, void *arg2)
 {
-   int loop;
-   int loop1;
+   int loop, loop1, i, physsegs;
u_int l1pagetable;
pv_addr_t kernel_l1pt;
paddr_t memstart;
@@ -722,6 +721,17 @@ initarm(void *arg0, void *arg1, void *ar
uvm_setpagesize();/* initialize PAGE_SIZE-dependent variables */
uvm_page_physload(atop(physical_freestart), atop(physical_freeend),
atop(physical_freestart), atop(physical_freeend), 0);
+
+   physsegs = MIN(bootconfig.dramblocks, VM_PHYSSEG_MAX);
+
+   for (i = 1; i  physsegs; i++) {
+   vaddr_t dramstart = bootconfig.dram[i].address;
+   vaddr_t dramend =  MIN((uint64_t)dramstart +
+   bootconfig.dram[i].pages * PAGE_SIZE, (paddr_t)-PAGE_SIZE);
+   physmem += (dramend - dramstart) / PAGE_SIZE;
+   uvm_page_physload(atop(dramstart), atop(dramend),
+   atop(dramstart), atop(dramend), 0);
+   }
 
/* Boot strap pmap telling it where the kernel page table is */
 #ifdef VERBOSE_INIT_ARM
Index: include/vmparam.h
===
RCS file: /cvs/src/sys/arch/armv7/include/vmparam.h,v
retrieving revision 1.2
diff -u -p -r1.2 vmparam.h
--- include/vmparam.h   10 May 2015 15:56:28 -  1.2
+++ include/vmparam.h   11 May 2015 03:52:13 -
@@ -77,7 +77,7 @@
  * max number of non-contig chunks of physical RAM you can have
  */
 
-#defineVM_PHYSSEG_MAX  1
+#defineVM_PHYSSEG_MAX  2
 #defineVM_PHYSSEG_STRATVM_PSTRAT_RANDOM
 
 /*



luarexlib patch

2015-05-10 Thread Mark Kettenis
[ Sending this to tech@ since I don't just want the ports people to
  know about this ]

Invoking the linker directly to build executables or shared libraries
is strongly discouraged.  It really doesn't work properly unless you
also link in the appropriate /usr/lib/crt*.o files.  We rely on code
in these files for:

 * The private stack protector cookie.

 * For atexit(3) to work in shared libraries that can be dlclose()ed.

 * For pthread_atfork(3) to work in shared libraries that can be dlclose()ed.

With binutils 2.15 linking will succeed, but you might see random
crashes if executable and shared libraries happen to be loaded more
than 2G apart from eachother.  With binutils 2.17 you'll see the
R_X86_64_PC32 relocation failure, and linking will fail.

In general, you should just invoke cc(1) instead of ld(1), since it
will take care of all the magic.

Diff below fixes things for devel/luarexlib.

ok?


Index: patches/patch-src_common_mak
===
RCS file: /cvs/ports/devel/luarexlib/patches/patch-src_common_mak,v
retrieving revision 1.1
diff -u -p -r1.1 patch-src_common_mak
--- patches/patch-src_common_mak9 Sep 2009 18:02:01 -   1.1
+++ patches/patch-src_common_mak10 May 2015 20:05:23 -
@@ -1,6 +1,6 @@
 $OpenBSD: patch-src_common_mak,v 1.1 2009/09/09 18:02:01 jolan Exp $
 --- src/common.mak.origSat Jun 14 20:11:08 2008
-+++ src/common.mak Wed Sep  9 12:13:00 2009
 src/common.mak Sun May 10 22:02:08 2015
 @@ -3,11 +3,11 @@
  V = 2.4
  
@@ -9,8 +9,9 @@ $OpenBSD: patch-src_common_mak,v 1.1 200
 +CFLAGS+= $(MYCFLAGS) $(DEFS) $(INC)
  TRG_AR = lib$(TRG).a
  TRG_SO = $(TRG).so
- LD = ld
+-LD = ld
 -LDFLAGS= -shared
++LD = cc
 +LDFLAGS= -fPIC -shared
  
  all: $(TRG_AR) $(TRG_SO)



Re: OpenBSD on Kosagi Novena open-source ARM board/desktop/laptop

2015-05-10 Thread Jonathan Gray
On Mon, May 11, 2015 at 12:44:14PM +1000, Damien Miller wrote:
 Hi,
 
 Thanks to jsg@, the latest snapshot releases of
 OpenBSD will boot on the Novenai open-source laptop
 (http://www.kosagi.com/w/index.php?title=Novena_Main_Page). It's still
 very rough: no SMP, flaky USB and support for the eeprom (so no MAC
 addr on the IMX ethernet), but it gets to multi-user and could probably
 compile its own kernel given the chance.

The commited VM_MAX_KERNEL_ADDRESS fix includes a page more memory
than what's in the snap, it would be nice to confirm that
the committed version works as well.

The eeprom is hooked up via i2c and will need imxiic in novena_devs[]
and likely some additional imxiic changes from Patrick.

Getting at the atheros wlan/mini pcie slot would need something along
the lines of Patrick's imxpcibr work.

Audio looks to need a new driver for the ES8328 hooked up to imx via
gpio/i2c?

Then there is all the rest of the io devices not to mention lvds...

 
 http://pastebin.com/raw.php?i=dr2qZSi2 is a boot log
 
 To try it out, the easiest way is to setup a tftp server and configure
 DHCP to tell Novena about it. Then boot/reset with the user button held
 down, ^C when prompted (be quick, you only have a couple of seconds) and
 issue the following u-boot commands:
 
 setenv machid 10ad
 setenv loadaddr 0x1080
 dhcp
 bootm
 
 Note that u-boot doesn't seem to fully reset the ethernet
 controller/MAC. If you experience partial transfers that abort due to
 timeouts during the 'dhcp' command then a workaround is to completely
 remove power from Novena and try again after a minute or three.
 
 If you can get an installation completed (the imxenet is pretty flaky,
 possibly because of an all-0 MAC address), then you'll also need to
 copy bsd*.IMX.umg to the /boot partition of the sdcard under Linux
 (OpenBSD can't access the sdcard yet) and arrange uboot to fatload
 it from there. Something like:

There are two sd slots which one doesn't work?

The (internal?) micro-sd slot doesn't have card detect
the (external?) normal sized sd slot does

 
 setenv machid 10ad
 setenv loadaddr 0x1080
 fatload mmc 0 0x1080 bsd.IMG.umg
 bootm
 
 I baked these sequences into u-boot by following the instructions at
 http://www.kosagi.com/w/index.php?title=U-boot_PVT_Notes and
 modifying include/configs/novena.h with the additional commands,
 but it's also probably possible to put them in the /boot/uEnv.txt file
 that uboot reads at startup.

Compiling u-boot is painful, I tried to do it natively on bbb but
gave up as it seems to expect linux headers.  Just modifiying
uEnv.txt is much easier.



GSoC project: KMS driver for Cirrus Logic graphics

2015-05-10 Thread Léo Grange
Hi @tech,

I don't want to spam on this mailing list, but it seems interesting to
share with the other developers about the content of my project for
OpenBSD during the current GSoC. Just to present myself briefly, I'm
student in first year of Master in computer science, in Toulouse,
France.

The goal of the project is to port the current Cirrus userland driver
from X.Org to an OpenBSD KMS driver, and to document the process in
order to make easier the addition of new KMS drivers for various
graphics adapter.
As QEMU emulates a Cirrus CLGD 5446, this card is virtually one of the
easiest to find for testing purpose, is relatively well documented,
and is simple compared to latest intel or radeon cards. For these
reasons it's a pretty good candidate to be used as a sample
implementation of DRM/KMS.

The original proposal contains other informations, mainly
non-technical, but if you want to read it I made it available at this
address:
http://lab.knightsofnii.com/kristaba/gsocproposal/blob/master/README.md

Feel free to contact me if you have any question or advice concerning
my work (or any other reason).


Regards,

Léo Grange



Re: prevent short transfer in nvramread()

2015-05-10 Thread Philip Guenther
On Thu, Apr 9, 2015 at 11:20 AM, Martin Natano nat...@natano.net wrote:
 Below another min() - ulmin() conversion to prevent integer overflow.
 The size (tmp - buf) passed to uiomovei() is essentially bound by the
 'count' variable, thus convert to uiomove().

Committed, with an additional format string fix; thanks!



Re: [ping] dump -U by default

2015-05-10 Thread Philip Guenther
On Wed, May 6, 2015 at 4:47 AM, Manuel Giraud man...@ledu-giraud.fr wrote:
 Minor fix: lastdump was not the only one using fstabsearch.

That fills in the filesystem name for DUID entries, but it's still
reporting both the device and DUID forms:

: morgaine; obj/dump -W
Last dump(s) done (Dump '' file systems):
  /dev/rsd0f(  /usr) Last dump: Level 0, Date Thu Mar 13 10:29
 /dev/rsd0i(/usr/src) Last dump: Level 0, Date Wed Apr  8 11:14
 /dev/rsd0k( /home) Last dump: Level 4, Date Wed Mar 25 00:33
 a7df1ec64e79a49c.i(/usr/src) Last dump: Level 2, Date Wed Apr 15 09:56
 a7df1ec64e79a49c.k( /home) Last dump: Level 6, Date Sat May  2 18:32
: morgaine;

Can we suppress the device form if there's a matching DUID entry?


Philip Guenther



Re: small ed diff

2015-05-10 Thread Philip Guenther
On Wed, Apr 29, 2015 at 3:24 PM, David CARLIER devne...@gmail.com wrote:
 There it is a tiny diff about ed ...

 1/ using a long long (for 32 bits case) for strtol.

Since strtol() returns a long, how can this have any effect?


 2/ realloc = reallocarray

 Hope it has any use

The point of reallocarray() is that it checks the multiple for
overflow; since sizeof(char) == 1, that check can never fail.  If the
concern is overflow of 'ti', the check needs to be done locally,
before the addition.  As for freeing 'b' on failure, doing so without
resetting 'n' to zero will result in a NULL dereference the next time
the involved function is hit.

Sorry, but this seems all wrong...


Philip Guenther



Re: prevent short transfer in lptwrite()

2015-05-10 Thread Philip Guenther
On Thu, Apr 9, 2015 at 11:10 AM, Martin Natano nat...@natano.net wrote:
 uio_resid may overflow when coerced to u_int, causing lptwrite() to
 return early. Also, uiomovei() can be replaced with uiomove(), the size
 argument is of type size_t anyway.

Committed as well.



OpenBSD on Kosagi Novena open-source ARM board/desktop/laptop

2015-05-10 Thread Damien Miller
Hi,

Thanks to jsg@, the latest snapshot releases of
OpenBSD will boot on the Novenai open-source laptop
(http://www.kosagi.com/w/index.php?title=Novena_Main_Page). It's still
very rough: no SMP, flaky USB and support for the eeprom (so no MAC
addr on the IMX ethernet), but it gets to multi-user and could probably
compile its own kernel given the chance.

http://pastebin.com/raw.php?i=dr2qZSi2 is a boot log

To try it out, the easiest way is to setup a tftp server and configure
DHCP to tell Novena about it. Then boot/reset with the user button held
down, ^C when prompted (be quick, you only have a couple of seconds) and
issue the following u-boot commands:

setenv machid 10ad
setenv loadaddr 0x1080
dhcp
bootm

Note that u-boot doesn't seem to fully reset the ethernet
controller/MAC. If you experience partial transfers that abort due to
timeouts during the 'dhcp' command then a workaround is to completely
remove power from Novena and try again after a minute or three.

If you can get an installation completed (the imxenet is pretty flaky,
possibly because of an all-0 MAC address), then you'll also need to
copy bsd*.IMX.umg to the /boot partition of the sdcard under Linux
(OpenBSD can't access the sdcard yet) and arrange uboot to fatload
it from there. Something like:

setenv machid 10ad
setenv loadaddr 0x1080
fatload mmc 0 0x1080 bsd.IMG.umg
bootm

I baked these sequences into u-boot by following the instructions at
http://www.kosagi.com/w/index.php?title=U-boot_PVT_Notes and
modifying include/configs/novena.h with the additional commands,
but it's also probably possible to put them in the /boot/uEnv.txt file
that uboot reads at startup.

-d



Re: GSoC project: KMS driver for Cirrus Logic graphics

2015-05-10 Thread Damien Miller
On Mon, 11 May 2015, L?o Grange wrote:

 The goal of the project is to port the current Cirrus userland driver
 from X.Org to an OpenBSD KMS driver, and to document the process in
 order to make easier the addition of new KMS drivers for various
 graphics adapter.
 As QEMU emulates a Cirrus CLGD 5446, this card is virtually one of the
 easiest to find for testing purpose, is relatively well documented,
 and is simple compared to latest intel or radeon cards. For these
 reasons it's a pretty good candidate to be used as a sample
 implementation of DRM/KMS.

Hi and welcome!

Possibly dumb question: why the Cirrus CLGD 5446? It doesn't seem like
a very common chipset.

Is the goal of the project to have a model KMS driver and
documentation that can serve as a guide? Or a KMS driver that works well
in a common virtualisation environment? or something else?

-d



Re: process stuck in a sched_yield() loop

2015-05-10 Thread David Coppa
On Sat, 09 May 2015, Philip Guenther wrote:

 Looks like the problem is that while one thread is calling vfork(), 
 another thread does something that acquires the spinlock inside 
 rthread_dl_lock() (probably another vfork).  The child of the vfork tries 
 to acquire the spinlock so that it can release the recursive lock itself 
 and spins forever.  The solution is to have the child reset that lock.  
 I'm unable to reproduce after applying the diff below.
 
 oks?
 

With your diff applied, the test suite from latest libinotify-kqueue's
git snapshot (which was even more prone to hangs than libinotify-20141104
currently in our ports tree) also runs w/o problems.

Thanks a lot Philip!
David

 Index: rthread.c
 ===
 RCS file: /data/src/openbsd/src/lib/librthread/rthread.c,v
 retrieving revision 1.81
 diff -u -p -r1.81 rthread.c
 --- rthread.c 29 Apr 2015 06:01:37 -  1.81
 +++ rthread.c 9 May 2015 23:22:25 -
 @@ -671,8 +671,7 @@ _rthread_dl_lock(int what)
   static struct pthread_queue lockers = TAILQ_HEAD_INITIALIZER(lockers);
   static int count = 0;
  
 - if (what == 0)
 - {
 + if (what == 0) {
   pthread_t self = pthread_self();
  
   /* lock, possibly recursive */
 @@ -689,9 +688,7 @@ _rthread_dl_lock(int what)
   }
   count++;
   _spinunlock(lock);
 - }
 - else
 - {
 + } else if (what == 1) {
   /* unlock, possibly recursive */
   if (--count == 0) {
   pthread_t next;
 @@ -704,6 +701,12 @@ _rthread_dl_lock(int what)
   if (next != NULL)
   __thrwakeup(next, 1);
   }
 + } else {
 + /* reinit: used in child after fork to clear the queue */
 + lock = _SPINLOCK_UNLOCKED_ASSIGN;
 + if (--count == 0)
 + owner = NULL;
 + TAILQ_INIT(lockers);
   }
  }
  
 Index: rthread_fork.c
 ===
 RCS file: /data/src/openbsd/src/lib/librthread/rthread_fork.c,v
 retrieving revision 1.11
 diff -u -p -r1.11 rthread_fork.c
 --- rthread_fork.c7 Apr 2015 01:27:07 -   1.11
 +++ rthread_fork.c9 May 2015 23:12:01 -
 @@ -105,12 +105,12 @@ _dofork(int is_vfork)
   _thread_malloc_unlock();
   _thread_atexit_unlock();
  
 + if (newid == 0) {
  #if defined(__ELF__)
 - if (_DYNAMIC)
 - _rthread_dl_lock(1);
 + /* reinitialize the lock in the child */
 + if (_DYNAMIC)
 + _rthread_dl_lock(2);
  #endif
 -
 - if (newid == 0) {
   /* update this thread's structure */
   me-tid = getthrid();
   me-donesem.lock = _SPINLOCK_UNLOCKED_ASSIGN;
 @@ -128,6 +128,10 @@ _dofork(int is_vfork)
   /* single threaded now */
   __isthreaded = 0;
   }
 +#if defined(__ELF__)
 + else if (_DYNAMIC)
 + _rthread_dl_lock(1);
 +#endif
   return newid;
  }
  



Re: process stuck in a sched_yield() loop

2015-05-10 Thread Mark Kettenis
 Date: Sat, 9 May 2015 16:31:25 -0700
 From: Philip Guenther pguent...@proofpoint.com
 
 On Thu, 7 May 2015, David Coppa wrote:
  Can somebody with the necessary skills help me with this?
  
  $ cd /usr/ports/devel/libinotify/  make clean fake  make test 
  
  I remember this used to work... Now, most of the times, the
  'check_libinotify' process brings the CPU to 100% and it's stuck
  in a sched_yield() loop:
 
 Looks like the problem is that while one thread is calling vfork(), 
 another thread does something that acquires the spinlock inside 
 rthread_dl_lock() (probably another vfork).  The child of the vfork tries 
 to acquire the spinlock so that it can release the recursive lock itself 
 and spins forever.  The solution is to have the child reset that lock.  
 I'm unable to reproduce after applying the diff below.
 
 oks?

ok kettenis@



Re: opensmtpd + acceptable mail

2015-05-10 Thread Gilles Chehade
On Fri, May 08, 2015 at 01:48:38PM -0600, Todd C. Miller wrote:
 On Fri, 08 May 2015 12:12:46 +0200, Gilles Chehade wrote:
 
  Now the problem is that if the .forward references a |/path it forks
  a mda (which prepends From), and if mda is sendmail then... it ends up
  calling mail.local which prepends From again.
  
  I think the proper fix is to reconsider the prepend in the mda case.
  If procmail requires custom config, so be it.
 
 I think you always need the From for pipes in .forward since that
 is what sendmail has always done.  It looks like real sendmail will
 strip off a Unix-style From line but smtpctl invoked as sendmail
 does not.
 

Indeed, and this would also be the simplest fix for me.
I'll have a look at what others do tomorrow.

-- 
Gilles Chehade

https://www.poolp.org  @poolpOrg



Re: [patch] rtl8188eu support for urtwn(4)

2015-05-10 Thread Stefan Sperling
On Tue, May 05, 2015 at 01:25:12PM +0200, Stefan Sperling wrote:
 On Mon, May 04, 2015 at 01:51:28PM +0200, Stefan Sperling wrote:
  On Mon, May 04, 2015 at 01:23:59PM +0200, Stefan Sperling wrote:
   Unfortunately, this patch doesn't still fix the performance problem
   for me. How are you testing performance? I'm using tcpbench(1).
  
  I've committed your patch so we can work on the remaining issues in
  smaller chunks. Thanks a lot for your work so far. It's always great
  to see someone new help us out with wireless.
 
 For the record: The speed issue happens only with an AP in 11b mode
 (the 88E firmware retries every data frame at 5Mbit/s). OFDM (11g) works.

This diff fixes 11b performance on 88EU.
Now getting the same results from tcpbench as with 88CUS.

Test / OKs welcome.

Index: if_urtwn.c
===
RCS file: /cvs/src/sys/dev/usb/if_urtwn.c,v
retrieving revision 1.44
diff -u -p -r1.44 if_urtwn.c
--- if_urtwn.c  4 May 2015 11:46:29 -   1.44
+++ if_urtwn.c  10 May 2015 14:05:54 -
@@ -184,6 +184,10 @@ void   urtwn_read_rom(struct urtwn_softc 
 void   urtwn_r88e_read_rom(struct urtwn_softc *);
 inturtwn_media_change(struct ifnet *);
 inturtwn_ra_init(struct urtwn_softc *);
+inturtwn_r92c_ra_init(struct urtwn_softc *, u_int8_t, u_int32_t,
+   int, uint32_t, int);
+inturtwn_r88e_ra_init(struct urtwn_softc *, u_int8_t, u_int32_t,
+   int, uint32_t, int);
 void   urtwn_tsf_sync_enable(struct urtwn_softc *);
 void   urtwn_set_led(struct urtwn_softc *, int, int);
 void   urtwn_calib_to(void *);
@@ -1083,7 +1087,6 @@ urtwn_ra_init(struct urtwn_softc *sc)
struct ieee80211com *ic = sc-sc_ic;
struct ieee80211_node *ni = ic-ic_bss;
struct ieee80211_rateset *rs = ni-ni_rates;
-   struct r92c_fw_cmd_macid_cfg cmd;
uint32_t rates, basicrates;
uint8_t mode;
int maxrate, maxbasicrate, error, i, j;
@@ -1114,6 +1117,24 @@ urtwn_ra_init(struct urtwn_softc *sc)
DPRINTF((mode=0x%x rates=0x%08x, basicrates=0x%08x\n,
mode, rates, basicrates));
 
+   if (sc-chip  URTWN_CHIP_88E)
+   error = urtwn_r88e_ra_init(sc, mode, rates, maxrate,
+   basicrates, maxbasicrate);
+   else
+   error = urtwn_r92c_ra_init(sc, mode, rates, maxrate,
+   basicrates, maxbasicrate);
+
+   /* Indicate highest supported rate. */
+   ni-ni_txrate = rs-rs_nrates - 1;
+   return (error);
+}
+
+int urtwn_r92c_ra_init(struct urtwn_softc *sc, u_int8_t mode, u_int32_t rates,
+int maxrate, uint32_t basicrates, int maxbasicrate)
+{
+   struct r92c_fw_cmd_macid_cfg cmd;
+   int error;
+
/* Set rates mask for group addressed frames. */
cmd.macid = URTWN_MACID_BC | URTWN_MACID_VALID;
cmd.mask = htole32(mode  28 | basicrates);
@@ -1142,8 +1163,28 @@ urtwn_ra_init(struct urtwn_softc *sc)
urtwn_write_1(sc, R92C_INIDATA_RATE_SEL(URTWN_MACID_BSS),
maxrate);
 
-   /* Indicate highest supported rate. */
-   ni-ni_txrate = rs-rs_nrates - 1;
+   return (0);
+}
+
+int
+urtwn_r88e_ra_init(struct urtwn_softc *sc, u_int8_t mode, u_int32_t rates,
+int maxrate, uint32_t basicrates, int maxbasicrate)
+{
+   u_int32_t reg;
+
+   urtwn_write_1(sc, R92C_INIRTS_RATE_SEL, maxbasicrate);
+
+   reg = urtwn_read_4(sc, R92C_RRSR);
+   reg = RW(reg, R92C_RRSR_RATE_BITMAP, rates);
+   urtwn_write_4(sc, R92C_RRSR, reg);
+
+   /* 
+* Workaround for performance problems with firmware rate adaptation:
+* If the AP only supports 11b rates, disable mixed B/G mode.
+*/
+   if (mode != R92C_RAID_11B  maxrate = 3 /* 11M */)
+   sc-sc_flags |= URTWN_FLAG_FORCE_RAID_11B;
+
return (0);
 }
 
@@ -1312,6 +1353,9 @@ urtwn_newstate_cb(struct urtwn_softc *sc
urtwn_write_4(sc, R92C_EDCA_VI_PARAM, 0x005e4317);
urtwn_write_4(sc, R92C_EDCA_BE_PARAM, 0x00105320);
urtwn_write_4(sc, R92C_EDCA_BK_PARAM, 0xa444);
+
+   /* Disable 11b-only AP workaround (see urtwn_r88e_ra_init). */
+   sc-sc_flags = ~URTWN_FLAG_FORCE_RAID_11B;
}
switch (cmd-state) {
case IEEE80211_S_INIT:
@@ -1417,10 +1461,8 @@ urtwn_newstate_cb(struct urtwn_softc *sc
urtwn_write_1(sc, R92C_T2T_SIFS + 1, 10);
 
/* Intialize rate adaptation. */
-   if (sc-chip  URTWN_CHIP_88E)
-   ni-ni_txrate = ni-ni_rates.rs_nrates-1;
-   else
-   urtwn_ra_init(sc);
+   urtwn_ra_init(sc);
+
/* Turn link LED on. */
urtwn_set_led(sc, URTWN_LED_LINK, 1);
 
@@ -1981,7 +2023,8 @@ urtwn_tx(struct urtwn_softc *sc, struct 
 #endif
if