From pisymbol at gmail.com Wed Jul 2 20:48:28 2008 From: pisymbol at gmail.com (Alexander Sack) Date: Wed Jul 2 20:48:33 2008 Subject: RT2790 Wireless miniCard - ral not working on Eee Box Message-ID: <3c0b01820807021348k5effa9aej799bfc7fdc66214f@mail.gmail.com> Hi Everybody: I cc'ed questions since if this turns out NOT be a driver related issue then hopefully someone can tell me what's going on. I have a Asus Eee Box PC with Intel Atom NS270 1.6Ghz model B202. I've installed FreeBSD 7.0-i386-RELEASE and currently going to try 7.0-i386-STABLE on it. I've done a lot of Googling and Nabbling to no avail! :D! My first issue is the onboard wireless card, PCI id: 1814:0781: RT2790 Wireless 802.11n 1T/2R miniCard, does not work. It looks like its a ral derivative which the driver doesn't recognize (from the driver source as well as man, looks like it doesn't even support this family of chipset). Is there a driver for this chipset? If not, why not? :D! Thanks! -aps From pisymbol at gmail.com Thu Jul 3 19:02:42 2008 From: pisymbol at gmail.com (Alexander Sack) Date: Thu Jul 3 19:02:46 2008 Subject: RT2790 Wireless miniCard - ral not working on Eee Box In-Reply-To: <3c0b01820807030515v438adb7bid337fdf8a2feff07@mail.gmail.com> References: <3c0b01820807021348k5effa9aej799bfc7fdc66214f@mail.gmail.com> <20080702185133.3b423e1f@verizon.net> <3c0b01820807030515v438adb7bid337fdf8a2feff07@mail.gmail.com> Message-ID: <3c0b01820807031202x27d9c6c2j61c574589eec93f8@mail.gmail.com> Moving this to freebsd-drivers since it is NOW definitely a driver issue.... Actually I do see the rt2x00 open source project for Linux which I suppose will support this chipset in time. I had the impression the ral driver was based off OpenBSD (I believe that is mentioned in the man page). I'm wondering if the rt2x00 stack would be beneficial to FreeBSD in order to keep in sync with the development being done. Perhaps I'm not in the know....but I thought I would ask to learn. -aps From pisymbol at gmail.com Thu Jul 3 21:04:34 2008 From: pisymbol at gmail.com (Alexander Sack) Date: Thu Jul 3 21:04:40 2008 Subject: RT2790 Wireless miniCard - ral not working on Eee Box In-Reply-To: <486D383B.7010500@freebsd.org> References: <3c0b01820807021348k5effa9aej799bfc7fdc66214f@mail.gmail.com> <20080702185133.3b423e1f@verizon.net> <3c0b01820807030515v438adb7bid337fdf8a2feff07@mail.gmail.com> <3c0b01820807031202x27d9c6c2j61c574589eec93f8@mail.gmail.com> <486D383B.7010500@freebsd.org> Message-ID: <3c0b01820807031404o5d1ff616k9041e2466183cde9@mail.gmail.com> On Thu, Jul 3, 2008 at 4:36 PM, Sam Leffler wrote: > Alexander Sack wrote: >> >> Moving this to freebsd-drivers since it is NOW definitely a driver >> issue.... >> >> Actually I do see the rt2x00 open source project for Linux which I >> suppose will support this chipset in time. I had the impression the >> ral driver was based off OpenBSD (I believe that is mentioned in the >> man page). >> >> I'm wondering if the rt2x00 stack would be beneficial to FreeBSD in >> order to keep in sync with the development being done. Perhaps I'm >> not in the know....but I thought I would ask to learn. >> > > If this is an 11n part then it's likely based on a 2860 part and there > currently is no driver for freebsd. I have a partly finished driver for > HEAD but no time. Also the info we received from ralink is incomplete and > they don't answer queries. Sam, thanks for the heads up. Yes it is, its a 11n minicard. Btw, I'm a happy user of I believe some of the ath work you've done in the past so thanks! :D! May I ask how far along are you? And if this is something you can hand over to someone else to finish? I was going to ask ralink for a spec sheet in an attempt to see if something could be done. I *thought* they were open source friendly? Btw, about my other point, so does FreeBSD have a separate ralink stack from the rt2x00 project? (I haven't peeked at the source yet, I was hoping perhaps it had support for the card and could be ported over, etc.). -aps From sam at freebsd.org Thu Jul 3 21:12:01 2008 From: sam at freebsd.org (Sam Leffler) Date: Thu Jul 3 21:12:05 2008 Subject: RT2790 Wireless miniCard - ral not working on Eee Box In-Reply-To: <3c0b01820807031202x27d9c6c2j61c574589eec93f8@mail.gmail.com> References: <3c0b01820807021348k5effa9aej799bfc7fdc66214f@mail.gmail.com> <20080702185133.3b423e1f@verizon.net> <3c0b01820807030515v438adb7bid337fdf8a2feff07@mail.gmail.com> <3c0b01820807031202x27d9c6c2j61c574589eec93f8@mail.gmail.com> Message-ID: <486D383B.7010500@freebsd.org> Alexander Sack wrote: > Moving this to freebsd-drivers since it is NOW definitely a driver issue.... > > Actually I do see the rt2x00 open source project for Linux which I > suppose will support this chipset in time. I had the impression the > ral driver was based off OpenBSD (I believe that is mentioned in the > man page). > > I'm wondering if the rt2x00 stack would be beneficial to FreeBSD in > order to keep in sync with the development being done. Perhaps I'm > not in the know....but I thought I would ask to learn. > If this is an 11n part then it's likely based on a 2860 part and there currently is no driver for freebsd. I have a partly finished driver for HEAD but no time. Also the info we received from ralink is incomplete and they don't answer queries. Sam From sam at freebsd.org Thu Jul 3 21:19:36 2008 From: sam at freebsd.org (Sam Leffler) Date: Thu Jul 3 21:19:39 2008 Subject: RT2790 Wireless miniCard - ral not working on Eee Box In-Reply-To: <3c0b01820807031404o5d1ff616k9041e2466183cde9@mail.gmail.com> References: <3c0b01820807021348k5effa9aej799bfc7fdc66214f@mail.gmail.com> <20080702185133.3b423e1f@verizon.net> <3c0b01820807030515v438adb7bid337fdf8a2feff07@mail.gmail.com> <3c0b01820807031202x27d9c6c2j61c574589eec93f8@mail.gmail.com> <486D383B.7010500@freebsd.org> <3c0b01820807031404o5d1ff616k9041e2466183cde9@mail.gmail.com> Message-ID: <486D4266.7040705@freebsd.org> Alexander Sack wrote: > On Thu, Jul 3, 2008 at 4:36 PM, Sam Leffler wrote: > >> Alexander Sack wrote: >> >>> Moving this to freebsd-drivers since it is NOW definitely a driver >>> issue.... >>> >>> Actually I do see the rt2x00 open source project for Linux which I >>> suppose will support this chipset in time. I had the impression the >>> ral driver was based off OpenBSD (I believe that is mentioned in the >>> man page). >>> >>> I'm wondering if the rt2x00 stack would be beneficial to FreeBSD in >>> order to keep in sync with the development being done. Perhaps I'm >>> not in the know....but I thought I would ask to learn. >>> >>> >> If this is an 11n part then it's likely based on a 2860 part and there >> currently is no driver for freebsd. I have a partly finished driver for >> HEAD but no time. Also the info we received from ralink is incomplete and >> they don't answer queries. >> > > Sam, thanks for the heads up. Yes it is, its a 11n minicard. Btw, > I'm a happy user of I believe some of the ath work you've done in the > past so thanks! :D! > "11n" may be misleading here; the 2661 parts are described as MIMO and sometimes marketed as pre-11n but are not capable of 802.11n as currently spec'd. The PCI id you stated previously doesn't match any of the ones I know are 2860-based. > May I ask how far along are you? And if this is something you can > hand over to someone else to finish? I was going to ask ralink for a > spec sheet in an attempt to see if something could be done. I > *thought* they were open source friendly? > I can hand the driver over to someone (I offered it to several developers already). I stopped when I went to add WME support and hit issues w/ apparent DMA alignment requirements. I asked Ralink to clarify the datasheet they provided (which says nothing) but they have not responded to that question or other critical questions we need answers to for 11n and multi-bss support. > Btw, about my other point, so does FreeBSD have a separate ralink > stack from the rt2x00 project? (I haven't peeked at the source yet, I > was hoping perhaps it had support for the card and could be ported > over, etc.). > > We don't need a separate stack; we have a common 802.11 framework that drivers share. This makes our drivers usually 1/4th - 1/10'th the size of other systems. Sam From mirnshi at gmail.com Mon Jul 14 14:56:55 2008 From: mirnshi at gmail.com (mirnshi@gmail.com) Date: Mon Jul 14 14:57:01 2008 Subject: patch for Attansic L2 FastEthernet Message-ID: Recently, I got an eeepc 701. And I installed FreeBSD 7.0 on it . The url http://wiki.freebsd.org/AsusEee gives me a big hand. But, the driver of lan did not work. The problem is that the driver can be loaded by kldload, but the interrupt storm caused the system to stop responding when I use ifconfig to mark the nic 'up'. BTW, I used 10MB hub. The driver uses taskqueue_enqueue. 'ae_intr' reads nic register, but 'ae_int_task' reads it again. So I merge them into the new 'ae_intr'. I test 'ping' and 'ftp', it works well. Please refer to the patch for details. --- if_ae.c 2008-06-27 20:19:43.000000000 +0800 +++ /sys/dev/if_ae/if_ae.c 2008-07-14 21:54:06.000000000 +0800 @@ -1450,20 +1450,56 @@ { ae_softc_t *sc; uint32_t val; + struct ifnet *ifp; + struct mii_data *mii; sc = (ae_softc_t *)arg; + AE_LOCK(sc); KASSERT(sc != NULL, ("[ae, %d]: sc is null", __LINE__)); val = AE_READ_4(sc, AE_ISR_REG); - if (val == 0 || (val & AE_IMR_DEFAULT) == 0) + if (val == 0 || (val & AE_IMR_DEFAULT) == 0) { + AE_UNLOCK(sc); return FILTER_STRAY; + } - /* Disable interrupts. */ - AE_WRITE_4(sc, AE_ISR_REG, AE_ISR_DISABLE); + /* Clear interrupts and disable them. */ + AE_WRITE_4(sc, AE_ISR_REG, val | AE_ISR_DISABLE); - /* Schedule interrupt processing. */ - taskqueue_enqueue(sc->tq, &sc->int_task); + ifp = sc->ifp; + if ((val & AE_ISR_PHY) != 0) { + /* + * Clear PHY interrupt. Not sure if it needed. From Linux. + */ + ae_miibus_readreg(sc->miibus, 1, 19); + } + +#ifdef AE_DEBUG + if_printf(ifp, "Interrupt received: 0x%08x\n", val); +#endif + + if ((val & (AE_ISR_PHY | AE_ISR_MANUAL)) != 0) { + mii = device_get_softc(sc->miibus); + mii_mediachg(mii); + } + + if ((val & (AE_ISR_DMAR_TIMEOUT | AE_ISR_DMAW_TIMEOUT | + AE_ISR_PHY_LINKDOWN)) != 0) { + ae_init_locked(sc); + } + if ((ifp->if_drv_flags & IFF_DRV_RUNNING) != 0) { + if ((val & AE_ISR_TX_EVENT) != 0) + ae_tx_intr(sc); + + if ((val & AE_ISR_RX_EVENT) != 0) + ae_rx_intr(sc); + } + + /* Re-enable interrupts. */ + AE_WRITE_4(sc, AE_ISR_REG, 0); + + AE_UNLOCK(sc); return (FILTER_HANDLED); } From pyunyh at gmail.com Tue Jul 15 01:10:36 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Tue Jul 15 01:10:42 2008 Subject: patch for Attansic L2 FastEthernet In-Reply-To: References: Message-ID: <20080715004301.GB40212@cdnetworks.co.kr> On Mon, Jul 14, 2008 at 10:30:36PM +0800, mirnshi@gmail.com wrote: > Recently, I got an eeepc 701. And I installed FreeBSD 7.0 on it . The url > http://wiki.freebsd.org/AsusEee gives me a big hand. But, the driver of lan > did not work. The problem is that the driver can be loaded by kldload, but > the interrupt storm caused the system to stop responding when I use ifconfig > to mark the nic 'up'. BTW, I used 10MB hub. Sound like interrupts are enabled in taskqueue handler. > > The driver uses taskqueue_enqueue. 'ae_intr' reads nic register, but > 'ae_int_task' reads it again. So I merge them into the new 'ae_intr'. > I test 'ping' and 'ftp', it works well. > You can't hold a mutex in fast interrupt handler. Since there is no documentation for L2 controller I'm not sure but ae_int_task() seems to have a code that reenables interrupts which was already disabled in ae_intr(). How about nuking AE_ISR_DISABLE in ae_int_task()? From: /* Clear interrupts and disable them. */ AE_WRITE_4(sc, AE_ISR_REG, val | AE_ISR_DISABLE); To: /* Clear interrupts. */ AE_WRITE_4(sc, AE_ISR_REG, val); CCed to Stanislav Sedov, the author of driver. > Please refer to the patch for details. > > --- if_ae.c 2008-06-27 20:19:43.000000000 +0800 > +++ /sys/dev/if_ae/if_ae.c 2008-07-14 21:54:06.000000000 +0800 > @@ -1450,20 +1450,56 @@ > { > ae_softc_t *sc; > uint32_t val; > + struct ifnet *ifp; > + struct mii_data *mii; > > sc = (ae_softc_t *)arg; > + AE_LOCK(sc); > KASSERT(sc != NULL, ("[ae, %d]: sc is null", __LINE__)); > > val = AE_READ_4(sc, AE_ISR_REG); > - if (val == 0 || (val & AE_IMR_DEFAULT) == 0) > + if (val == 0 || (val & AE_IMR_DEFAULT) == 0) { > + AE_UNLOCK(sc); > return FILTER_STRAY; > + } > > - /* Disable interrupts. */ > - AE_WRITE_4(sc, AE_ISR_REG, AE_ISR_DISABLE); > + /* Clear interrupts and disable them. */ > + AE_WRITE_4(sc, AE_ISR_REG, val | AE_ISR_DISABLE); > > - /* Schedule interrupt processing. */ > - taskqueue_enqueue(sc->tq, &sc->int_task); > + ifp = sc->ifp; > > + if ((val & AE_ISR_PHY) != 0) { > + /* > + * Clear PHY interrupt. Not sure if it needed. From Linux. > + */ > + ae_miibus_readreg(sc->miibus, 1, 19); > + } > + > +#ifdef AE_DEBUG > + if_printf(ifp, "Interrupt received: 0x%08x\n", val); > +#endif > + > + if ((val & (AE_ISR_PHY | AE_ISR_MANUAL)) != 0) { > + mii = device_get_softc(sc->miibus); > + mii_mediachg(mii); > + } > + > + if ((val & (AE_ISR_DMAR_TIMEOUT | AE_ISR_DMAW_TIMEOUT | > + AE_ISR_PHY_LINKDOWN)) != 0) { > + ae_init_locked(sc); > + } > + if ((ifp->if_drv_flags & IFF_DRV_RUNNING) != 0) { > + if ((val & AE_ISR_TX_EVENT) != 0) > + ae_tx_intr(sc); > + > + if ((val & AE_ISR_RX_EVENT) != 0) > + ae_rx_intr(sc); > + } > + > + /* Re-enable interrupts. */ > + AE_WRITE_4(sc, AE_ISR_REG, 0); > + > + AE_UNLOCK(sc); > return (FILTER_HANDLED); > } -- Regards, Pyun YongHyeon From mirnshi at gmail.com Tue Jul 15 02:11:36 2008 From: mirnshi at gmail.com (mirnshi@gmail.com) Date: Tue Jul 15 02:11:42 2008 Subject: patch for Attansic L2 FastEthernet In-Reply-To: <20080715004301.GB40212@cdnetworks.co.kr> References: <20080715004301.GB40212@cdnetworks.co.kr> Message-ID: 2008/7/15 Pyun YongHyeon : > On Mon, Jul 14, 2008 at 10:30:36PM +0800, mirnshi@gmail.com wrote: > > Recently, I got an eeepc 701. And I installed FreeBSD 7.0 on it . The > url > > http://wiki.freebsd.org/AsusEee gives me a big hand. But, the driver of > lan > > did not work. The problem is that the driver can be loaded by kldload, > but > > the interrupt storm caused the system to stop responding when I use > ifconfig > > to mark the nic 'up'. BTW, I used 10MB hub. > > Sound like interrupts are enabled in taskqueue handler. > > > > > The driver uses taskqueue_enqueue. 'ae_intr' reads nic register, but > > 'ae_int_task' reads it again. So I merge them into the new 'ae_intr'. > > I test 'ping' and 'ftp', it works well. > > > > You can't hold a mutex in fast interrupt handler. Do you mean the driver will slow down? Many GB driver use LOCK in their xxx_intr. > Since there is no documentation for L2 controller I'm not sure but > ae_int_task() seems to have a code that reenables interrupts which > was already disabled in ae_intr(). How about nuking AE_ISR_DISABLE > in ae_int_task()? > > From: > /* Clear interrupts and disable them. */ > AE_WRITE_4(sc, AE_ISR_REG, val | AE_ISR_DISABLE); > > To: > /* Clear interrupts. */ > AE_WRITE_4(sc, AE_ISR_REG, val); enable or disable the interrupt? I think this code enable the interrupt, right? Stanislav did not write the status word back, just disable the interrupt. AE_WRITE_4(sc, AE_ISR_REG, AE_ISR_DISABLE); but, the linux does it AT_WRITE_REG(hw, REG_ISR, status|ISR_DIS_INT); In 'ae_int_task', Stanislav read the status word again, like in linux, write back. val = AE_READ_4(sc, AE_ISR_REG); AE_WRITE_4(sc, AE_ISR_REG, val | AE_ISR_DISABLE); Is the status word still there ? > CCed to Stanislav Sedov, the author of driver. > > > Please refer to the patch for details. > > > > --- if_ae.c 2008-06-27 20:19:43.000000000 +0800 > > +++ /sys/dev/if_ae/if_ae.c 2008-07-14 21:54:06.000000000 +0800 > > @@ -1450,20 +1450,56 @@ > > { > > ae_softc_t *sc; > > uint32_t val; > > + struct ifnet *ifp; > > + struct mii_data *mii; > > > > sc = (ae_softc_t *)arg; > > + AE_LOCK(sc); > > KASSERT(sc != NULL, ("[ae, %d]: sc is null", __LINE__)); > > > > val = AE_READ_4(sc, AE_ISR_REG); > > - if (val == 0 || (val & AE_IMR_DEFAULT) == 0) > > + if (val == 0 || (val & AE_IMR_DEFAULT) == 0) { > > + AE_UNLOCK(sc); > > return FILTER_STRAY; > > + } > > > > - /* Disable interrupts. */ > > - AE_WRITE_4(sc, AE_ISR_REG, AE_ISR_DISABLE); > > + /* Clear interrupts and disable them. */ > > + AE_WRITE_4(sc, AE_ISR_REG, val | AE_ISR_DISABLE); > > > > - /* Schedule interrupt processing. */ > > - taskqueue_enqueue(sc->tq, &sc->int_task); > > + ifp = sc->ifp; > > > > + if ((val & AE_ISR_PHY) != 0) { > > + /* > > + * Clear PHY interrupt. Not sure if it needed. From Linux. > > + */ > > + ae_miibus_readreg(sc->miibus, 1, 19); > > + } > > + > > +#ifdef AE_DEBUG > > + if_printf(ifp, "Interrupt received: 0x%08x\n", val); > > +#endif > > + > > + if ((val & (AE_ISR_PHY | AE_ISR_MANUAL)) != 0) { > > + mii = device_get_softc(sc->miibus); > > + mii_mediachg(mii); > > + } > > + > > + if ((val & (AE_ISR_DMAR_TIMEOUT | AE_ISR_DMAW_TIMEOUT | > > + AE_ISR_PHY_LINKDOWN)) != 0) { > > + ae_init_locked(sc); > > + } > > + if ((ifp->if_drv_flags & IFF_DRV_RUNNING) != 0) { > > + if ((val & AE_ISR_TX_EVENT) != 0) > > + ae_tx_intr(sc); > > + > > + if ((val & AE_ISR_RX_EVENT) != 0) > > + ae_rx_intr(sc); > > + } > > + > > + /* Re-enable interrupts. */ > > + AE_WRITE_4(sc, AE_ISR_REG, 0); > > + > > + AE_UNLOCK(sc); > > return (FILTER_HANDLED); > > } > > -- > Regards, > Pyun YongHyeon > From stas at FreeBSD.org Tue Jul 15 23:29:21 2008 From: stas at FreeBSD.org (Stanislav Sedov) Date: Tue Jul 15 23:29:27 2008 Subject: patch for Attansic L2 FastEthernet In-Reply-To: References: <20080715004301.GB40212@cdnetworks.co.kr> Message-ID: <20080716023907.d11f15b2.stas@FreeBSD.org> On Tue, 15 Jul 2008 10:11:23 +0800 mirnshi@gmail.com mentioned: > > Do you mean the driver will slow down? Many GB driver use LOCK in their > xxx_intr. > You just can't hold locks in FILTER isrs. If you need locking, you're definitely not going to use fast interrupt handlers. And I see no good reason not to use them. > > > Since there is no documentation for L2 controller I'm not sure but > > ae_int_task() seems to have a code that reenables interrupts which > > was already disabled in ae_intr(). How about nuking AE_ISR_DISABLE > > in ae_int_task()? > > > > From: > > /* Clear interrupts and disable them. */ > > AE_WRITE_4(sc, AE_ISR_REG, val | AE_ISR_DISABLE); > > > > To: > > /* Clear interrupts. */ > > AE_WRITE_4(sc, AE_ISR_REG, val); > > > enable or disable the interrupt? I think this code enable the interrupt, > right? > > Stanislav did not write the status word back, just disable the interrupt. > AE_WRITE_4(sc, AE_ISR_REG, AE_ISR_DISABLE); > but, the linux does it > AT_WRITE_REG(hw, REG_ISR, status|ISR_DIS_INT); > > In 'ae_int_task', Stanislav read the status word again, like in linux, write > back. > val = AE_READ_4(sc, AE_ISR_REG); > AE_WRITE_4(sc, AE_ISR_REG, val | AE_ISR_DISABLE); > > Is the status word still there ? > That's because I need to pass ISR status word between fast interrupt handler and the actual isr processor. Thus I just disable interrupts in filter, and clear the interrupt status word after processing in ae_int_task. > > > > CCed to Stanislav Sedov, the author of driver. > > > > > Please refer to the patch for details. > > > > > > --- if_ae.c 2008-06-27 20:19:43.000000000 +0800 > > > +++ /sys/dev/if_ae/if_ae.c 2008-07-14 21:54:06.000000000 +0800 > > > @@ -1450,20 +1450,56 @@ > > > { > > > ae_softc_t *sc; > > > uint32_t val; > > > + struct ifnet *ifp; > > > + struct mii_data *mii; > > > > > > sc = (ae_softc_t *)arg; > > > + AE_LOCK(sc); > > > KASSERT(sc != NULL, ("[ae, %d]: sc is null", __LINE__)); > > > > > > val = AE_READ_4(sc, AE_ISR_REG); > > > - if (val == 0 || (val & AE_IMR_DEFAULT) == 0) > > > + if (val == 0 || (val & AE_IMR_DEFAULT) == 0) { > > > + AE_UNLOCK(sc); > > > return FILTER_STRAY; > > > + } > > > > > > - /* Disable interrupts. */ > > > - AE_WRITE_4(sc, AE_ISR_REG, AE_ISR_DISABLE); > > > + /* Clear interrupts and disable them. */ > > > + AE_WRITE_4(sc, AE_ISR_REG, val | AE_ISR_DISABLE); > > > > > > - /* Schedule interrupt processing. */ > > > - taskqueue_enqueue(sc->tq, &sc->int_task); > > > + ifp = sc->ifp; > > > > > > + if ((val & AE_ISR_PHY) != 0) { > > > + /* > > > + * Clear PHY interrupt. Not sure if it needed. From Linux. > > > + */ > > > + ae_miibus_readreg(sc->miibus, 1, 19); > > > + } > > > + > > > +#ifdef AE_DEBUG > > > + if_printf(ifp, "Interrupt received: 0x%08x\n", val); > > > +#endif > > > + > > > + if ((val & (AE_ISR_PHY | AE_ISR_MANUAL)) != 0) { > > > + mii = device_get_softc(sc->miibus); > > > + mii_mediachg(mii); > > > + } > > > + > > > + if ((val & (AE_ISR_DMAR_TIMEOUT | AE_ISR_DMAW_TIMEOUT | > > > + AE_ISR_PHY_LINKDOWN)) != 0) { > > > + ae_init_locked(sc); > > > + } > > > + if ((ifp->if_drv_flags & IFF_DRV_RUNNING) != 0) { > > > + if ((val & AE_ISR_TX_EVENT) != 0) > > > + ae_tx_intr(sc); > > > + > > > + if ((val & AE_ISR_RX_EVENT) != 0) > > > + ae_rx_intr(sc); > > > + } > > > + > > > + /* Re-enable interrupts. */ > > > + AE_WRITE_4(sc, AE_ISR_REG, 0); > > > + > > > + AE_UNLOCK(sc); > > > return (FILTER_HANDLED); > > > } > > I don't see how this can help with your issue. One guy has reported he's able to stably reproduce the bug by booting into FreeBSD just after Linux touches the hardware. This explains why I've never seen that, as I never booted Linux on my box. I think the problem caused by the ukphy driver which just can't handle the F2 phy. I plan to use agephy to handle the Attansic L2 phy also. Please, wait a couple of days - I'll try to reproduce the problem, and incorporate appropriate fixes. Also, as was mentioned in my previous mail, the drives isn't complete now - there're a lot of places that had to be fixed, not speaking of the public version of the driver isn't the latest one. I'm a bit busy now, but I hope I'll roll out the updated version by the end of the week. -- Stanislav Sedov ST4096-RIPE -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-drivers/attachments/20080715/e0662936/attachment.pgp From Satendra.Pratap at citrix.com Wed Jul 16 14:15:39 2008 From: Satendra.Pratap at citrix.com (Satendra Pratap) Date: Wed Jul 16 14:16:02 2008 Subject: Regarding Broadcom driver for Linux tg3.c Message-ID: Can anyone please let me know which code in Broadcom driver informs about the link failure to its Link partner when Broadcom NIC goes into disable (OR error disable) state? Actually I found that code but that code does inform the link partner and immediately comes up again. Any help is appreciated. Thanks, From sbruno at miralink.com Mon Jul 21 18:32:30 2008 From: sbruno at miralink.com (Sean Bruno) Date: Mon Jul 21 18:32:37 2008 Subject: MII compile errors(RELENG_7) Message-ID: <4884D1ED.5060205@miralink.com> Anyone else getting this with GENERIC from this AM? ===> mii (all) cc -O2 -fno-strict-aliasing -pipe -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /usr/home/sbruno/FreeBSD_RELENG_7_15APR08/src/sys/i386/compile/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -I/usr/home/sbruno/FreeBSD_RELENG_7_15APR08/src/sys/i386/compile/GENERIC -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c /usr/home/sbruno/FreeBSD_RELENG_7_15APR08/src/sys/modules/mii/../../dev/mii/jmphy.c cc -O2 -fno-strict-aliasing -pipe -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /usr/home/sbruno/FreeBSD_RELENG_7_15APR08/src/sys/i386/compile/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -I/usr/home/sbruno/FreeBSD_RELENG_7_15APR08/src/sys/i386/compile/GENERIC -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c /usr/home/sbruno/FreeBSD_RELENG_7_15APR08/src/sys/modules/mii/../../dev/mii/truephy.c /usr/home/sbruno/FreeBSD_RELENG_7_15APR08/src/sys/modules/mii/../../dev/mii/truephy.c:78: error: 'MII_OUI_AGERE' undeclared here (not in a function) /usr/home/sbruno/FreeBSD_RELENG_7_15APR08/src/sys/modules/mii/../../dev/mii/truephy.c:78: error: 'MII_MODEL_AGERE_ET1011C' undeclared here (not in a function) /usr/home/sbruno/FreeBSD_RELENG_7_15APR08/src/sys/modules/mii/../../dev/mii/truephy.c:78: error: 'MII_STR_AGERE_ET1011C' undeclared here (not in a function) *** Error code 1 /usr/home/sbruno/FreeBSD_RELENG_7_15APR08/src/sys/modules/mii/../../dev/mii/jmphy.c:88: error: 'MII_OUI_JMICRON' undeclared here (not in a function) /usr/home/sbruno/FreeBSD_RELENG_7_15APR08/src/sys/modules/mii/../../dev/mii/jmphy.c:88: error: 'MII_MODEL_JMICRON_JMP202' undeclared here (not in a function) /usr/home/sbruno/FreeBSD_RELENG_7_15APR08/src/sys/modules/mii/../../dev/mii/jmphy.c:88: error: 'MII_STR_JMICRON_JMP202' undeclared here (not in a function) /usr/home/sbruno/FreeBSD_RELENG_7_15APR08/src/sys/modules/mii/../../dev/mii/jmphy.c:89: error: 'MII_MODEL_JMICRON_JMP211' undeclared here (not in a function) /usr/home/sbruno/FreeBSD_RELENG_7_15APR08/src/sys/modules/mii/../../dev/mii/jmphy.c:89: error: 'MII_STR_JMICRON_JMP211' undeclared here (not in a function) *** Error code 1 2 errors *** Error code 2 1 error *** Error code 2 1 error -- Sean Bruno MiraLink Corporation 6015 NE 80th Ave, Ste 100 Portland, OR 97218 Phone 503-621-5143 Fax 503-621-5199 MSN: sbruno@miralink.com Google: seanwbruno@gmail.com Yahoo: sean_bruno@yahoo.com From sbruno at miralink.com Mon Jul 21 18:33:44 2008 From: sbruno at miralink.com (Sean Bruno) Date: Mon Jul 21 18:33:51 2008 Subject: MII compile errors(RELENG_7) In-Reply-To: <4884D1ED.5060205@miralink.com> References: <4884D1ED.5060205@miralink.com> Message-ID: <4884D686.2040706@miralink.com> Sean Bruno wrote: > Anyone else getting this with GENERIC from this AM? > > > ===> mii (all) > cc -O2 -fno-strict-aliasing -pipe -D_KERNEL -DKLD_MODULE -std=c99 > -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include > /usr/home/sbruno/FreeBSD_RELENG_7_15APR08/src/sys/i386/compile/GENERIC/opt_global.h > -I. -I@ -I@/contrib/altq -finline-limit=8000 --param > inline-unit-growth=100 --param large-function-growth=1000 -fno-common > -g > -I/usr/home/sbruno/FreeBSD_RELENG_7_15APR08/src/sys/i386/compile/GENERIC > -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx > -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Wall > -Wredundant-decls -Wnested-externs -Wstrict-prototypes > -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef > -Wno-pointer-sign -fformat-extensions -c > /usr/home/sbruno/FreeBSD_RELENG_7_15APR08/src/sys/modules/mii/../../dev/mii/jmphy.c > > cc -O2 -fno-strict-aliasing -pipe -D_KERNEL -DKLD_MODULE -std=c99 > -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include > /usr/home/sbruno/FreeBSD_RELENG_7_15APR08/src/sys/i386/compile/GENERIC/opt_global.h > -I. -I@ -I@/contrib/altq -finline-limit=8000 --param > inline-unit-growth=100 --param large-function-growth=1000 -fno-common > -g > -I/usr/home/sbruno/FreeBSD_RELENG_7_15APR08/src/sys/i386/compile/GENERIC > -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx > -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Wall > -Wredundant-decls -Wnested-externs -Wstrict-prototypes > -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef > -Wno-pointer-sign -fformat-extensions -c > /usr/home/sbruno/FreeBSD_RELENG_7_15APR08/src/sys/modules/mii/../../dev/mii/truephy.c > > /usr/home/sbruno/FreeBSD_RELENG_7_15APR08/src/sys/modules/mii/../../dev/mii/truephy.c:78: > error: 'MII_OUI_AGERE' undeclared here (not in a function) > /usr/home/sbruno/FreeBSD_RELENG_7_15APR08/src/sys/modules/mii/../../dev/mii/truephy.c:78: > error: 'MII_MODEL_AGERE_ET1011C' undeclared here (not in a function) > /usr/home/sbruno/FreeBSD_RELENG_7_15APR08/src/sys/modules/mii/../../dev/mii/truephy.c:78: > error: 'MII_STR_AGERE_ET1011C' undeclared here (not in a function) > *** Error code 1 > /usr/home/sbruno/FreeBSD_RELENG_7_15APR08/src/sys/modules/mii/../../dev/mii/jmphy.c:88: > error: 'MII_OUI_JMICRON' undeclared here (not in a function) > /usr/home/sbruno/FreeBSD_RELENG_7_15APR08/src/sys/modules/mii/../../dev/mii/jmphy.c:88: > error: 'MII_MODEL_JMICRON_JMP202' undeclared here (not in a function) > /usr/home/sbruno/FreeBSD_RELENG_7_15APR08/src/sys/modules/mii/../../dev/mii/jmphy.c:88: > error: 'MII_STR_JMICRON_JMP202' undeclared here (not in a function) > /usr/home/sbruno/FreeBSD_RELENG_7_15APR08/src/sys/modules/mii/../../dev/mii/jmphy.c:89: > error: 'MII_MODEL_JMICRON_JMP211' undeclared here (not in a function) > /usr/home/sbruno/FreeBSD_RELENG_7_15APR08/src/sys/modules/mii/../../dev/mii/jmphy.c:89: > error: 'MII_STR_JMICRON_JMP211' undeclared here (not in a function) > *** Error code 1 > 2 errors > *** Error code 2 > 1 error > *** Error code 2 > 1 error > Hmmm....This looks like an artifact of compiling with -j flags. e.g. make -j 2 Excluding that make option, compile fine. -- Sean Bruno MiraLink Corporation 6015 NE 80th Ave, Ste 100 Portland, OR 97218 Phone 503-621-5143 Fax 503-621-5199 MSN: sbruno@miralink.com Google: seanwbruno@gmail.com Yahoo: sean_bruno@yahoo.com From bu7cher at yandex.ru Fri Jul 25 10:12:50 2008 From: bu7cher at yandex.ru (Andrey V. Elsukov) Date: Fri Jul 25 10:12:58 2008 Subject: ATA patch for RELENG_6 ... a patch looking for a good home In-Reply-To: <4889A415.1060309@yandex.ru> References: <4839F473.6070109@miralink.com> <4889A415.1060309@yandex.ru> Message-ID: <4889A712.7090204@yandex.ru> Andrey V. Elsukov wrote: > What you think about attached patch? > It can resolve your problem and shouldn't break anything. > With this patch you can set mode in /boot/device.hints, for > example: > hint.ad.0.mode="UDMA33" > hint.ad.1.mode="UDMA100" > > These limits work only on boot stage, after boot completed you can > change mode via atacontrol. Also, this is the same patch, but it doesn't allow override maximum mode in device.hints. I don't know which patch is preferable, I think second one. -- WBR, Andrey V. Elsukov -------------- next part -------------- Index: src/sys/dev/ata/ata-all.c =================================================================== RCS file: /ncvs/src/sys/dev/ata/ata-all.c,v retrieving revision 1.289 diff -u -b -p -r1.289 ata-all.c --- src/sys/dev/ata/ata-all.c 11 Jun 2008 06:44:58 -0000 1.289 +++ src/sys/dev/ata/ata-all.c 25 Jul 2008 10:06:00 -0000 @@ -889,6 +889,28 @@ ata_mode2str(int mode) } } +static int +ata_str2mode(const char *str) +{ + if (!strncasecmp(str, "BIOSPIO", 7)) return ATA_PIO; + if (!strncasecmp(str, "PIO0", 4)) return ATA_PIO0; + if (!strncasecmp(str, "PIO1", 4)) return ATA_PIO1; + if (!strncasecmp(str, "PIO2", 4)) return ATA_PIO2; + if (!strncasecmp(str, "PIO3", 4)) return ATA_PIO3; + if (!strncasecmp(str, "PIO4", 4)) return ATA_PIO4; + if (!strncasecmp(str, "WDMA2", 5)) return ATA_WDMA2; + if (!strncasecmp(str, "UDMA2", 5)) return ATA_UDMA2; + if (!strncasecmp(str, "UDMA33", 6)) return ATA_UDMA2; + if (!strncasecmp(str, "UDMA4", 5)) return ATA_UDMA4; + if (!strncasecmp(str, "UDMA66", 6)) return ATA_UDMA4; + if (!strncasecmp(str, "UDMA5", 5)) return ATA_UDMA5; + if (!strncasecmp(str, "UDMA100", 7)) return ATA_UDMA5; + if (!strncasecmp(str, "UDMA6", 5)) return ATA_UDMA6; + if (!strncasecmp(str, "UDMA133", 7)) return ATA_UDMA6; + if (!strncasecmp(str, "BIOSDMA", 7)) return ATA_DMA; + return -1; +} + int ata_pmode(struct ata_params *ap) { @@ -952,6 +974,19 @@ ata_limit_mode(device_t dev, int mode, i { struct ata_device *atadev = device_get_softc(dev); + if (ata_delayed_attach) { + driver_t *drv = device_get_driver(dev); + const char *str = NULL; + int m; + + if (drv && resource_string_value(drv->name, atadev->unit, + "mode", &str) == 0) { + m = ata_str2mode(str); + if (m >= ATA_PIO) + mode = m; + } + } + if (maxmode && mode > maxmode) mode = maxmode; From bu7cher at yandex.ru Fri Jul 25 10:46:46 2008 From: bu7cher at yandex.ru (Andrey V. Elsukov) Date: Fri Jul 25 10:46:52 2008 Subject: ATA patch for RELENG_6 ... a patch looking for a good home In-Reply-To: <4839F473.6070109@miralink.com> References: <4839F473.6070109@miralink.com> Message-ID: <4889A415.1060309@yandex.ru> Sean Bruno wrote: > I got this patch a while ago and I don't see it appearing in RELENG_6 > yet. Can someone "sheperd" this along or point out why it's not > acceptable? > > This patch was generated by a failure to boot correctly off of a compact > flash IDE module from Transcend. > > Index: dev/ata/ata-chipset.c > =================================================================== > --- dev/ata/ata-chipset.c (.../FreeBSD_RELENG_6_13APR07/src/sys) > (revision 5436) > +++ dev/ata/ata-chipset.c (.../miralink.FreeBSD.6/src/sys) > (revision 5436) > @@ -2059,7 +2059,8 @@ > atadev->mode = ATA_SA150; > } > else { > - mode = ata_limit_mode(dev, mode, ATA_UDMA5); > + /*mode = ata_limit_mode(dev, mode, ATA_UDMA5);*/ > + mode = ata_check_80pin(dev, ATA_UDMA5); > if (!ata_controlcmd(dev, ATA_SETFEATURES, ATA_SF_SETXFER, 0, mode)) > atadev->mode = mode; > } Hi, Soren and Sean. What you think about attached patch? It can resolve your problem and shouldn't break anything. With this patch you can set mode in /boot/device.hints, for example: hint.ad.0.mode="UDMA33" hint.ad.1.mode="UDMA100" These limits work only on boot stage, after boot completed you can change mode via atacontrol. -- WBR, Andrey V. Elsukov -------------- next part -------------- Index: src/sys/dev/ata/ata-all.c =================================================================== RCS file: /ncvs/src/sys/dev/ata/ata-all.c,v retrieving revision 1.289 diff -u -b -p -r1.289 ata-all.c --- src/sys/dev/ata/ata-all.c 11 Jun 2008 06:44:58 -0000 1.289 +++ src/sys/dev/ata/ata-all.c 25 Jul 2008 09:54:52 -0000 @@ -889,6 +889,28 @@ ata_mode2str(int mode) } } +static int +ata_str2mode(const char *str) +{ + if (!strncasecmp(str, "BIOSPIO", 7)) return ATA_PIO; + if (!strncasecmp(str, "PIO0", 4)) return ATA_PIO0; + if (!strncasecmp(str, "PIO1", 4)) return ATA_PIO1; + if (!strncasecmp(str, "PIO2", 4)) return ATA_PIO2; + if (!strncasecmp(str, "PIO3", 4)) return ATA_PIO3; + if (!strncasecmp(str, "PIO4", 4)) return ATA_PIO4; + if (!strncasecmp(str, "WDMA2", 5)) return ATA_WDMA2; + if (!strncasecmp(str, "UDMA2", 5)) return ATA_UDMA2; + if (!strncasecmp(str, "UDMA33", 6)) return ATA_UDMA2; + if (!strncasecmp(str, "UDMA4", 5)) return ATA_UDMA4; + if (!strncasecmp(str, "UDMA66", 6)) return ATA_UDMA4; + if (!strncasecmp(str, "UDMA5", 5)) return ATA_UDMA5; + if (!strncasecmp(str, "UDMA100", 7)) return ATA_UDMA5; + if (!strncasecmp(str, "UDMA6", 5)) return ATA_UDMA6; + if (!strncasecmp(str, "UDMA133", 7)) return ATA_UDMA6; + if (!strncasecmp(str, "BIOSDMA", 7)) return ATA_DMA; + return -1; +} + int ata_pmode(struct ata_params *ap) { @@ -955,6 +977,19 @@ ata_limit_mode(device_t dev, int mode, i if (maxmode && mode > maxmode) mode = maxmode; + if (ata_delayed_attach) { + driver_t *drv = device_get_driver(dev); + const char *str = NULL; + int m; + + if (drv && resource_string_value(drv->name, atadev->unit, + "mode", &str) == 0) { + m = ata_str2mode(str); + if (m >= ATA_PIO) + mode = m; + } + } + if (mode >= ATA_UDMA0 && ata_umode(&atadev->param) > 0) return min(mode, ata_umode(&atadev->param)); From sbruno at miralink.com Fri Jul 25 14:43:40 2008 From: sbruno at miralink.com (Sean Bruno) Date: Fri Jul 25 14:43:46 2008 Subject: ATA patch for RELENG_6 ... a patch looking for a good home In-Reply-To: <4889A712.7090204@yandex.ru> References: <4839F473.6070109@miralink.com> <4889A415.1060309@yandex.ru> <4889A712.7090204@yandex.ru> Message-ID: <4889E699.3050606@miralink.com> Andrey V. Elsukov wrote: > Andrey V. Elsukov wrote: >> What you think about attached patch? >> It can resolve your problem and shouldn't break anything. >> With this patch you can set mode in /boot/device.hints, for >> example: >> hint.ad.0.mode="UDMA33" >> hint.ad.1.mode="UDMA100" >> >> These limits work only on boot stage, after boot completed you can >> change mode via atacontrol. > My issue was that the boot device itself was the flash module from Transcend. Setting the speed via atacontrol after the system booted was not preferred as the root device _was_ the Transcend. Does that make sense? > Also, this is the same patch, but it doesn't allow override maximum > mode in device.hints. I don't know which patch is preferable, I think > second one. > I'll try both and get back to you. -- Sean Bruno MiraLink Corporation 6015 NE 80th Ave, Ste 100 Portland, OR 97218 Cell 503-358-6832 Phone 503-621-5143 Fax 503-621-5199 MSN: sbruno@miralink.com Google: seanwbruno@gmail.com From bu7cher at yandex.ru Sat Jul 26 05:25:10 2008 From: bu7cher at yandex.ru (Andrey V. Elsukov) Date: Sat Jul 26 05:25:18 2008 Subject: ATA patch for RELENG_6 ... a patch looking for a good home In-Reply-To: <4889E699.3050606@miralink.com> References: <4839F473.6070109@miralink.com> <4889A415.1060309@yandex.ru> <4889A712.7090204@yandex.ru> <4889E699.3050606@miralink.com> Message-ID: <147801217049898@webmail3.yandex.ru> 25.07.08, 18:43, "Sean Bruno" : > >> These limits work only on boot stage, after boot completed you can > >> change mode via atacontrol. > > > My issue was that the boot device itself was the flash module from > Transcend. Setting the speed via atacontrol after the system booted was > not preferred as the root device _was_ the Transcend. Does that make sense? Yes, I remember your problem. You don't need to change mode after boot. I wanted to say that it is possible to change mode and device.hints doesn't limit you to change mode after boot. > > Also, this is the same patch, but it doesn't allow override maximum > > mode in device.hints. I don't know which patch is preferable, I think > > second one. > > > I'll try both and get back to you. I think you may try only the last patch. -- WBR, Andrey V. Elsukov From ikram at wideband.com.pk Tue Jul 29 19:55:05 2008 From: ikram at wideband.com.pk (Mohammad Ikram) Date: Tue Jul 29 19:55:15 2008 Subject: Incorrect Atheros txpower output Message-ID: <6fe7c62a0807291226x15ef59bcn334c97562f3399b8@mail.gmail.com> Hi ! I am using FreeBSD 7.0 and recently installed a Engines EPI-3601S card. The card has an Atheros chip with a 27dBm output power rating. I am using it as hostap. FreeBSD detects it fine, but the trouble is FreeBSD does not takes the power level up. The max i was able to set is was 16dBm. (ifconfig ath0 txpower xx). I tried it on linux with madwifi but same results, so i started having a few doubts with this card, a friend of mine suggested that i should try the router OS (www.mikrotik.com) i did, and it worked perfectly. can any one tell me why can't i change the power level ? (i did changed country codes, to no avail) i read some where it is the problem with the driver ? so is there any patch ? Ikram Pakistan. From imp at bsdimp.com Tue Jul 29 20:25:38 2008 From: imp at bsdimp.com (M. Warner Losh) Date: Tue Jul 29 20:25:45 2008 Subject: Incorrect Atheros txpower output In-Reply-To: <6fe7c62a0807291226x15ef59bcn334c97562f3399b8@mail.gmail.com> References: <6fe7c62a0807291226x15ef59bcn334c97562f3399b8@mail.gmail.com> Message-ID: <20080729.142220.-749250939.imp@bsdimp.com> In message: <6fe7c62a0807291226x15ef59bcn334c97562f3399b8@mail.gmail.com> "Mohammad Ikram" writes: : Hi ! : : I am using FreeBSD 7.0 and recently installed a Engines EPI-3601S card. The : card has an Atheros chip with a 27dBm output power rating. I am using it as : hostap. FreeBSD detects it fine, but the trouble is FreeBSD does not takes : the power level up. The max i was able to set is was 16dBm. (ifconfig ath0 : txpower xx). I tried it on linux with madwifi but same results, so i started : having a few doubts with this card, a friend of mine suggested that i should : try the router OS (www.mikrotik.com) i did, and it worked perfectly. : : can any one tell me why can't i change the power level ? (i did changed : country codes, to no avail) i read some where it is the problem with the : driver ? so is there any patch ? Did you measure the output power directly? Many cards have a final stage amplifier that kicks things up a few dB... Maybe router OS knows about this card's quirks and copes... Warner From sam at freebsd.org Tue Jul 29 20:39:42 2008 From: sam at freebsd.org (Sam Leffler) Date: Tue Jul 29 20:39:48 2008 Subject: Incorrect Atheros txpower output In-Reply-To: <20080729.142220.-749250939.imp@bsdimp.com> References: <6fe7c62a0807291226x15ef59bcn334c97562f3399b8@mail.gmail.com> <20080729.142220.-749250939.imp@bsdimp.com> Message-ID: <488F7FE1.5080401@freebsd.org> M. Warner Losh wrote: > In message: <6fe7c62a0807291226x15ef59bcn334c97562f3399b8@mail.gmail.com> > "Mohammad Ikram" writes: > : Hi ! > : > : I am using FreeBSD 7.0 and recently installed a Engines EPI-3601S card. The > : card has an Atheros chip with a 27dBm output power rating. I am using it as > : hostap. FreeBSD detects it fine, but the trouble is FreeBSD does not takes > : the power level up. The max i was able to set is was 16dBm. (ifconfig ath0 > : txpower xx). I tried it on linux with madwifi but same results, so i started > : having a few doubts with this card, a friend of mine suggested that i should > : try the router OS (www.mikrotik.com) i did, and it worked perfectly. > : > : can any one tell me why can't i change the power level ? (i did changed > : country codes, to no avail) i read some where it is the problem with the > : driver ? so is there any patch ? > > Did you measure the output power directly? Many cards have a final > stage amplifier that kicks things up a few dB... Maybe router OS > knows about this card's quirks and copes... > > The external PA's you're thinking of are not controllable by the host; they are always present. The original post doesn't explain how mikrotik "worked perfectly" while freebsd did not. I have measured many high power cards with a power meter and SA under FreeBSD and have never seen a power cap other than that imposed by regulatory or vendor mis-claims. Sam From joao at matik.com.br Wed Jul 30 22:58:22 2008 From: joao at matik.com.br (JoaoBR) Date: Wed Jul 30 22:58:30 2008 Subject: Incorrect Atheros txpower output In-Reply-To: <488F7FE1.5080401@freebsd.org> References: <6fe7c62a0807291226x15ef59bcn334c97562f3399b8@mail.gmail.com> <20080729.142220.-749250939.imp@bsdimp.com> <488F7FE1.5080401@freebsd.org> Message-ID: <200807301945.22284.joao@matik.com.br> On Tuesday 29 July 2008 17:38:57 Sam Leffler wrote: > M. Warner Losh wrote: > > In message: <6fe7c62a0807291226x15ef59bcn334c97562f3399b8@mail.gmail.com> > > > > "Mohammad Ikram" writes: > > : Hi ! > > : > > : I am using FreeBSD 7.0 and recently installed a Engines EPI-3601S card. > > : The card has an Atheros chip with a 27dBm output power rating. I am > > : using it as hostap. FreeBSD detects it fine, but the trouble is FreeBSD > > : does not takes the power level up. The max i was able to set is was > > : 16dBm. (ifconfig ath0 txpower xx). I tried it on linux with madwifi but > > : same results, so i started having a few doubts with this card, a friend > > : of mine suggested that i should try the router OS (www.mikrotik.com) i > > : did, and it worked perfectly. > > : > > : can any one tell me why can't i change the power level ? (i did changed > > : country codes, to no avail) i read some where it is the problem with > > : the driver ? so is there any patch ? > > > > Did you measure the output power directly? Many cards have a final > > stage amplifier that kicks things up a few dB... Maybe router OS > > knows about this card's quirks and copes... > > The external PA's you're thinking of are not controllable by the host; > they are always present. The original post doesn't explain how mikrotik > "worked perfectly" while freebsd did not. I have measured many high > power cards with a power meter and SA under FreeBSD and have never seen > a power cap other than that imposed by regulatory or vendor mis-claims. > certainly the poster has reason here, follows an ifconfig from a machine with a DLINK AG530 (ath1) which has 60mW I think and a genius 400mW card (ath0), both show with same power values but clients connected to each card (and switching them between both ssid) show that they get a far better RSSI on the stronger card, something about 20-25% also on client site you can see a clearly stronger signal what on a FreeBSD ath client shows up with 30% more RSSI when connected to the 400mW I do not believe that this card really has 400mW, if then the signal or RSSI should be far stronger but is not, I compare to a test I run with an 0.5W amplifier I sticked onto the Dlink card which than gives a really signal boost I also have no comparism to other OS with this cards and I am not so worried about what ifconfig tells because at the end the signal is stronger I use this ath_hal: 0.10.5.6 but the former hal gave same results ath0: flags=8943 metric 0 mtu 1500 ether 00:02:6f:4a:a6:29 media: IEEE 802.11 Wireless Ethernet DS/11Mbps mode 11b status: associated ssid LUCENET-CW channel 6 (2437 Mhz 11b) bssid 00:02:6f:4a:a6:29 wepkey 4:40-bit powersavemode OFF powersavesleep 100 txpower 31.5 txpowmax 18.0 rtsthreshold 2346 fragthreshold 2346 bmiss 7 scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi11a 7 roam:rate11a 12 roam:rssi11b 7 roam:rate11b 1 roam:rssi11g 7 roam:rate11g 5 -pureg protmode CTS -ht -htcompat -ampdu ampdulimit 8k ampdudensity - -amsdu -shortgi htprotmode RTSCTS -puren -wme burst -ff -dturbo hidessid -apbridge dtimperiod 1 doth inact bintval 100 ath1: flags=8943 metric 0 mtu 1500 ether 00:19:5b:cf:26:78 media: IEEE 802.11 Wireless Ethernet DS/11Mbps mode 11b status: associated ssid LUCENET-CS channel 1 (2412 Mhz 11b) bssid 00:19:5b:cf:26:78 wepkey 4:40-bit powersavemode OFF powersavesleep 100 txpower 31.5 txpowmax 18.0 rtsthreshold 2346 fragthreshold 2346 bmiss 7 scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi11a 7 roam:rate11a 12 roam:rssi11b 7 roam:rate11b 1 roam:rssi11g 7 roam:rate11g 5 -pureg protmode CTS -ht -htcompat -ampdu ampdulimit 8k ampdudensity - -amsdu -shortgi htprotmode RTSCTS -puren -wme burst -ff -dturbo hidessid -apbridge dtimperiod 1 doth inact bintval 100 -- Jo?o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br