Re: Call for Test and Review: bwn(4) - another Broadcom Wireless driver
On Wed, Dec 23, 2009 at 08:18:48AM +, Aditya Sarawgi wrote: > On Tue, Dec 22, 2009 at 07:53:31PM -0800, Weongyo Jeong wrote: > > Hello, > > > > Now bwn(4) is available at the public and waiting test and review. The > > status of this driver is *alpha* so could make panics, warnings and > > errors. Please let me know if you encounter problems. > > > > The following NICs all I have are only tested on the little endian 64bit > > machine and big endian 32bit machine. > > > > - Broadcom BCM4306 802.11b/g Wireless > > - Broadcom BCM4318 802.11b/g Wireless > > > > I tested basic RX, TX and WPA association as STA mode and checked it > > worked. > > > > As you might know there are still a lot of TODO in the driver so you > > could see some verbose messages during testing so please ignore or let > > me know it makes problems. > > > > == How to build and load == > > > > # cd /usr/src/sys > > # fetch http://people.freebsd.org/~weongyo/bwn_20091222.tar.gz > > # tar xzf bwn_20091222.tar.gz > > # cd modules/ssb > > # make && make install > > # cd ../.. > > # cd modules/bwn > > # make && make install > > # cd somewhere > > # fetch http://people.freebsd.org/~weongyo/bwn_ports_20091222.tar.gz > > # tar xzf bwn_ports_20091222.tar.gz > > # cd sysutils/b43-fwcutter > > # make install clean > > # cd ../.. > > # cd net/bwn-firmware-kmod > > # make install clean > > # > > # kldload ssb > > # kldload bwn_v4_ucode > > # kldload if_bwn > > > > regards, > > Weongyo Jeong > > > > Hi, > > The driver doesn't work with BCM4315, here's what dmesg shows > > ssb0: mem 0xf400-0xf4003fff > irq 19 at device 0.0 on pci6 > bwn0 on ssb0 > bwn0: unsupported PHY type (5) > device_attach: bwn0 attach returned 6 FYI bwn(4) driver is committed into FreeBSD tree. I think the driver supports your LP PHY device. After cvsup please try to rebuild siba_bwn and bwn modules. Could you please test with it? Please let me know and send me your full dmesg when you encounters the following problems: - if the driver doesn't work or is unstable. - if it prints debugging or verbose messages. regards, Weongyo Jeong ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Call for Test and Review: bwn(4) - another Broadcom Wireless driver
On Fri, Feb 26, 2010 at 04:21:06PM -0800, Xin LI wrote: > Hi, Weongyo, > > On 2010/02/25 16:51, Weongyo Jeong wrote: > > FYI bwn(4) driver is committed into FreeBSD tree. I think the driver > > supports your LP PHY device. After cvsup please try to rebuild siba_bwn > > and bwn modules. > > > > Could you please test with it? Please let me know and send me your > > full dmesg when you encounters the following problems: > > > > - if the driver doesn't work or is unstable. > > - if it prints debugging or verbose messages. > > Great! Thanks for the work! > > Is it possible to MFC the work back to 8-STABLE at some point? Of course yes. AFAIK it could be compiled and works without problems on 8-STABLE; I checked it. :-) > A colleague of mine has tried to compile the code on 8-STABLE but seems > that it's using some new API I guess... I've asked him to try a > 9-CURRENT kernel but the Atom based netbook would take some while to > compile the code =-) Thank you. regards, Weongyo Jeong ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Call for Test and Review: bwn(4) - another Broadcom Wireless driver
On Sat, Feb 27, 2010 at 01:15:35AM +0200, Alex RAY wrote: > Hi Weongyo, > > Can new siba release operate in systems like in this SVG image? > System example: CPU BCM5836 + Wi-Fi BCM4318 Recent changes of siba(4) by myself doesn't change code flow, layout and doesn't include enhancements if you're an user of SENTRY5 mips CPU (like BCM5836) All I did on recent changes were to put common routines or codes which could be used for original siba(4). These codes are only used for bwn(4) driver currently and don't be merged with original siba(4). That means there are two separated codes in current siba(4) so merging two into one is a TODO. I have no idea current siba(4) supports a system using on CPU BCM5836 + Wi-Fi BCM4318 but in theory it should work without problems though I didn't test. > And can we compile siba bus code without pci code? I think it looks that it could be possible to compile without pci code. But makes sure that your device doesn't have PCI core. regards, Weongyo Jeong ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Call for Test and Review: bwn(4) - another Broadcom Wireless driver
On Sun, Feb 28, 2010 at 11:56:50PM +, Aditya Sarawgi wrote: > On Wed, Dec 23, 2009 at 11:51:34AM -0800, Weongyo Jeong wrote: > > On Wed, Dec 23, 2009 at 08:18:48AM +, Aditya Sarawgi wrote: > > > On Tue, Dec 22, 2009 at 07:53:31PM -0800, Weongyo Jeong wrote: > > > > Hello, > > > > > > > > Now bwn(4) is available at the public and waiting test and review. The > > > > status of this driver is *alpha* so could make panics, warnings and > > > > errors. Please let me know if you encounter problems. > > > > > > > > The following NICs all I have are only tested on the little endian 64bit > > > > machine and big endian 32bit machine. > > > > > > > > - Broadcom BCM4306 802.11b/g Wireless > > > > - Broadcom BCM4318 802.11b/g Wireless > > > > > > > > I tested basic RX, TX and WPA association as STA mode and checked it > > > > worked. > > > > > > > > As you might know there are still a lot of TODO in the driver so you > > > > could see some verbose messages during testing so please ignore or let > > > > me know it makes problems. > > > > > > > > == How to build and load == > > > > > > > > # cd /usr/src/sys > > > > # fetch http://people.freebsd.org/~weongyo/bwn_20091222.tar.gz > > > > # tar xzf bwn_20091222.tar.gz > > > > # cd modules/ssb > > > > # make && make install > > > > # cd ../.. > > > > # cd modules/bwn > > > > # make && make install > > > > # cd somewhere > > > > # fetch http://people.freebsd.org/~weongyo/bwn_ports_20091222.tar.gz > > > > # tar xzf bwn_ports_20091222.tar.gz > > > > # cd sysutils/b43-fwcutter > > > > # make install clean > > > > # cd ../.. > > > > # cd net/bwn-firmware-kmod > > > > # make install clean > > > > # > > > > # kldload ssb > > > > # kldload bwn_v4_ucode > > > > # kldload if_bwn > > > > > > > > regards, > > > > Weongyo Jeong > > > > > > > > > > Hi, > > > > > > The driver doesn't work with BCM4315, here's what dmesg shows > > > > > > ssb0: mem 0xf400-0xf4003fff > > > irq 19 at device 0.0 on pci6 > > > bwn0 on ssb0 > > > bwn0: unsupported PHY type (5) > > > device_attach: bwn0 attach returned 6 > > > > I see that your device has LP-PHY instead of A/B/G/N PHYs so currently > > it's not supported by bwn(4). > > > > AFAIK linux has a weak but working implementation so we could refer to > > other Open Sources. > > > > regards, > > Weongyo Jeong > > > > Hi, > > It still doesn't work, when I try to do > ifconfig bwn0 scan > I get > ifconfig: unable to get the scan results uses the following commands instead of it that you didn't create the virtual wlan interface: # ifconfig wlan0 create wlandev bwn0 # ifconfig wlan0 up # ifconfig wlan0 scan # ifconfig wlan0 list scan > The device is getting recognized properly > here's the dmesg > > siba_bwn0: mem > 0xf400-0xf4003fff irq 19 at device 0.0 on pci6 > bwn0 on siba_bwn0 > bwn0: WLAN (chipid 0x4312 rev 15) PHY (analog 6 type 5 rev 1) RADIO > (manuf 0x17f ver 0x2062 rev 2) > bwn0: DMA (64 bits) > bwn0: Using 1 MSI messages > bwn0: [FILTER] > > I have loaded the following modules > bwn_v4_ucode.ko Please uses bwn_v4_lp_ucode.ko because your device looks it's LP PHY. > if_bwn.ko > siba_bwn.ko regards, Weongyo Jeong ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Call for Test and Review: bwn(4) - another Broadcom Wireless driver
On Sun, Feb 28, 2010 at 08:45:32PM +0100, Miki wrote: > Hi, > > Thanks for the work ! > > I have some problems here when I try to create a wlan interface : > bwn_v4_ucode5: could not load firmware image, error 2 > bwn0: the fw file(bwn_v4_ucode5) not found Did you try to UP the interface withload loading bwn_v4_ucode.ko? If yes currently bwn(4) doesn't automatically load firmware module so you need to do it by hand. # kldload bwn_v4_ucode The patch for this is ready to commit and it'll be happened soon. > I have installed bwn-firmware-kmod from ports but the only files I have in > /boot/modules are bwn_v4_lp_ucode.ko and bwn_v4_ucode.ko. So I tried to > copy bwn_v4_ucode to bwn_v4_ucode5 and it seems to work : wlan0 is > created, I can associate to an open Access Point and obtain a DHCP lease. > But if I try to do some network IO (browsing the web) the interface hang > (I cannot obtain a lease anymore). I have a exact same device like you have but I didn't encounter this issue. Are there any messages from bwn(4) when you the interface becomes hang? One more question, after the interface hang, does the system be hang also? One thing you can do is that trying the device with PIO mode not DMA mode using the following tunable variable: hw.bwn.usedma Its default value is 1 to enable DMA operation so if you set it 0, PIO mode would be used and could see the message like below: bwn0: PIO Could you please test with it? regards, Weongyo Jeong ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Problem with new bwn driver on -CURRENT
On Sun, Feb 28, 2010 at 03:24:28PM -0500, Joe Marcus Clarke wrote:
> I was extremely pleased to see this driver, so I could get off of the
> flaky NDIS version. I have a Dell Vostra 2510 with a LP bwn mini-PCI
> card. I have set if_bwn_load="YES" in /boot/loader.conf. I also have
> bwn_v4_lp_ucode_load="YES" set.
>
> The firmware and driver loads. However, if_bwn doesn't attach to the
> card. Once the OS is fully booted, I kldunload if_bwn, then reload it,
> and the driver attaches just fine.
This issue is reported by some people and I'm looking codes.
> Once it is attached, however, I can
> pass traffic just fine, but I get a large number of these messages on
> the console, and the traffic rate is not what it was with the NDIS
> driver:
Could you please elaborate the traffic rate? You mean the traffic rate
is lower or higher than NDIS driver?
>
> bwn0: out of bounds of the square-root table (-770884)
> bwn0: out of bounds of the square-root table (-225625)
> bwn0: out of bounds of the square-root table (-240100)
Patch is attached with email and it'll fix this message. Could you
please test with it?
Was it successful to associate with AP?
> When I boot with verbose mode, I only see the siba driver attach to the
> card:
>
> siba_bwn0: mem 0xf400-0xf4003fff
> irq 19 at device 0.0 on pci6
>
> My pciconf output is:
>
> siba_b...@pci0:6:0:0: class=0x028000 card=0x000b1028 chip=0x431514e4
> rev=0x01 hdr=0x00
> vendor = 'Broadcom Corporation'
> device = 'Broadcom Wireless b/g (BCM4315/BCM22062000)'
> class = network
>
> When the driver does attach, I see:
>
> bwn0 on siba_bwn0
> bwn0: WLAN (chipid 0x4312 rev 15) PHY (analog 6 type 5 rev 1) RADIO (manuf
> 0x17f
> bwn0: DMA (64 bits)
> bwn0: MSI count : 1
> siba_bwn0: attempting to allocate 1 MSI vectors (1 supported)
> msi: routing MSI IRQ 258 to local APIC 1 vector 54
> siba_bwn0: using IRQ 258 for MSI
> bwn0: Using 1 MSI messages
> bwn0: [MPSAFE]
> bwn0: [FILTER]
> bwn0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
> bwn0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps
> 36M
> bps 48Mbps 54Mbps
> wlan0: bpf attached
> wlan0: bpf attached
>
> Am I missing anything to get this to attach at boot time? Thanks.
Maybe nothing. It looks there's a bug to attach bwn on boot time.
One thing FYI is that bwn(4)'s LP implementation has some problems to
calibrate TX so sometimes TX speed could be unstable and fluctuate.
regards,
Weongyo Jeong
Index: if_bwn.c
===
--- if_bwn.c (revision 204437)
+++ if_bwn.c (working copy)
@@ -12846,7 +12846,6 @@
static unsigned int
bwn_sqrt(struct bwn_mac *mac, unsigned int x)
{
- struct bwn_softc *sc = mac->mac_sc;
/* Table holding (10 * sqrt(x)) for x between 1 and 256. */
static uint8_t sqrt_table[256] = {
10, 14, 17, 20, 22, 24, 26, 28,
@@ -12886,9 +12885,11 @@
if (x == 0)
return (0);
if (x >= 256) {
- device_printf(sc->sc_dev,
- "out of bounds of the square-root table (%d)\n", x);
- return (16);
+ unsigned int tmp;
+
+ for (tmp = 0; x >= (2 * tmp) + 1; x -= (2 * tmp++) + 1)
+ /* do nothing */ ;
+ return (tmp);
}
return (sqrt_table[x - 1] / 10);
}
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Call for Test and Review: bwn(4) - another Broadcom Wireless driver
On Mon, Mar 01, 2010 at 10:32:40AM +0200, Alexandr Rybalko wrote: > On Sun, 28 Feb 2010 01:52:59 -0800 > Weongyo Jeong wrote: > > >> On Sat, Feb 27, 2010 at 01:15:35AM +0200, Alex RAY wrote: > >> > Hi Weongyo, > >> > > >> > Can new siba release operate in systems like in this SVG image? > >> > System example: CPU BCM5836 + Wi-Fi BCM4318 > >> > >> Recent changes of siba(4) by myself doesn't change code flow, layout and > >> doesn't include enhancements if you're an user of SENTRY5 mips CPU (like > >> BCM5836) > >> > >> All I did on recent changes were to put common routines or codes which > >> could be used for original siba(4). These codes are only used for > >> bwn(4) driver currently and don't be merged with original siba(4). That > >> means there are two separated codes in current siba(4) so merging two > >> into one is a TODO. > >> > >> I have no idea current siba(4) supports a system using on CPU BCM5836 + > >> Wi-Fi BCM4318 but in theory it should work without problems though I > >> didn't test. > >> > >> > And can we compile siba bus code without pci code? > >> > >> I think it looks that it could be possible to compile without pci code. > >> But makes sure that your device doesn't have PCI core. > > Can You test your driver without siba_switchcore, I see the device > have mapping for all cores on SSB? I see what you mean. siba_core.c which depends on PCI code would be compiled when it builds on SENTRY5. So it looks currently it needs a patch to compile siba bus code without PCI code. I'll try to make a patch. > > ssb0: mem 0xf400-0xf4003fff > Think thre is 4 cores. > When SSB on nexus, we don`t need core switching, maybe on PCI too. I think this is a difference between siba(4) and siba_bwn currently and it's one of TODOs we should solve to merge two codes. AFAIK approach to access each cores isn't same; it looks siba(4) creates devices for each cores so it'd not need to switch cores. But siba_bwn doesn't do it like siba(4) so it needs to switch cores because all are handled on one device. regards, Weongyo Jeong ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Problem with new bwn driver on -CURRENT
On Mon, Mar 01, 2010 at 11:50:43PM -0500, Joe Marcus Clarke wrote: > On Mon, 2010-03-01 at 15:37 -0800, Weongyo Jeong wrote: > > On Sun, Feb 28, 2010 at 03:24:28PM -0500, Joe Marcus Clarke wrote: > > > I was extremely pleased to see this driver, so I could get off of the > > > flaky NDIS version. I have a Dell Vostra 2510 with a LP bwn mini-PCI > > > card. I have set if_bwn_load="YES" in /boot/loader.conf. I also have > > > bwn_v4_lp_ucode_load="YES" set. > > > > > > The firmware and driver loads. However, if_bwn doesn't attach to the > > > card. Once the OS is fully booted, I kldunload if_bwn, then reload it, > > > and the driver attaches just fine. > > > > This issue is reported by some people and I'm looking codes. > > Good to know. This issue is solved in r204657. Thank you for reporting! > > > > > > Once it is attached, however, I can > > > pass traffic just fine, but I get a large number of these messages on > > > the console, and the traffic rate is not what it was with the NDIS > > > driver: > > > > Could you please elaborate the traffic rate? You mean the traffic rate > > is lower or higher than NDIS driver? > > The throughput with the if_bwn driver is less than with the ndis driver. > It associates at 11g (36 Mbps), but the RTT is longer. This is > noticeable with apps like VNC. The redraw is noticeably slower (line by > line) than it was ndis. Low throughput apps like SSH work more or less > the same. > > > > > > > > > bwn0: out of bounds of the square-root table (-770884) > > > bwn0: out of bounds of the square-root table (-225625) > > > bwn0: out of bounds of the square-root table (-240100) > > > > Patch is attached with email and it'll fix this message. Could you > > please test with it? > > Yes, the patch removes those messages. Thanks! > > > > > Was it successful to associate with AP? > > Yes, in DMA mode. In PIO mode, it associates, but does not pass any > traffic. After a while, there was a critical DMA error, and the driver > looped forever trying to communicate with the card. Are there any messages from bwn(4) related with DMA error? If yes and you reproduce DMA error easily could you please show me the full dmesg? regards, Weongyo Jeong ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Problem with new bwn driver on -CURRENT
On Wed, Mar 03, 2010 at 05:46:09PM -0500, Joe Marcus Clarke wrote: > On 3/3/10 5:04 PM, Weongyo Jeong wrote: > > On Mon, Mar 01, 2010 at 11:50:43PM -0500, Joe Marcus Clarke wrote: > >> On Mon, 2010-03-01 at 15:37 -0800, Weongyo Jeong wrote: > >>> On Sun, Feb 28, 2010 at 03:24:28PM -0500, Joe Marcus Clarke wrote: > >>>> I was extremely pleased to see this driver, so I could get off of the > >>>> flaky NDIS version. I have a Dell Vostra 2510 with a LP bwn mini-PCI > >>>> card. I have set if_bwn_load="YES" in /boot/loader.conf. I also have > >>>> bwn_v4_lp_ucode_load="YES" set. > >>>> > >>>> The firmware and driver loads. However, if_bwn doesn't attach to the > >>>> card. Once the OS is fully booted, I kldunload if_bwn, then reload it, > >>>> and the driver attaches just fine. > >>> > >>> This issue is reported by some people and I'm looking codes. > >> > >> Good to know. > > > > This issue is solved in r204657. Thank you for reporting! > > Saw that, thanks! > > > >>>> bwn0: out of bounds of the square-root table (-770884) > >>>> bwn0: out of bounds of the square-root table (-225625) > >>>> bwn0: out of bounds of the square-root table (-240100) > >>> > >>> Patch is attached with email and it'll fix this message. Could you > >>> please test with it? > >> > >> Yes, the patch removes those messages. Thanks! > > Was this patch committed? I don't recall seeing an svn notice. Yes at r204542. > > >> > >>> > >>> Was it successful to associate with AP? > >> > >> Yes, in DMA mode. In PIO mode, it associates, but does not pass any > >> traffic. After a while, there was a critical DMA error, and the driver > >> looped forever trying to communicate with the card. > > > > Are there any messages from bwn(4) related with DMA error? If yes and > > you reproduce DMA error easily could you please show me the full dmesg? > > When it occurs, it is a fatal DMA error, and this streams on the console > until reboot. In order to get the card to work again (with either bwn > or ndis), I need to power-cycle the laptop. > > When it occurs again, I will get you the details and the full dmesg. Do > you want a verbose dmesg, or a standard one? I think a standard one is enough. Thank you. regards, Weongyo Jeong ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Call for Test and Review: bwn(4) - another Broadcom Wireless driver
On Tue, Mar 02, 2010 at 07:57:26PM +0100, Gustau P?rez wrote: > En/na John Baldwin ha escrit: > > On Monday 01 March 2010 3:22:34 pm Gustau P?rez wrote: > > > >> En/na Weongyo Jeong ha escrit: > >> > >>> On Fri, Feb 26, 2010 at 04:21:06PM -0800, Xin LI wrote: > >>> > >>> > >>>> Hi, Weongyo, > >>>> > >>>> On 2010/02/25 16:51, Weongyo Jeong wrote: > >>>> > >>>> > >>>>> FYI bwn(4) driver is committed into FreeBSD tree. I think the driver > >>>>> supports your LP PHY device. After cvsup please try to rebuild siba_bwn > >>>>> and bwn modules. > >>>>> > >>>>> Could you please test with it? Please let me know and send me your > >>>>> full dmesg when you encounters the following problems: > >>>>> > >>>>> - if the driver doesn't work or is unstable. > >>>>> - if it prints debugging or verbose messages. > >>>>> > >>>>> > >>>> Great! Thanks for the work! > >>>> > >>>> Is it possible to MFC the work back to 8-STABLE at some point? > >>>> > >>>> > >>> Of course yes. AFAIK it could be compiled and works without problems on > >>> 8-STABLE; I checked it. :-) > >>> > >>> > >>> > >>I'm trying to run it in STABLE right now. When kldloading if_bwm > >> (following the given instructions, the other modules are kldloaded) it > >> complains with : > >> > >> link_elf_obj: symbol _mtx_assert undefined > >> > >>looks like it fails in if_bwnvar.h. Culprit is this define : > >> > >> #defineBWN_ASSERT_LOCKED(sc) > >> mtx_assert(&(sc)->sc_mtx, MA_OWNED) > >> > >>Do I need witness enabled to run this ? Is there any way to run it in > >> STABLE or do I need to run CURRENT ? > >> > > > > It sounds like you have INVARIANTS defined when the module was built, but > > your > > kernel does not have INVARIANT_SUPPORT defined. > > > > >That did it. Thank you. After recompiling and rebooting the kernel, I > noticed via dmesg that when kldloading ssb the module complains with : > > ssb0: mem > 0xf9ffc000-0xf9ff irq 17 at device 0.0 on pci12 > ssb0: unsupportted coreid 0x817 > >When kldloading if_bwn (after bwn_v4_ucode) the machine freezes. I > guess my hard isn't supported yet. It looks you're using old bwn(4) sources. Could you test it with sources on HEAD? You should use and compile siba_bwn module and bwn module on HEAD. regards, Weongyo Jeong ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Problem with new bwn driver on -CURRENT
On Thu, Mar 04, 2010 at 12:12:02AM -0500, Joe Marcus Clarke wrote: > On Wed, 2010-03-03 at 15:14 -0800, Weongyo Jeong wrote: > > > When it occurs again, I will get you the details and the full dmesg. Do > > > you want a verbose dmesg, or a standard one? > > > > I think a standard one is enough. Thank you. > > Here you go. This is on -CURRENT from about 30 minutes ago. Thanks for > looking into this. > > http://www.marcuscom.com/downloads/salami.dmesg Thank you for dmesg. It looks using PIO mode is only a way to avoid this problem. I looked sources and problems of other Broadcom wireless driver for LP PHY users. They also encounters this issue and are trying to solve this but no luck and no perfect patch until now. Recently AFAIK wireless-test git of linux adopted a patch `gracefully convert DMA to PIO mode' to solve it. Additionally some guys tolds some success story when they disabled ACPI but it looks it's not a perfect solution. IIRC you said PIO worked for association with your AP but no further traffic. However I wonder that this is weird for me because paths of sending management frames and sending data frames are same. Could you please recheck whether PIO mode worked? I'll try to test PIO mode on my environment again. regards, Weongyo Jeong ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Problem with new bwn driver on -CURRENT
On Fri, Mar 05, 2010 at 04:44:34PM -0500, Joe Marcus Clarke wrote:
> On 3/5/10 3:53 PM, Weongyo Jeong wrote:
> > On Thu, Mar 04, 2010 at 12:12:02AM -0500, Joe Marcus Clarke wrote:
> >> On Wed, 2010-03-03 at 15:14 -0800, Weongyo Jeong wrote:
> >>>> When it occurs again, I will get you the details and the full dmesg. Do
> >>>> you want a verbose dmesg, or a standard one?
> >>>
> >>> I think a standard one is enough. Thank you.
> >>
> >> Here you go. This is on -CURRENT from about 30 minutes ago. Thanks for
> >> looking into this.
> >>
> >> http://www.marcuscom.com/downloads/salami.dmesg
> >
> > Thank you for dmesg. It looks using PIO mode is only a way to avoid
> > this problem.
> >
> > I looked sources and problems of other Broadcom wireless driver for LP
> > PHY users. They also encounters this issue and are trying to solve
> > this but no luck and no perfect patch until now.
> >
> > Recently AFAIK wireless-test git of linux adopted a patch `gracefully
> > convert DMA to PIO mode' to solve it.
> >
> > Additionally some guys tolds some success story when they disabled ACPI
> > but it looks it's not a perfect solution.
> >
> > IIRC you said PIO worked for association with your AP but no further
> > traffic. However I wonder that this is weird for me because paths of
> > sending management frames and sending data frames are same. Could you
> > please recheck whether PIO mode worked? I'll try to test PIO mode on my
> > environment again.
>
> I can absolutely confirm PIO mode does NOT work with my card. I tested
> on a clean power-up. The card associates, but does not pass any
> traffic. I do not see the same decryption messages that I do with DMA mode.
OK. I'd like to see some verbose message from bwn(4) after applying
attached patch with email. Could you please test with it and show me
dmesg?
I tested 3 broadcom card whose revisions are 5 and 9 and it looks it's
working.
I have one LP PHY device, half MiniPCI-E for laptop, but could not test
with this patch because I could not turn on RF; it's connected with
desktop using converter MiniPCI-E to PCI-E though normally it looks
MiniPCI-E devices are turned on using H/W RF switch.
regards,
Weongyo Jeong
Index: if_bwn.c
===
--- if_bwn.c (revision 204657)
+++ if_bwn.c (working copy)
@@ -73,6 +73,7 @@
#include
#include
+#define BWN_DEBUG
SYSCTL_NODE(_hw, OID_AUTO, bwn, CTLFLAG_RD, 0, "Broadcom driver parameters");
/*
@@ -102,6 +103,7 @@
BWN_DEBUG_FW = 0x4000, /* firmware */
BWN_DEBUG_WME = 0x8000, /* WME */
BWN_DEBUG_RF = 0x0001, /* RF */
+ BWN_DEBUG_PIO = 0x0002, /* PIO */
BWN_DEBUG_FATAL = 0x8000, /* fatal errors */
BWN_DEBUG_ANY = 0x
};
@@ -124,7 +126,7 @@
"uses H/W power control");
static int bwn_msi_disable = 0; /* MSI disabled */
TUNABLE_INT("hw.bwn.msi_disable", &bwn_msi_disable);
-static int bwn_usedma = 1;
+static int bwn_usedma = 0;
SYSCTL_INT(_hw_bwn, OID_AUTO, usedma, CTLFLAG_RD, &bwn_usedma, 0,
"uses DMA");
TUNABLE_INT("hw.bwn.usedma", &bwn_usedma);
@@ -936,8 +938,11 @@
sc->sc_sd = sd;
#ifdef BWN_DEBUG
sc->sc_debug = bwn_debug;
+ sc->sc_debug |= BWN_DEBUG_ANY;
#endif
+ device_printf(dev, "DEBUG %#x\n", sc->sc_debug);
+
if ((sc->sc_flags & BWN_FLAG_ATTACHED) == 0) {
error = bwn_attach_pre(sc);
if (error != 0)
@@ -1410,6 +1415,7 @@
struct bwn_pio_txqueue *tq = bwn_pio_select(mac, M_WME_GETAC(m));
struct bwn_softc *sc = mac->mac_sc;
struct bwn_txhdr txhdr;
+ struct ieee80211_frame *wh;
struct mbuf *m_new;
uint32_t ctl32;
int error;
@@ -1434,6 +1440,12 @@
tq->tq_used += roundup(m->m_pkthdr.len + BWN_HDRSIZE(mac), 4);
tq->tq_free--;
+ wh = mtod(m, struct ieee80211_frame *);
+ DPRINTF(sc, BWN_DEBUG_PIO,
+ "tx: used %d free %d (type %#x subtype %#x)\n", tq->tq_used,
+ tq->tq_free, wh->i_fc[0] & IEEE80211_FC0_TYPE_MASK,
+ wh->i_fc[0] & IEEE80211_FC0_SUBTYPE_MASK);
+
if (mac->mac_sd->sd_id.sd_rev >= 8) {
/*
* XXX please removes m_defrag(9)
@@ -9236,6 +9248,8 @@
m->m_pkthdr.rcvif = ifp;
m->m_len = m->m_pkthdr.len = len + padding;
+ DPRINTF(sc, BWN_DEBUG_PIO, "rx: m %p len %d\n", m, m->m_pkthdr.len);
+
bwn_rxeof(prq->prq_mac, m, &rxhdr);
return (1);
@@ -9562,6 +9576,9 @@
tp->tp_m = NULL;
TAILQ_INSERT_TAIL(&tq->tq_pktlist, tp, tp_list);
+ DPRINTF(sc, BWN_DEBUG_PIO, "txeof: used %d free %d\n", tq->tq_used,
+ tq->tq_free);
+
ifp->if_opackets++;
sc->sc_watchdog_timer = 0;
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Problem with new bwn driver on -CURRENT
On Sun, Mar 07, 2010 at 12:05:43AM -0500, Joe Marcus Clarke wrote: > On Fri, 2010-03-05 at 16:16 -0800, Weongyo Jeong wrote: > > On Fri, Mar 05, 2010 at 04:44:34PM -0500, Joe Marcus Clarke wrote: > > > On 3/5/10 3:53 PM, Weongyo Jeong wrote: > > > > On Thu, Mar 04, 2010 at 12:12:02AM -0500, Joe Marcus Clarke wrote: > > > >> On Wed, 2010-03-03 at 15:14 -0800, Weongyo Jeong wrote: > > > >>>> When it occurs again, I will get you the details and the full dmesg. > > > >>>> Do > > > >>>> you want a verbose dmesg, or a standard one? > > > >>> > > > >>> I think a standard one is enough. Thank you. > > > >> > > > >> Here you go. This is on -CURRENT from about 30 minutes ago. Thanks > > > >> for > > > >> looking into this. > > > >> > > > >> http://www.marcuscom.com/downloads/salami.dmesg > > > > > > > > Thank you for dmesg. It looks using PIO mode is only a way to avoid > > > > this problem. > > > > > > > > I looked sources and problems of other Broadcom wireless driver for LP > > > > PHY users. They also encounters this issue and are trying to solve > > > > this but no luck and no perfect patch until now. > > > > > > > > Recently AFAIK wireless-test git of linux adopted a patch `gracefully > > > > convert DMA to PIO mode' to solve it. > > > > > > > > Additionally some guys tolds some success story when they disabled ACPI > > > > but it looks it's not a perfect solution. > > > > > > > > IIRC you said PIO worked for association with your AP but no further > > > > traffic. However I wonder that this is weird for me because paths of > > > > sending management frames and sending data frames are same. Could you > > > > please recheck whether PIO mode worked? I'll try to test PIO mode on my > > > > environment again. > > > > > > I can absolutely confirm PIO mode does NOT work with my card. I tested > > > on a clean power-up. The card associates, but does not pass any > > > traffic. I do not see the same decryption messages that I do with DMA > > > mode. > > > > OK. I'd like to see some verbose message from bwn(4) after applying > > attached patch with email. Could you please test with it and show me > > dmesg? > > > > I tested 3 broadcom card whose revisions are 5 and 9 and it looks it's > > working. > > > > I have one LP PHY device, half MiniPCI-E for laptop, but could not test > > with this patch because I could not turn on RF; it's connected with > > desktop using converter MiniPCI-E to PCI-E though normally it looks > > MiniPCI-E devices are turned on using H/W RF switch. > > Here are two dmesg outputs. Both were taken with this patch. One is > with PIO mode, and the other is with (working) DMA mode. The names > indicate which is which. > > http://www.marcuscom.com/downloads/salami_pio.dmesg > http://www.marcuscom.com/downloads/salami_dma.dmesg Thank you for dmesg. It looks you are right that your device in PIO mode doesn't work. Specially RX path is weird that it was good until the status is changed to RUN but after querying DHCP requests (or another) there were no more RX events (seems no more frames ready). I think it'd be better to file a PR because I could not test LP PHY easily and it looks that it takes time to solve this problem. Could you please do that? regards, Weongyo Jeong ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: sys/dev/siba/siba_core.c fails compilation
On Wed, Mar 10, 2010 at 07:37:56PM -0500, Michael Butler wrote: > If compiling -current without debugging enabled, this module fails with > a warning about unused variables (warnings treated as errors). > > The attached patch allows compilation to proceed although I'm not > convinced that it's entirely correct (duplicate evaluation of > device_get_ivars()), Your patch is committed at r204992. Thank you! regards, Weongyo Jeong ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [head tinderbox] failure on powerpc/powerpc
On Thu, Mar 11, 2010 at 09:10:35PM +1300, Andrew Thompson wrote:
> On Wed, Mar 10, 2010 at 10:48:27PM -0800, Garrett Cooper wrote:
> > Weongyo, et all,
> >
> > On Wed, Mar 10, 2010 at 10:29 PM, FreeBSD Tinderbox
> > > /src/sys/modules/siba_bwn/../../dev/siba/siba_core.c:2035: error: request
> > > for member 'sd_bus' in something not a structure or union
> > > *** Error code 1
> > >
> > > Stop in /src/sys/modules/siba_bwn.
> > > *** Error code 1
> > >
> > > Stop in /src/sys/modules.
> > > *** Error code 1
> > >
> > > Stop in /obj/powerpc/src/sys/LINT.
> > > *** Error code 1
> > >
> > > Stop in /src.
> > > *** Error code 1
> > >
> > > Stop in /src.
> > > TB --- 2010-03-11 06:29:31 - WARNING: /usr/bin/make returned exit code ?1
> > > TB --- 2010-03-11 06:29:31 - ERROR: failed to build lint kernel
> > > TB --- 2010-03-11 06:29:31 - 3629.47 user 614.12 system 4685.83 real
> >
> > Could someone please try this patch to see whether or not it fixes
> > the void* deref issue? I don't think it's style(9) correct, but it
> > might resolve the issue.
> > Thanks,
> > -Garrett
> >
> > Index: siba_core.c
> > ===
> > --- siba_core.c (revision 204996)
> > +++ siba_core.c (working copy)
> > @@ -2032,9 +2032,9 @@
> > siba_dma_translation(device_t dev)
> > {
> >
> > - KASSERT(device_get_ivars(dev)->sd_bus->siba_type == SIBA_TYPE_PCI,
> > - ("unsupported bustype %d\n",
> > -device_get_ivars(dev)->sd_bus->siba_type));
> > + KASSERT(((struct siba_softc *)
> > device_get_ivars(dev))->sd_bus->siba_type ==
> > + SIBA_TYPE_PCI, ("unsupported bustype %d\n",
> > + ((struct siba_softc*) device_get_ivars(dev))->sd_bus->siba_type));
> >
>
> It was all getting a bit unwieldy, I committed a more simple fix in
> r205003.
Thank you for fix and sorry for break build.
regards,
Weongyo Jeong
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Call for Test and Review: bwn(4) - another Broadcom Wireless driver
On Wed, Mar 03, 2010 at 11:10:14AM +0200, Alexandr Rybalko wrote: > On Wed, 3 Mar 2010 00:28:33 -0800 > Weongyo Jeong wrote: > > >> On Mon, Mar 01, 2010 at 10:32:40AM +0200, Alexandr Rybalko wrote: > >> > On Sun, 28 Feb 2010 01:52:59 -0800 > >> > Weongyo Jeong wrote: > >> > > >> > Can You test your driver without siba_switchcore, I see the device > >> > have mapping for all cores on SSB? > >> > >> I see what you mean. siba_core.c which depends on PCI code would be > >> compiled when it builds on SENTRY5. So it looks currently it needs a > >> patch to compile siba bus code without PCI code. I'll try to make a > >> patch. > > I now trying to make bus independent interface, not done yet. > When finish, I send to You for review and maybe test. It's my pleasure to test your patch. > > >> > >> > > ssb0: mem 0xf400-0xf4003fff > >> > Think thre is 4 cores. > >> > When SSB on nexus, we don`t need core switching, maybe on PCI too. > >> > >> I think this is a difference between siba(4) and siba_bwn currently and > >> it's one of TODOs we should solve to merge two codes. > >> > >> AFAIK approach to access each cores isn't same; it looks siba(4) creates > >> devices for each cores so it'd not need to switch cores. But siba_bwn > >> doesn't do it like siba(4) so it needs to switch cores because all are > >> handled on one device. > > Look into this line: > ssb0: mem 0xf400-0xf4003fff > There we see, device have 0x4000 memory window. Each core required 0x1000. > Your code to call required core move PCI window to appropriate 0x1000 block > (if core - second, move to 0xf4001000). > Maybe we can map full window, and then access to required core without > core switching. I thought that your opinion was right and if mem is 0xf400-0xf4003fff (16 Kb) I thought the device has 4 cores. However it looks this was wrong according to the below document: http://voodoowarez.com/bcm5365p.pdf Please see Section 3: PCI Core, PCI Bus (Page 34) that it indicates that 16Kb, maybe 8 Kb in the old devices is core register region. "Accesses to the lower half of the core register region are translated into system backplane accesses using the PCIBAR0Window register" "Accesses to offsets 0x1000 to 0x17FF of this region initiate a direct access to the external SPROM" If we just access memory using offset + core and bus_space_read_x interfaces it would actually not access core register region. So without solving this problem it looks it could not remove coreswitch routines. regards, Weongyo Jeong ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CALL for TEST [HOSTAP] run(4) ralink usb wireless
On Thu, Mar 04, 2010 at 12:50:29AM -0800, PseudoCylon wrote: > Hello, > > Finally, I have fixed mysterious device lock out and run(4) works fine > in HOSTAP mode. Up time is 80 hours and counting. I even filed tax > though it. > > The device supports up to 253 stations. I only tested with 2 station. > If you have resources, please hit it with bunch of STAs. > > As usual codes are posted at my git repository > git://dev.nasreddine.com/run.git > http://dev.nasreddine.com/gitweb/?p=run.git;a=summary > Please fetch 'hostap_rc' branch not 'master' this time. > > or freebsd forums > http://forums.freebsd.org/showthread.php?s=1d3b01fbed80c61ff508e12e9805146e&t=7562 Out of curiosity, what's the difference between run(4) and rt2870 driver written by Alexander Egorenkov? And why there are two drivers? regards, Weongyo Jeong ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ndisgen on FreeBSD-9.0-CURRENT-201002-i386
On Sat, Mar 06, 2010 at 08:59:01AM +0300, Azim wrote:
> I tried ndisgen to convert BCMWL564.SYS using FreeBSD-9.0-CURRENT
> FEB-2010(x86).
> The files I had were :
> It gave an error stating BCM43XX64.CAT(unrequired),
> BCM43XX.CAT(unrequired), bcmwl5.inf and BCMWL564.SYS
>
> I had successfully compiled the 32-bit and 64-bit driver on FreeBSD 8.0
> (the 64-BIT couldn't be used on FreeBSD amd64 though)
>
> This time on FreeBSD-9.0-CURRENT while trying ndisgen the following
> files got created:
> bus_if.h
> device_if.h
> windrv.h
> and windrv.o and ndisgen echoed an error
>
> ==
> Generating Makefile... done
> Building kernel module.. "/usr/share/mk/bsd.kmod.mk", line 12: "can't
> find kernel source tree"
It looks it failed to search kernel source in standard places, for
example:
${.CURDIR}/../../kern
${.CURDIR}/../../../kern
${.CURDIR}/../../../../kern
${.CURDIR}/../../../../../kern
/sys/kern
/usr/src/sys/kern
Could you please check that one of above directories exists?
regards,
Weongyo Jeong
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Call for Test and Review: bwn(4) - another Broadcom Wireless driver
On Sat, Mar 13, 2010 at 11:12:05PM +0200, Alex RAY wrote: > On Fri, 12 Mar 2010 15:13:34 -0800 > Weongyo Jeong wrote: > > > > > I thought that your opinion was right and if mem is > > 0xf400-0xf4003fff (16 Kb) I thought the device has 4 cores. However > > it looks this was wrong according to the below document: > > > > http://voodoowarez.com/bcm5365p.pdf > > > > Please see Section 3: PCI Core, PCI Bus (Page 34) that it indicates that > > 16Kb, maybe 8 Kb in the old devices is core register region. > > > > "Accesses to the lower half of the core register region are translated > >into system backplane accesses using the PCIBAR0Window register" > > "Accesses to offsets 0x1000 to 0x17FF of this region initiate a direct > >access to the external SPROM" > > > > If we just access memory using offset + core and bus_space_read_x > > interfaces it would actually not access core register region. > > > > So without solving this problem it looks it could not remove coreswitch > > routines. > > > > regards, > > Weongyo Jeong > > > > Hi, > > this document about SoC BCM5365P, not about PCI device with PCI to SSB > bridge. Yes it's about SoC BCM5365P but I think the basic concept of Silicon Backplane would be same at a PCI device with PCI to SSB bridge. > I know in SoC`s like BSM5365 (I test it in BCM5354 and BCM5836) core > switching is not required. > > BCM5354 - > http://lists.freebsd.org/pipermail/freebsd-mips/2009-June/000421.html > BCM5836 - > http://lists.freebsd.org/pipermail/freebsd-mips/2010-February/000635.html The above URLs you mentioned indicates that siba0: at mem 0x1800-0x18006fff on nexus0 siba_cc0: at mem 0x1800-0x18000fff irq 0 on siba0 bfe0: at mem 0x18001000-0x18001fff irq 1 on siba0 siba_mips0: at mem 0x18002000-0x18002fff on siba0 ohci0: at mem 0x18003000-0x18003fff irq 4 on siba0 siba0 used memory region at starting 0x1800 that I think this is a reason why it doesn't require core switching and each cores have their own memory region at starting 0x1800. But in a case of PCI device with PCI to SSB bridge, it normally used 0xf400, 0xfe20 or other address which reserved by parent PCI bridge. > With PCI device, when device report memory window > 0xf400-0xf4003fff, why we can`t use full window? Because I'm not a Silicon Backplane expert I could not answer this question. But I'd like to make sure that memory window at 0xf400 (size 16 Kbytes) comes from PCI BAR0 when pci(4) attached device. Moreover I believe size of memory window also comes from PCI BAR0 size testing of pci(4). Of course I think we can try to remap full memory window after calculating numbers of core but it looks meaning would be little bit different. > May be You can test your code without core switching? I tried to remove core switching code in siba_bwn bridge but after moment I got stuck to go forward. For example, I have 1 device which attached with bwn(4) and it has 4 cores: 0x1800-0x18000fff ChipCommon 0x18001000-0x18001fff EMAC 0x18002000-0x18002fff PCI 0x18003000-0x18003fff PCMCIA When it attached at siba_bwn it shows its memory region at 0xfe2fe000 - 0xfe2f (8 Kbytes). Initial PCI BAR0 value was 0x18002000. If your opinion is right the memory region for full window should be 0xfe2fe000 - 0xfe301fff (16 Kb for 4 core, each core consumes 0x1000 size) Even if I tried to remap memory region from 0xfe2fe000 to 0xfe301fff and setting PCI BAR0 to 0x1800, another problem is occurred for reading SPROM data. To access external SPROM it could be possible to access bus_space_read_2(bt, bh, 0x1000 ~ 0x17ff) at ChipCommon core. But accessing register in a core could not over 0xfff because maximum size of a core limited within 0x1000. That means internally in Silicon Backplane it has a special meaning if it try to access over 0x1000 or 0x2000 which mentioned a quote at Section 3: PCI Core, PCI Bus (Page 34). I guess you're thinking that we could access EMAC core using bus_space_read_2(bt, bh, 0x1000 ~ 0x1fff) after setting full memory window. But it looks it's not possible. regards, Weongyo Jeong ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CALL for TEST [HOSTAP] run(4) ralink usb wireless
On Sat, Mar 13, 2010 at 08:36:41AM +0100, Hans Petter Selasky wrote: > On Saturday 13 March 2010 03:42:46 Rui Paulo wrote: > > On 13 Mar 2010, at 09:18, Weongyo Jeong wrote: > > > On Thu, Mar 04, 2010 at 12:50:29AM -0800, PseudoCylon wrote: > > >> Hello, > > >> > > >> Finally, I have fixed mysterious device lock out and run(4) works > > >> fine > > >> in HOSTAP mode. Up time is 80 hours and counting. I even filed tax > > >> though it. > > >> > > >> The device supports up to 253 stations. I only tested with 2 station. > > >> If you have resources, please hit it with bunch of STAs. > > >> > > >> As usual codes are posted at my git repository > > >> git://dev.nasreddine.com/run.git > > >> http://dev.nasreddine.com/gitweb/?p=run.git;a=summary > > >> Please fetch 'hostap_rc' branch not 'master' this time. > > >> > > >> or freebsd forums > > >> http://forums.freebsd.org/showthread.php?s=1d3b01fbed80c61ff508e12e98051 > > >>46e&t=7562 > > > > > > Out of curiosity, what's the difference between run(4) and rt2870 > > > driver > > > written by Alexander Egorenkov? And why there are two drivers? > > > > From what I understand, Alexander's driver supports 11n ann run(4) > > doesn't. > > Will this two drivers be merged then? I really want it and hope driver writers focus on one driver for same chipsets. :-) regards, Weongyo Jeong ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Call for Test and Review: bwn(4) - another Broadcom Wireless driver
On Mon, Mar 15, 2010 at 12:43:57AM +0200, Alex RAY wrote: > On Sat, 13 Mar 2010 16:55:58 -0800 > Weongyo Jeong wrote: > > > On Sat, Mar 13, 2010 at 11:12:05PM +0200, Alex RAY wrote: > > > On Fri, 12 Mar 2010 15:13:34 -0800 > > > Weongyo Jeong wrote: > > > > > > > > > > > I thought that your opinion was right and if mem is > > > > 0xf400-0xf4003fff (16 Kb) I thought the device has 4 cores. However > > > > it looks this was wrong according to the below document: > > > > > > > > http://voodoowarez.com/bcm5365p.pdf > > > > > > > > Please see Section 3: PCI Core, PCI Bus (Page 34) that it indicates that > > > > 16Kb, maybe 8 Kb in the old devices is core register region. > > > > > > > > "Accesses to the lower half of the core register region are translated > > > >into system backplane accesses using the PCIBAR0Window register" > > > > "Accesses to offsets 0x1000 to 0x17FF of this region initiate a direct > > > >access to the external SPROM" > > > > > > > > If we just access memory using offset + core and bus_space_read_x > > > > interfaces it would actually not access core register region. > > > > > > > > So without solving this problem it looks it could not remove coreswitch > > > > routines. > > > > > > > > regards, > > > > Weongyo Jeong > > > > > > > > > > Hi, > > > > > > this document about SoC BCM5365P, not about PCI device with PCI to SSB > > > bridge. > > > > Yes it's about SoC BCM5365P but I think the basic concept of Silicon > > Backplane would be same at a PCI device with PCI to SSB bridge. > > > > > I know in SoC`s like BSM5365 (I test it in BCM5354 and BCM5836) core > > > switching is not required. > > > > > > BCM5354 - > > > http://lists.freebsd.org/pipermail/freebsd-mips/2009-June/000421.html > > > BCM5836 - > > > http://lists.freebsd.org/pipermail/freebsd-mips/2010-February/000635.html > > > > The above URLs you mentioned indicates that > > > > siba0: at mem 0x1800-0x18006fff on > > nexus0 > > siba_cc0: at mem 0x1800-0x18000fff irq 0 on siba0 > > bfe0: at mem 0x18001000-0x18001fff irq 1 on > > siba0 > > siba_mips0: at mem 0x18002000-0x18002fff on siba0 > > ohci0: at mem 0x18003000-0x18003fff irq 4 > > on siba0 > > > > siba0 used memory region at starting 0x1800 that I think this is a > > reason why it doesn't require core switching and each cores have their > > own memory region at starting 0x1800. > > > > But in a case of PCI device with PCI to SSB bridge, it normally used > > 0xf400, 0xfe20 or other address which reserved by parent PCI > > bridge. > > > > > With PCI device, when device report memory window > > > 0xf400-0xf4003fff, why we can`t use full window? > > > > Because I'm not a Silicon Backplane expert I could not answer this > > question. But I'd like to make sure that memory window at 0xf400 > > (size 16 Kbytes) comes from PCI BAR0 when pci(4) attached device. > > Moreover I believe size of memory window also comes from PCI BAR0 size > > testing of pci(4). > > > > Of course I think we can try to remap full memory window after > > calculating numbers of core but it looks meaning would be little bit > > different. > > > > > May be You can test your code without core switching? > > > > I tried to remove core switching code in siba_bwn bridge but after > > moment I got stuck to go forward. For example, > > > > I have 1 device which attached with bwn(4) and it has 4 cores: > > > > 0x1800-0x18000fff ChipCommon > > 0x18001000-0x18001fff EMAC > > 0x18002000-0x18002fff PCI > > 0x18003000-0x18003fff PCMCIA > > > > When it attached at siba_bwn it shows its memory region at 0xfe2fe000 - > > 0xfe2f (8 Kbytes). Initial PCI BAR0 value was 0x18002000. > > Yes, You're right. I found another way. > We can use SBtoPCITranslation2 (Offset 0x108) register, in that way we > can access to SSB without coreswitching. > (Page 42) > > Initial access for copy SPROM and preconfigure make via BAR0, then > setup SBtoPCITranslation2 and access to SSB direct. According to the specification, as you mentioned SBtoPCITranslation2 has a field UpperAddress but on field 31:30. It looks 2 bit fields are too limited to use so don't know how to implement it you mentioned. Could you please elaborate or show me details? regards, Weongyo Jeong ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Call for Test and Review: bwn(4) - another Broadcom Wireless driver
On Sat, Apr 24, 2010 at 12:33:02AM +0200, Gustau P?rez wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> En/na Weongyo Jeong ha escrit:
> > On Wed, Mar 03, 2010 at 11:10:14AM +0200, Alexandr Rybalko wrote:
> >> On Wed, 3 Mar 2010 00:28:33 -0800
> >> Weongyo Jeong wrote:
> >
> I've been testing the driver for a few time with AMD64/CURRENT. A
> few time ago I started to see messages like :
>
> bwn0: unsupported rate 0
>
> I've checked the code and I found it seems to fail when trying to
> check the TX rate at if_bw.c:9561 (in bwn_ieeerate2hwrate
> routine the rate parameter is 0). I checked where bwn_ieeerate2hwrate
> is called, to see how 'rate' is calculated. This is where I got lost :(
>
> My AP is FreeBSD 8.0 box with an atheros card. My hostapd works
> with both WPA2-PSK and WPA2-EAP (although
> I thinks this is not the problem) but with default values for rates
> and friends. I then forced my hostapd to use only a subset of transmit
> rates (with supported_rates and basic_rates) with no luck.
>
> My laptop is a DELL D630 with a BCM4310 UART adapter.
>
> Any need info will be provided and any help will be appreciated.
First I think we need to know that where rate == 0 comes from. Rate
information on TX could be got from the following points:
tp->mgmtrate
tp->mcastrate
tp->ucastrate
ni->ni_txrate
Could you please test these variables to narrow this problem down?
regards,
Weongyo Jeong
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Call for Test and Review: bwn(4) - another Broadcom Wireless driver
On Fri, Apr 23, 2010 at 06:44:25PM -0500, James R. Van Artsdalen wrote: > I have a Dell Zino HD (Mac mini clone, with eSATA ports) that uses the > BCM4353 chip (called a Dell 1520 card) > > no...@pci0:2:0:0:class=0x028000 card=0x000e1028 chip=0x435314e4 > rev=0x01 hdr=0x00 > vendor = 'Broadcom Corporation' > class = network > > Should I expect this to work with to work here or try the NDIS driver? BCM4353 uses N PHY so it's not supported by bwn(4). I think NDIS driver is only a way to try currently. regards, Weongyo Jeong ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Call for Test and Review: bwn(4) - another Broadcom Wireless driver
On Sat, Apr 24, 2010 at 11:42:53PM +0800, Buganini wrote: > No luck here, it's still keeping scanning channels. > > --Buganini > > On Thu, Apr 15, 2010 at 1:34 AM, Ian FREISLICH wrote: > > Buganini wrote: > >> Hi, I got a Lenovo G450 with > >> siba_b...@pci0:4:0:0: class=0x028000 card=0x04b514e4 chip=0x431514e4 > >> rev=0x01 hdr=0x00 > >> ?? ?? vendor ?? ?? = 'Broadcom Corporation' > >> ?? ?? device ?? ?? = 'Broadcom Wireless b/g (BCM4315/BCM22062000)' > >> ?? ?? class ?? ?? ??= network > >> > >> > >> 4315 is not in supported list, but however the driver took the device > >> bwn_v4_lp_ucode.ko was not loaded automatically, so I loaded it > >> manually ifconfig scan seem freeze, I can `ifconfig list scan` later > >> and found access point correctly, but I can't associate with them, it > >> just keep scanning channels. > > > > I found that if I 'ifconfig wlan0 destroy' followed by 'ifconfig > > wlan0 create wlandev bwn0' it works. > > > > /etc/rc.conf: > > --- > > wlans_bwn0="wlan0" > > ifconfig_wlan0="WPA DHCP" > > --- > > > > The corollery is that it doesn't work first time on reboot. ??I need > > to either '/etc/rc.d/netif restart' and if that panics the machine, > > destroy wlan0 and then restart netif. > > > > Then wlan0/bwn0 associates correctly with this device. If you're a CURRENT user could you please show me the result of `netstat -ni' after updating latest CURRENT and keeping scanning channels? In LP-PHY AFAIK there's a DMA Fatal error issue which isn't solved yet. regards, Weongyo Jeong ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
about in_multi_mtx @ netinet/in_mcast.c:1095
Hello, I have a question about IN_MULTI_LOCK() because it uses MTX_DEF flag when it's initialized so I always encounters the following LOR lock order reversal: (sleepable after non-sleepable) 1st 0x80d0b560 in_multi_mtx (in_multi_mtx) @ netinet/in_mcast.c:1095 2nd 0xff00014e3850 USB device SX lock (USB device SX lock) @ /usr/home/freebsd_usb/sys/modules/usb/usb/../../../dev/usb/usb_request.c:441 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x807 _sx_xlock() at _sx_xlock+0x55 usbd_do_request_flags() at usbd_do_request_flags+0xe5 axe_cmd() at axe_cmd+0xc7 axe_setmulti_locked() at axe_setmulti_locked+0x70 axe_setmulti() at axe_setmulti+0x3e axe_ioctl() at axe_ioctl+0x132 if_addmulti() at if_addmulti+0x19b in_joingroup_locked() at in_joingroup_locked+0x1bc in_joingroup() at in_joingroup+0x52 in_control() at in_control+0x1144 ifioctl() at ifioctl+0x1118 kern_ioctl() at kern_ioctl+0xbe ioctl() at ioctl+0xfd syscallenter() at syscallenter+0x1aa syscall() at syscall+0x4c Xfast_syscall() at Xfast_syscall+0xe2 when I uses the following code at driver's ioctl routine: case SIOCADDMULTI: case SIOCDELMULTI: axe_setmulti(sc, 0); break; It means that USB driver always should defer SIOCADDMULTI / SIOCDELMULTI handling to the other process context to avoid LOR. My question is that is it safe if the multicasting operations for USB device happens without IN_MULTI_LOCK? Or is there any race cases if the task is deferred? Or is it OK like the following code? case SIOCADDMULTI: case SIOCDELMULTI: IN_MULTI_UNLOCK(); axe_setmulti(sc, 0); IN_MULTI_LOCK(); break; regards, Weongyo Jeong ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: about in_multi_mtx @ netinet/in_mcast.c:1095
On Thu, Sep 09, 2010 at 09:36:19AM -0400, John Baldwin wrote: > On Wednesday, September 08, 2010 4:14:19 pm Weongyo Jeong wrote: > > Hello, > > > > I have a question about IN_MULTI_LOCK() because it uses MTX_DEF flag > > when it's initialized so I always encounters the following LOR > > > > lock order reversal: (sleepable after non-sleepable) > > 1st 0x80d0b560 in_multi_mtx (in_multi_mtx) @ > netinet/in_mcast.c:1095 > > 2nd 0xff00014e3850 USB device SX lock (USB device SX lock) @ > /usr/home/freebsd_usb/sys/modules/usb/usb/../../../dev/usb/usb_request.c:441 > > KDB: stack backtrace: > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > > _witness_debugger() at _witness_debugger+0x2e > > witness_checkorder() at witness_checkorder+0x807 > > _sx_xlock() at _sx_xlock+0x55 > > usbd_do_request_flags() at usbd_do_request_flags+0xe5 > > axe_cmd() at axe_cmd+0xc7 > > axe_setmulti_locked() at axe_setmulti_locked+0x70 > > axe_setmulti() at axe_setmulti+0x3e > > axe_ioctl() at axe_ioctl+0x132 > > if_addmulti() at if_addmulti+0x19b > > in_joingroup_locked() at in_joingroup_locked+0x1bc > > in_joingroup() at in_joingroup+0x52 > > in_control() at in_control+0x1144 > > ifioctl() at ifioctl+0x1118 > > kern_ioctl() at kern_ioctl+0xbe > > ioctl() at ioctl+0xfd > > syscallenter() at syscallenter+0x1aa > > syscall() at syscall+0x4c > > Xfast_syscall() at Xfast_syscall+0xe2 > > > > when I uses the following code at driver's ioctl routine: > > > > case SIOCADDMULTI: > > case SIOCDELMULTI: > > axe_setmulti(sc, 0); > > break; > > > > It means that USB driver always should defer SIOCADDMULTI / > > SIOCDELMULTI handling to the other process context to avoid LOR. > > > > My question is that is it safe if the multicasting operations for USB > > device happens without IN_MULTI_LOCK? Or is there any race cases if the > > task is deferred? > > Why is USB using an sx lock instead of a mutex? Frankly speaking I also don't know why hps@ uses sx lock. That is one of things I'd like to change it. Just looking the comment at usb_reques...@441: /* * Grab the default sx-lock so that serialisation * is achieved when multiple threads are involved: */ sx_xlock(&udev->ctrl_sx); I think he might want to hold the lock even if the thread is going into sleep. It might be for serialization. However even if we succeed to change the lock from sx to mutex, it's hard to avoid the requests going into the sleep. It means USB stack should call like below: mtx_sleep(chan, IN_MULTI_LOCK, ...); to avoid the kernel's complain (would be `sleep with holding non-sleepable lock'). What I'd like to say is that the sleeping is big problem if mutex is used that it'd be worse when multiple mutex locks are used. So I'm looking for a fundamental solution to solve this problem. Welcomes any ideas. regards, Weongyo Jeong ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: about in_multi_mtx @ netinet/in_mcast.c:1095
On Thu, Sep 09, 2010 at 02:32:52PM -0400, John Baldwin wrote: > On Thursday, September 09, 2010 1:41:46 pm Weongyo Jeong wrote: > > On Thu, Sep 09, 2010 at 09:36:19AM -0400, John Baldwin wrote: > > > On Wednesday, September 08, 2010 4:14:19 pm Weongyo Jeong wrote: > > > > Hello, > > > > > > > > I have a question about IN_MULTI_LOCK() because it uses MTX_DEF flag > > > > when it's initialized so I always encounters the following LOR > > > > > > > > lock order reversal: (sleepable after non-sleepable) > > > > 1st 0x80d0b560 in_multi_mtx (in_multi_mtx) @ > > > netinet/in_mcast.c:1095 > > > > 2nd 0xff00014e3850 USB device SX lock (USB device SX lock) @ > > > > /usr/home/freebsd_usb/sys/modules/usb/usb/../../../dev/usb/usb_request.c:441 > > > > KDB: stack backtrace: > > > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > > > > _witness_debugger() at _witness_debugger+0x2e > > > > witness_checkorder() at witness_checkorder+0x807 > > > > _sx_xlock() at _sx_xlock+0x55 > > > > usbd_do_request_flags() at usbd_do_request_flags+0xe5 > > > > axe_cmd() at axe_cmd+0xc7 > > > > axe_setmulti_locked() at axe_setmulti_locked+0x70 > > > > axe_setmulti() at axe_setmulti+0x3e > > > > axe_ioctl() at axe_ioctl+0x132 > > > > if_addmulti() at if_addmulti+0x19b > > > > in_joingroup_locked() at in_joingroup_locked+0x1bc > > > > in_joingroup() at in_joingroup+0x52 > > > > in_control() at in_control+0x1144 > > > > ifioctl() at ifioctl+0x1118 > > > > kern_ioctl() at kern_ioctl+0xbe > > > > ioctl() at ioctl+0xfd > > > > syscallenter() at syscallenter+0x1aa > > > > syscall() at syscall+0x4c > > > > Xfast_syscall() at Xfast_syscall+0xe2 > > > > > > > > when I uses the following code at driver's ioctl routine: > > > > > > > > case SIOCADDMULTI: > > > > case SIOCDELMULTI: > > > > axe_setmulti(sc, 0); > > > > break; > > > > > > > > It means that USB driver always should defer SIOCADDMULTI / > > > > SIOCDELMULTI handling to the other process context to avoid LOR. > > > > > > > > My question is that is it safe if the multicasting operations for USB > > > > device happens without IN_MULTI_LOCK? Or is there any race cases if the > > > > task is deferred? > > > > > > Why is USB using an sx lock instead of a mutex? > > > > Frankly speaking I also don't know why hps@ uses sx lock. That is one > > of things I'd like to change it. > > > > Just looking the comment at usb_reques...@441: > > > > /* > > * Grab the default sx-lock so that serialisation > > * is achieved when multiple threads are involved: > > */ > > sx_xlock(&udev->ctrl_sx); > > > > I think he might want to hold the lock even if the thread is going into > > sleep. It might be for serialization. > > > > However even if we succeed to change the lock from sx to mutex, it's > > hard to avoid the requests going into the sleep. It means USB stack > > should call like below: > > > > mtx_sleep(chan, IN_MULTI_LOCK, ...); > > > > to avoid the kernel's complain (would be `sleep with holding > > non-sleepable lock'). > > > > What I'd like to say is that the sleeping is big problem if mutex is > > used that it'd be worse when multiple mutex locks are used. > > > > So I'm looking for a fundamental solution to solve this problem. > > Welcomes any ideas. > > It is probably fine to just schedule a task to do the actual work of > axe_setmulti(). I think you do not need to lock IN_MULTI_LOCK yourself in > your task handler as long as your handler holds the appropriate lock > (if_maddr_rlock() IIRC) when walking the interface's multicast address list. OK. I'll try to use a task handler for this case. One thing, just for curious. Why the lower layer (in this case it might be netinet/in_mcast.c) calls ioctl interface with holding IN_MULTI_LOCK? If it calls ioctl without holding the lock, all drivers (specially all USB drivers) which handles SIOCADDMULTI and SIOCDELMULTI don't need to implement their own taskqueue or process context. It looks to me that calling ioctl interface with holding IN_MULTI_LOCK is useless if the drivers hold if_maddr_rlock(ifp) lock properly though I could miss something important. regards, Weongyo Jeong ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: about in_multi_mtx @ netinet/in_mcast.c:1095
On Fri, Sep 10, 2010 at 05:17:39PM -0400, John Baldwin wrote: > On Friday, September 10, 2010 4:28:58 pm Weongyo Jeong wrote: > > On Thu, Sep 09, 2010 at 02:32:52PM -0400, John Baldwin wrote: > > > On Thursday, September 09, 2010 1:41:46 pm Weongyo Jeong wrote: > > > > On Thu, Sep 09, 2010 at 09:36:19AM -0400, John Baldwin wrote: > > > > > On Wednesday, September 08, 2010 4:14:19 pm Weongyo Jeong wrote: > > > > > > Hello, > > > > > > > > > > > > I have a question about IN_MULTI_LOCK() because it uses MTX_DEF flag > > > > > > when it's initialized so I always encounters the following LOR > > > > > > > > > > > > lock order reversal: (sleepable after non-sleepable) > > > > > > 1st 0x80d0b560 in_multi_mtx (in_multi_mtx) @ > > > > > netinet/in_mcast.c:1095 > > > > > > 2nd 0xff00014e3850 USB device SX lock (USB device SX lock) @ > > > > > > > > > /usr/home/freebsd_usb/sys/modules/usb/usb/../../../dev/usb/usb_request.c:441 > > > > > > KDB: stack backtrace: > > > > > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > > > > > > _witness_debugger() at _witness_debugger+0x2e > > > > > > witness_checkorder() at witness_checkorder+0x807 > > > > > > _sx_xlock() at _sx_xlock+0x55 > > > > > > usbd_do_request_flags() at usbd_do_request_flags+0xe5 > > > > > > axe_cmd() at axe_cmd+0xc7 > > > > > > axe_setmulti_locked() at axe_setmulti_locked+0x70 > > > > > > axe_setmulti() at axe_setmulti+0x3e > > > > > > axe_ioctl() at axe_ioctl+0x132 > > > > > > if_addmulti() at if_addmulti+0x19b > > > > > > in_joingroup_locked() at in_joingroup_locked+0x1bc > > > > > > in_joingroup() at in_joingroup+0x52 > > > > > > in_control() at in_control+0x1144 > > > > > > ifioctl() at ifioctl+0x1118 > > > > > > kern_ioctl() at kern_ioctl+0xbe > > > > > > ioctl() at ioctl+0xfd > > > > > > syscallenter() at syscallenter+0x1aa > > > > > > syscall() at syscall+0x4c > > > > > > Xfast_syscall() at Xfast_syscall+0xe2 > > > > > > > > > > > > when I uses the following code at driver's ioctl routine: > > > > > > > > > > > > case SIOCADDMULTI: > > > > > > case SIOCDELMULTI: > > > > > > axe_setmulti(sc, 0); > > > > > > break; > > > > > > > > > > > > It means that USB driver always should defer SIOCADDMULTI / > > > > > > SIOCDELMULTI handling to the other process context to avoid LOR. > > > > > > > > > > > > My question is that is it safe if the multicasting operations for > USB > > > > > > device happens without IN_MULTI_LOCK? Or is there any race cases > > > > > > if > the > > > > > > task is deferred? > > > > > > > > > > Why is USB using an sx lock instead of a mutex? > > > > > > > > Frankly speaking I also don't know why hps@ uses sx lock. That is one > > > > of things I'd like to change it. > > > > > > > > Just looking the comment at usb_reques...@441: > > > > > > > > /* > > > > * Grab the default sx-lock so that serialisation > > > > * is achieved when multiple threads are involved: > > > > */ > > > > sx_xlock(&udev->ctrl_sx); > > > > > > > > I think he might want to hold the lock even if the thread is going into > > > > sleep. It might be for serialization. > > > > > > > > However even if we succeed to change the lock from sx to mutex, it's > > > > hard to avoid the requests going into the sleep. It means USB stack > > > > should call like below: > > > > > > > > mtx_sleep(chan, IN_MULTI_LOCK, ...); > > > > > > > > to avoid the kernel's complain (would be `sleep with holding > > > > non-sleepable lock'). > > > > > > > > What I'd like to say is that the sleeping is big problem if mutex is > > > > used that it'd be worse when multiple mutex locks are used. > > > > > > >
Re: [RFC] Outline of USB process integration in the kernel taskqueue system
On Fri, Nov 05, 2010 at 07:30:38PM +0100, Hans Petter Selasky wrote: > Hi, > > In the patch attached to this e-mail I included Matthew Fleming's patch > aswell. > > 1) I renamed taskqueue_cancel() into taskqueue_stop(), hence that resembles > the words of the callout and USB API's terminology for doing the same. > > 2) I turns out I need to have code in subr_taskqueue.c to be able to make the > operations atomic. > > 3) I did not update the manpage in this patch. Will do that before a commit. > > 4) My patch implements separate state keeping in "struct task_pair", which > avoids having to change any KPI's for now, like suggested by John Baldwin I > think. > > 5) In my implementation I hard-coded the priority argument to zero, so that > enqueuing is fast. > > Comments are welcome! The patch looks almost you moved usb_process.c code into taskqueue(9) that I means it still follows that a entry which enqueued at last should be executed at last. It seems that at least it's not a general for taskqueue(9). In my humble opinion it looks a trick. I think it'd better to find a general solution to solve it though I used sx(9) lock in my patches. regards, Weongyo Jeong ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[CFR] a small change of ifconfig(8)
Hello all,
I'm sending this email to check whether my approach is reasonable that I
added 2 line into ifconfig(8) to skip IFT_USB interfaces as follows:
+ if (sdl != NULL && sdl->sdl_type == IFT_USB)
+ continue;
And as additionally I added two changes of USB pf to call if_up(ifp) /
if_down(ifp) explicitly to UP usbus interfaces though normally it always
should be called through user ioctl calls.
The reason why I make this patch is that I encountered a side-effect
output from ifconfig(8) after USB packet filter is committed. Yes usbus
interfaces are printed.
Please give me some hints whether the patch is reasonable. If it's
reasonable, is there other tools which I should make patches?
regards,
Weongyo Jeong
Index: sbin/ifconfig/ifconfig.c
===
--- sbin/ifconfig/ifconfig.c (revision 215648)
+++ sbin/ifconfig/ifconfig.c (working copy)
@@ -295,6 +295,8 @@
sdl = (const struct sockaddr_dl *) ifa->ifa_addr;
else
sdl = NULL;
+ if (sdl != NULL && sdl->sdl_type == IFT_USB)
+ continue;
if (cp != NULL && strcmp(cp, ifa->ifa_name) == 0 && !namesonly)
continue;
iflen = strlcpy(name, ifa->ifa_name, sizeof(name));
Index: sys/dev/usb/usb_pf.c
===
--- sys/dev/usb/usb_pf.c (revision 215812)
+++ sys/dev/usb/usb_pf.c (working copy)
@@ -65,6 +65,7 @@
ifp = ubus->ifp = if_alloc(IFT_USB);
if_initname(ifp, "usbus", device_get_unit(ubus->bdev));
if_attach(ifp);
+ if_up(ifp);
KASSERT(sizeof(struct usbpf_pkthdr) == USBPF_HDR_LEN,
("wrong USB pf header length (%zd)", sizeof(struct usbpf_pkthdr)));
@@ -86,6 +87,7 @@
if (ifp != NULL) {
bpfdetach(ifp);
+ if_down(ifp);
if_detach(ifp);
if_free(ifp);
}
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[CFR] Forward RTO recovery algorithm (rfc5682) patch
This patch is *VERY* experimental patch to implement rfc5862 which is on
the IETF standard tracks so it could be completely wrong or has a lot of
bugs on it or wrong approaches because I'm a really newbie on TCP stack.
This patch includes two features to support `Basic FRTO algorithm' and
`SACK-Enhanced FRTO algorithm' but not including a feature to support
things mentioned at `Appendix A'.
I'm looking for reviewers teaching me where it's wrong or what the
approach was bad on line by line. However any comments are welcome.
The patch is available at:
http://people.freebsd.org/~weongyo/patch_tcpfrto_20110205.diff
regards,
Weongyo Jeong
Index: netinet/tcp_input.c
===
--- netinet/tcp_input.c (revision 218148)
+++ netinet/tcp_input.c (working copy)
@@ -161,6 +161,11 @@
&VNET_NAME(tcp_abc_l_var), 2,
"Cap the max cwnd increment during slow-start to this number of segments");
+VNET_DEFINE(int, tcp_do_rfc5682) = 1;
+SYSCTL_VNET_INT(_net_inet_tcp, OID_AUTO, rfc5682, CTLFLAG_RW,
+&VNET_NAME(tcp_do_rfc5682), 0,
+"Enable RFC 5682 (Forward RTO-Recovery: F-RTO)");
+
SYSCTL_NODE(_net_inet_tcp, OID_AUTO, ecn, CTLFLAG_RW, 0, "TCP ECN");
VNET_DEFINE(int, tcp_do_ecn) = 0;
@@ -254,6 +259,212 @@
}
}
+/* revert to the conventional RTO recovery. */
+#define TCP_FRTO_REVERT(tp) do { \
+ (tp)->frto_flags = 0; \
+} while (0)
+
+static int
+tcp_frto_send2mss(struct tcpcb *tp, struct tcphdr *th, uint16_t type)
+{
+ struct inpcb *inp = tp->t_inpcb;
+ struct socket *so = inp->inp_socket;
+ u_long oldcwnd;
+ tcp_seq onxt;
+
+ /*
+ * XXXWG If the TCP sender does not have any new data to send, OR the
+ * advertised window prohibits new transmissions, the recommended
+ * action is to skip step 3 of this algorithm and continue with
+ * slow-start retransmissions, following the conventional RTO recovery
+ * algorithm. However, alternative ways of handling the window-limited
+ * cases that could result in better performance are discussed in
+ * Appendix A.
+ */
+ if (so->so_snd.sb_cc == 0 || tp->snd_wnd == 0)
+ /* XXXWG skip step 3 OR do alternative ways. */
+ return (1);
+ oldcwnd = tp->snd_cwnd;
+ onxt = tp->snd_nxt;
+ /*
+ * XXXWG transmit up to two new (previously unsent) segments and enter
+ * step 3 of this algorithm. If the TCP sender does not have enough
+ * unsent data, it can send only one segment.
+ */
+ tp->snd_cwnd = 2 * tp->t_maxseg;
+ tp->snd_nxt = tp->snd_max;
+ /*
+ * XXXWG in addition, the TCP sender MAY override the Nagle algorithm.
+ */
+ tp->t_flags |= TF_ACKNOW;
+ (void) tcp_output(tp);
+ tp->snd_nxt = onxt;
+ tp->snd_cwnd = oldcwnd;
+ return (0);
+}
+
+static void inline
+tcp_frto_ack_received(struct tcpcb *tp, struct tcphdr *th, uint16_t type)
+{
+
+ /* SACK-Enhanced F-RTO */
+
+ if (tp->t_flags & TF_SACK_PERMIT) {
+ if ((tp->frto_flags & FRTO_INSTEP1) != 0 &&
+ (tp->frto_flags & FRTO_CANGOSTEP2) != 0) {
+ /* SACK-Enhanced F-RTO - step 2 */
+ if (type == CC_DUPACK)
+/*
+ * 2) If duplicate ACKs arrive before the
+ * cumulative acknowledgment for retransmitted
+ * data, adjust the scoreboard according to
+ * the incoming SACK information. Stay in
+ * step 2 and wait for the next new
+ * acknowledgment.
+ */
+return;
+ KASSERT(type == CC_ACK,
+ ("%s: expected ACK (but %d)", __func__, type));
+
+ /*
+ * 2) When a new acknowledgment arrives, set variable
+ * "RecoveryPoint" to indicate the highest sequence
+ * number transmitted so far.
+ */
+ tp->frto_flags |= FRTO_INSTEP2;
+ tp->snd_recover = tp->snd_max;
+
+ /*
+ * 2a) If the Cumulative Acknowledgement field covers
+ * "RecoveryPoint" but not more than
+ * "RecoveryPoint", revert to the conventional RTO
+ * recovery and set the congestion window to no
+ * more than 2 * MSS, like a regular TCP would do.
+ * Do not enter step 3 of this algorithm.
+ */
+ if (th->th_ack == tp->snd_recover) {
+tp->snd_cwnd = 2 * tp->t_maxseg;
+TCP_FRTO_REVERT(tp);
+return;
+ /*
+ * 2b) If the Cumulative Acknowledgment field does not
+ * cover "RecoveryPoint" but is larger than
+ * SND.UNA.
+ */
+ } else if (SEQ_LT(th->th_ack, tp->snd_recover) &&
+ SEQ_GT(th->th_ack, tp->snd_una) &&
+ !tcp_frto_send2mss(tp, th, type)) {
+tp->frto_flags |= FRTO_CANGOSTEP3;
+tp->frto_fack = tp->snd_fack;
+ }
+ }
+ if ((tp->frto_flags & FRTO_INSTEP2) != 0 &&
+ (tp->frto_flags & FRTO_CANGOSTEP3) != 0) {
+ struct sackhole *q = TAILQ_FIRST(&tp->snd_holes);
+ /* the Cumulative Acknowledgment */
+ tcp_seq cack = SEQ_MAX(th->th_ack, tp->snd_una);
+
+ /*
Re: Call for Test and Review: bwn(4) - another Broadcom Wireless driver
On Sun, Apr 25, 2010 at 10:42:16PM +0200, Gustau P?rez wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>
> >> I've been testing the driver for a few time with AMD64/CURRENT. A
> >> few time ago I started to see messages like :
> >>
> >> bwn0: unsupported rate 0
> >>
> >> I've checked the code and I found it seems to fail when trying to
> >> check the TX rate at if_bw.c:9561 (in bwn_ieeerate2hwrate
> >> routine the rate parameter is 0). I checked where bwn_ieeerate2hwrate
> >> is called, to see how 'rate' is calculated. This is where I got lost :(
> >>
> >> My AP is FreeBSD 8.0 box with an atheros card. My hostapd works
> >> with both WPA2-PSK and WPA2-EAP (although
> >> I thinks this is not the problem) but with default values for rates
> >> and friends. I then forced my hostapd to use only a subset of transmit
> >> rates (with supported_rates and basic_rates) with no luck.
> >>
> >> My laptop is a DELL D630 with a BCM4310 UART adapter.
> >>
> >> Any need info will be provided and any help will be appreciated.
> >
> > First I think we need to know that where rate == 0 comes from. Rate
> > information on TX could be got from the following points:
> >
> > tp->mgmtrate
> > tp->mcastrate
> > tp->ucastrate
> > ni->ni_txrate
> >
> Added some device_printf to test those values. This is what I got :
>
> bwn0: tp->mgmtrate : 2
> bwn0: tp->mcastrate : 2
> bwn0: tp->ucastrate : 255
> bwn0: ni->ni_txrate : 0
>
>I didn't have time to follow the code to find out why it has a 0
> value. If you need
> more info let me know.
Hello Gustau, I'm so sorry for belated response that I had no time to
read and work email and wireless stuffs.
Could you please test this symptom with attached patch? It looks in
CURRENT it missed to initialize a ratectl when it associates with AP.
regards,
Weongyo Jeong
Index: if_bwn.c
===
--- if_bwn.c (revision 207481)
+++ if_bwn.c (working copy)
@@ -8329,6 +8329,7 @@
static int
bwn_newstate(struct ieee80211vap *vap, enum ieee80211_state nstate, int arg)
{
+ const struct ieee80211_txparam *tp;
struct bwn_vap *bvp = BWN_VAP(vap);
struct ieee80211com *ic= vap->iv_ic;
struct ifnet *ifp = ic->ic_ifp;
@@ -8377,6 +8378,11 @@
bwn_set_pretbtt(mac);
bwn_spu_setdelay(mac, 0);
bwn_set_macaddr(mac);
+
+ /* Initializes ratectl for a node. */
+ tp = &vap->iv_txparms[ieee80211_chan2mode(ic->ic_curchan)];
+ if (tp->ucastrate == IEEE80211_FIXED_RATE_NONE)
+ ieee80211_ratectl_node_init(vap->iv_bss);
}
BWN_UNLOCK(sc);
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
a panic on uart_z8530_class?
Hello, Anyone encountered this panic on recent CURRENT kernel? [r...@test ~]# uname -a FreeBSD test 9.0-CURRENT FreeBSD 9.0-CURRENT #16: Sun May 2 00:24:12 PDT 2010 r...@test:/usr/obj/usr/src/sys/GENERIC amd64 [r...@test /home/freebsd/sys/modules/bwn]# ifconfig wlan0 create wlandev bwn0 Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x0 fault code = supervisor read instruction, page not present instruction pointer = 0x20:0x0 stack pointer = 0x28:0xff8073cdd810 frame pointer = 0x28:0xff8073cdd8e0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 1795 (ifconfig) [ thread pid 1795 tid 100096 ] Stopped at 0: *** error reading from address 0 *** db> bt Tracing pid 1795 tid 100096 td 0xff0003d8b390 uart_z8530_class() at 0 ifc_simple_create() at ifc_simple_create+0x89 if_clone_createif() at if_clone_createif+0x64 ifioctl() at ifioctl+0x685 kern_ioctl() at kern_ioctl+0xc5 ioctl() at ioctl+0xfd syscall() at syscall+0x102 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x800b86d0c, rsp = 0x7fffe2e8, rbp = 0x7fffee36 --- db> call doadump Physical memory: 3916 MB Dumping 1239 MB: 1224 1208 1192 1176 1160 1144 1128 1112 1096 1080 1064 1048 1032 1016 1000 984 968 952 936 920 904 888 872 856 840 824 808 792 776 760 744 728 712 696 680 664 648 632 616 600 584 568 552 536 520 504 488 472 456 440 424 408 392 376 360 344 328 312 296 280 264 248 232 216 200 184 168 152 136 120 104 88 72 56 40 24 8 Dump complete = 0 db> reset [r...@test ~]# kgdb /boot/kernel/kernel /var/crash/vmcore.1 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Cannot access memory at address 0xff0127e0 (kgdb) bt #0 0x in ?? () Cannot access memory at address 0x0 (kgdb) q regards, Weongyo Jeong ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Call for Test and Review: bwn(4) - another Broadcom Wireless driver
On Fri, May 07, 2010 at 06:08:05PM +0200, Gustavo Perez Querol wrote: > > > > > Hello Gustau, I'm so sorry for belated response that I had no time to > > read and work email and wireless stuffs. > > > > Could you please test this symptom with attached patch? It looks in > > CURRENT it missed to initialize a ratectl when it associates with AP. > > > > The patch made the machine to panic. I think it happened when launching > the supplicant. In fact, right now it works by putting the RF switch to > OFF. As soon as I change it to ON the machine panics. > > It get a trap 12, with two reasons : page fault and "bufwrite, buffer is > not busy?" > > I'm running 9.0/AMD64 from 1 of May (don't know exact svn revision). > > Do you want me to test anything else ? Please give me some time to prepare another patch. My machine encountered another problem which looks related with serial console so I can not test my patch due to kernel panic. regards, Weongyo Jeong ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Call for Test and Review: bwn(4) - another Broadcom Wireless driver
On Thu, May 06, 2010 at 10:27:31PM +0200, Attilio Rao wrote: > 2010/5/6 Weongyo Jeong : > > On Sun, Apr 25, 2010 at 10:42:16PM +0200, Gustau P?rez wrote: > >> -BEGIN PGP SIGNED MESSAGE- > >> Hash: SHA1 > >> > >> > >> >> I've been testing the driver for a few time with AMD64/CURRENT. A > >> >> few time ago I started to see messages like : > >> >> > >> >> bwn0: unsupported rate 0 > >> >> > >> >> I've checked the code and I found it seems to fail when trying to > >> >> check the TX rate at if_bw.c:9561 (in bwn_ieeerate2hwrate > >> >> routine the rate parameter is 0). I checked where bwn_ieeerate2hwrate > >> >> is called, to see how 'rate' is calculated. This is where I got lost :( > >> >> > >> >> My AP is FreeBSD 8.0 box with an atheros card. My hostapd works > >> >> with both WPA2-PSK and WPA2-EAP (although > >> >> I thinks this is not the problem) but with default values for rates > >> >> and friends. I then forced my hostapd to use only a subset of transmit > >> >> rates (with supported_rates and basic_rates) with no luck. > >> >> > >> >> My laptop is a DELL D630 with a BCM4310 UART adapter. > >> >> > >> >> Any need info will be provided and any help will be appreciated. > >> > > >> > First I think we need to know that where rate == 0 comes from. ??Rate > >> > information on TX could be got from the following points: > >> > > >> > ?? ?? tp->mgmtrate > >> > ?? ?? tp->mcastrate > >> > ?? ?? tp->ucastrate > >> > ?? ?? ni->ni_txrate > >> > > >> ?? Added some device_printf to test those values. This is what I got : > >> > >> bwn0: tp->mgmtrate : 2 > >> bwn0: tp->mcastrate : 2 > >> bwn0: tp->ucastrate : 255 > >> bwn0: ni->ni_txrate : 0 > >> > >> ?? ??I didn't have time to follow the code to find out why it has a 0 > >> value. If you need > >> more info let me know. > > > > Hello Gustau, I'm so sorry for belated response that I had no time to > > read and work email and wireless stuffs. > > > > Could you please test this symptom with attached patch? ??It looks in > > CURRENT it missed to initialize a ratectl when it associates with AP. > > Hello, > I have another problem where the bwn is fully recognized and wlan0 is > created but the interface doesn't scan at all: > > # netstat -nil > Name Mtu Network Address Ipkts Ierrs Idrop > Opkts Oerrs Coll > bwn0 2290 00:26:5e:64:be:750 0 0 >0 0 0 > > # ifconfig wlan0 > wlan0: flags=8843 metric 0 mtu 1500 > ether 00:26:5e:64:be:75 > media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) > status: no carrier > ssid "" channel 1 (2412 MHz 11b) > country US authmode OPEN privacy OFF txpower 30 bmiss 7 scanvalid 60 > bgscan bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 1 wme > bintval 0 > > # kldstat > Id Refs AddressSize Name > 14 0x8010 90b9a8 kernel > 21 0x80c22000 28a9abwn_v4_ucode.ko > > doing "ifconfig wlan0 list scan" ends up immediately without further output. > The dmesg is here: http://www.freebsd.org/~attilio/dmesg-bwn0.diff > > Sorry for not digging further. It looks the interface isn't scanning. Could you please try to UP the device manually as the below after boot? # ifconfig wlan0 create wlandev bwn0 # ifconfig wlan0 ssid # ifconfig wlan0 up # ifconfig wlan0 list scan regards, Weongyo Jeong ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Call for Test and Review: bwn(4) - another Broadcom Wireless driver
On Fri, May 07, 2010 at 06:08:05PM +0200, Gustavo Perez Querol wrote:
>
> >
> > Hello Gustau, I'm so sorry for belated response that I had no time to
> > read and work email and wireless stuffs.
> >
> > Could you please test this symptom with attached patch? It looks in
> > CURRENT it missed to initialize a ratectl when it associates with AP.
> >
>
> The patch made the machine to panic. I think it happened when launching
> the supplicant. In fact, right now it works by putting the RF switch to
> OFF. As soon as I change it to ON the machine panics.
>
> It get a trap 12, with two reasons : page fault and "bufwrite, buffer is
> not busy?"
>
> I'm running 9.0/AMD64 from 1 of May (don't know exact svn revision).
>
> Do you want me to test anything else ?
OK. The patch is ready to test. Could you please test it with attached
patch?
regards,
Weongyo Jeong
Index: if_bwn.c
===
--- if_bwn.c (revision 207881)
+++ if_bwn.c (working copy)
@@ -8329,6 +8329,7 @@
static int
bwn_newstate(struct ieee80211vap *vap, enum ieee80211_state nstate, int arg)
{
+ const struct ieee80211_txparam *tp;
struct bwn_vap *bvp = BWN_VAP(vap);
struct ieee80211com *ic= vap->iv_ic;
struct ifnet *ifp = ic->ic_ifp;
@@ -8377,6 +8378,11 @@
bwn_set_pretbtt(mac);
bwn_spu_setdelay(mac, 0);
bwn_set_macaddr(mac);
+
+ /* Initializes ratectl for a node. */
+ tp = &vap->iv_txparms[ieee80211_chan2mode(ic->ic_curchan)];
+ if (tp->ucastrate == IEEE80211_FIXED_RATE_NONE)
+ ieee80211_ratectl_node_init(vap->iv_bss);
}
BWN_UNLOCK(sc);
@@ -8994,7 +9000,7 @@
struct bwn_stats *stats = &mac->mac_stats;
struct ieee80211_node *ni;
struct ieee80211vap *vap;
- int slot;
+ int retrycnt = 0, slot;
BWN_ASSERT_LOCKED(mac->mac_sc);
@@ -9027,7 +9033,7 @@
status->ack ?
IEEE80211_RATECTL_TX_SUCCESS :
IEEE80211_RATECTL_TX_FAILURE,
- NULL, 0);
+ &retrycnt, 0);
break;
}
slot = bwn_dma_nextslot(dr, slot);
@@ -9048,7 +9054,7 @@
status->ack ?
IEEE80211_RATECTL_TX_SUCCESS :
IEEE80211_RATECTL_TX_FAILURE,
- NULL, 0);
+ &retrycnt, 0);
}
bwn_pio_handle_txeof(mac, status);
}
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Call for Test and Review: bwn(4) - another Broadcom Wireless driver
On Sat, May 15, 2010 at 05:02:42PM +0200, Gustau P??rez wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > En/na Weongyo Jeong ha escrit: > > On Fri, May 07, 2010 at 06:08:05PM +0200, Gustavo Perez Querol wrote: > >>> Hello Gustau, I'm so sorry for belated response that I had no time to > >>> read and work email and wireless stuffs. > >>> > >>> Could you please test this symptom with attached patch? It looks in > >>> CURRENT it missed to initialize a ratectl when it associates with AP. > >>> > >> The patch made the machine to panic. I think it happened when launching > >> the supplicant. In fact, right now it works by putting the RF switch to > >> OFF. As soon as I change it to ON the machine panics. > >> > >> It get a trap 12, with two reasons : page fault and "bufwrite, buffer is > >> not busy?" > >> > >> I'm running 9.0/AMD64 from 1 of May (don't know exact svn revision). > >> > >> Do you want me to test anything else ? > > > > OK. The patch is ready to test. Could you please test it with attached > > patch? > > > > regards, > > Weongyo Jeong > > > >It worked fine with current. I still haven't tested it a few hours, > let's see if it works. Thanks ! > >However, right now I'm testing zfs with the same laptop (with a > different HDD) and unfortunately I'm seeing the same with STABLE. > Tons of : > > "bwn0: unsupported rate 0" > >I wonder if the patch you sent will work with stable's source code ... Recently the ratectl framwork was MFC to STABLE_8 so it could cause this problem. I'll MFC my patch to STABLE_8 as soon as possible. regards, Weongyo Jeong ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Call for Test and Review: bwn(4) - another Broadcom Wireless driver
On Tue, May 11, 2010 at 10:04:34AM +0200, Ian FREISLICH wrote: > Ian FREISLICH wrote: > > Weongyo Jeong wrote: > > > > Do you want me to test anything else ? > > > > > > OK. The patch is ready to test. Could you please test it with attached > > > patch? > > > > No panic this time. I also don't get these messages any more: > > > > May 10 23:25:36 mini kernel: bwn0: unsupported rate 0 > > May 10 23:26:13 mini last message repeated 2 times > > May 10 23:28:29 mini last message repeated 320 times > > May 10 23:28:32 mini last message repeated 61 times > > May 10 23:29:42 mini shutdown: reboot by ianf: > > > > It still doesn't associate with my AP until I destroy the wlan > > interface and create it again: > > But, after about 12 hours it reduced the rate to 36mbit/s OFDM with > large amounts of time either not transmitting or not recieving - > 86% packet loss over 5 minutes. The rate change to 36 MBit/s is a normal operation depending on the rate control algorithm. But the packet loss could be a problem so I think we need to narrow down this issue why this happens. regards, Weongyo Jeong ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Call for Test and Review: bwn(4) - another Broadcom Wireless driver
On Mon, May 10, 2010 at 11:41:34PM +0200, Ian FREISLICH wrote: > Weongyo Jeong wrote: > > > Do you want me to test anything else ? > > > > OK. The patch is ready to test. Could you please test it with attached > > patch? > > No panic this time. I also don't get these messages any more: > > May 10 23:25:36 mini kernel: bwn0: unsupported rate 0 > May 10 23:26:13 mini last message repeated 2 times > May 10 23:28:29 mini last message repeated 320 times > May 10 23:28:32 mini last message repeated 61 times > May 10 23:29:42 mini shutdown: reboot by ianf: > > It still doesn't associate with my AP until I destroy the wlan > interface and create it again: Could you please show me your setup and steps you did? It would be helpful if you give me a typescript file using script(1). regards, Weongyo Jeong ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Call for Test and Review: bwn(4) - another Broadcom Wireless driver
On Thu, May 20, 2010 at 05:04:51PM +0200, Gustau P??rez wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > En/na Weongyo Jeong ha escrit: > > On Fri, May 07, 2010 at 06:08:05PM +0200, Gustavo Perez Querol wrote: > >>> Hello Gustau, I'm so sorry for belated response that I had no time to > >>> read and work email and wireless stuffs. > >>> > >>> Could you please test this symptom with attached patch? It looks in > >>> CURRENT it missed to initialize a ratectl when it associates with AP. > >>> > >> The patch made the machine to panic. I think it happened when launching > >> the supplicant. In fact, right now it works by putting the RF switch to > >> OFF. As soon as I change it to ON the machine panics. > >> > >> It get a trap 12, with two reasons : page fault and "bufwrite, buffer is > >> not busy?" > >> > >> I'm running 9.0/AMD64 from 1 of May (don't know exact svn revision). > >> > >> Do you want me to test anything else ? > > > > OK. The patch is ready to test. Could you please test it with attached > > patch? > > > > regards, > > Weongyo Jeong > > >I've just updated to FreeBSD 8.1 PRERELEASE and I see the > unsupported rate problem again. I applied the patch for CURRENT and it > works. So I guess the patch was not MFC in the 8.1 branch. It's MFCed today. >However it still works slow (betwenn 200 and 300 kbytes/s). I tried > using a rum dongle with the same AP (which is a 8.0-STABLE system with > an Atheros card) and works great when uploading (2Mb sustained). Umm. I have no clue why this is happened currently. When I found any hints I'll let you know. Thank you. > In my laptop I see now messages like these : > > bwn0: RX decryption attempted (old 0 keyidx 0x1) You could ignore this messages because bwn(4) doesn't support H/W crypto and it looks it's harmless. >If you want me to try anything, let me know. Regards, Weongyo Jeong ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[CFT] Forward RTO recovery algorithm (rfc5682) patch
Hello, I sent a email to current@ two months ago about F-RTO patch CFR but didn't get proper feedbacks from yours. And at now two months later, I have prepared my final code for F-RTO patch and checked it's working for SACK enabled and disabled environments: http://people.freebsd.org/~weongyo/rfc5682/ The above links include some graphs before and after applying RFC5682 patch and a patch I prepared. If no objections I'd like to commit it into HEAD and still welcomes your opinions and reviews. If you have any concerns and questions please let me know. regards, Weongyo Jeong ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[CFT] Early Retransmit for TCP (rfc5827) patch
Hello all, I'd like to send another patch to support RFC5827 in TCP stack which could be found at: http://people.freebsd.org/~weongyo/patch_20110506_rfc5827.diff This patch supports all Early Retransmit logics (Byte-Based Early Retransmit and Segment-Based Early Retransmit) when net.inet.tcp.rfc5827 sysctl knob is turned on. Please note that Segment-Based Early Retransmit logic is separated using khelp module because it adds additional operations and requires variable spaces to track segment boundaries on the right side window. So if the khelp module is loaded, it's a preference but if not the default logic is `Byte-Based Early Retransmit'. I implemented based on DragonflyBSD's implementation but it looked it's not same with RFC specification what I thought so I changed most of parts. In my test environments it looks it's working correctly. Please review and test my work and tell me if you have any concerns and questions. regards, Weongyo Jeong Index: usr.bin/netstat/inet.c === --- usr.bin/netstat/inet.c (revision 221564) +++ usr.bin/netstat/inet.c (working copy) @@ -622,6 +622,7 @@ "\t\t%lu data packet%s (%lu byte%s) retransmitted\n"); p(tcps_sndrexmitbad, "\t\t%lu data packet%s unnecessarily retransmitted\n"); + p(tcps_sndearlyrexmit, "\t%lu packet%s early retransmitted\n"); p(tcps_mturesent, "\t\t%lu resend%s initiated by MTU discovery\n"); p2a(tcps_sndacks, tcps_delack, "\t\t%lu ack-only packet%s (%lu delayed)\n"); Index: share/man/man4/Makefile === --- share/man/man4/Makefile (revision 221564) +++ share/man/man4/Makefile (working copy) @@ -140,6 +140,7 @@ gpib.4 \ gre.4 \ h_ertt.4 \ + h_tcper.4 \ harp.4 \ hatm.4 \ hfa.4 \ Index: share/man/man4/h_tcper.4 === --- share/man/man4/h_tcper.4 (revision 0) +++ share/man/man4/h_tcper.4 (revision 0) @@ -0,0 +1,60 @@ +.\" +.\" Copyright (c) 2011 Weongyo Jeong +.\" All rights reserved. +.\" +.\" Redistribution and use in source and binary forms, with or without +.\" modification, are permitted provided that the following conditions +.\" are met: +.\" 1. Redistributions of source code must retain the above copyright +.\"notice, this list of conditions and the following disclaimer. +.\" 2. Redistributions in binary form must reproduce the above copyright +.\"notice, this list of conditions and the following disclaimer in the +.\"documentation and/or other materials provided with the distribution. +.\" +.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND +.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE +.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE +.\" ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE FOR +.\" ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL +.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS +.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) +.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT +.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY +.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF +.\" SUCH DAMAGE. +.\" +.\" $FreeBSD: share/man/man4/h_ertt.4 218912 2011-02-21 11:56:11Z lstewart $ +.\" +.Dd May 4, 2011 +.Dt h_tcper 9 +.Os +.Sh NAME +.Nm h_tcper +.Nd Segment Boundary Tracker Khelp module +.Sh SYNOPSIS +.In netinet/khelp/h_tcper.h +.Sh DESCRIPTION +The +.Nm +Khelp module works within the +.Xr khelp 9 +framework to provide TCP with a per-connection, segment boundary tracker. +It's to form an understanding as to how many actual segments have been +transmitted, but not acknowledged. +Its implementation is done by the sender by tracking the boundaries of +the four segments on the right side of the current window. +.Sh SEE ALSO +.Xr hhook 9 , +.Xr khelp 9 +.Sh HISTORY +The +.Nm +module first appeared in +.Fx 9.0 . +The module was first released in 2011 by Weongyo Jeong +.Sh AUTHORS +.An -nosplit +The +.Nm +Khelp module and this manual page were written by +.An Weongyo Jeong Aq weon...@freebsd.org . Index: sys/netinet/tcp_input.c === --- sys/netinet/tcp_input.c (revision 221564) +++ sys/netinet/tcp_input.c (working copy) @@ -55,6 +55,7 @@ #include #include #include +#include #include #include #include /* for proc0 declaration */ @@ -101,6 +102,7 @@ #ifdef TCPDEBUG #include #endif /* TCPDEBUG */ +#include #ifdef IPSEC #includ
