From mav at FreeBSD.org  Sun Feb  1 02:07:59 2009
From: mav at FreeBSD.org (Alexander Motin)
Date: Sun Feb  1 02:08:06 2009
Subject: Problem about the new sdhci driver
In-Reply-To: <53a1e0710901311949x3b853404oe89cf2ae9a0903f7@mail.gmail.com>
References: <53a1e0710901311949x3b853404oe89cf2ae9a0903f7@mail.gmail.com>
Message-ID: <49857482.5080508@FreeBSD.org>

Henry Hu wrote:
> I'm using FreeBSD 7-STABLE, with sdhci driver
> sdhci.20081029.tgz
> mmc.20081029.tgz
> 
> I've found that if I load sdhci driver with card inserted, everything
> works fine.
> But if I load sdhci driver first, and then insert card, the card is
> not detected.Additionally, there is no interrupt.
> After I've load sdhci driver without card, the controller seems to be
> in a problematic state. The register dump outputed when the driver
> loaded showed that Present is 0x01f20000 which is correct since the
> card is not inserted then. But cards is not detected.
> Even if I unload the driver and reload with card inserted, the card
> still cannot be detected, and there's no interrupt. But the Present
> register changed to 0x01fa0000 which is strange.
> 
> So I guess there's something wrong with the driver when the card is not present.
> 
> sdhci0: <RICOH R5C822 SD> mem 0xf0401000-0xf04010ff irq 18 at device 9.1 on pci5
> sdhci0-slot0: 33MHz 4bits 3.3V DMA
> sdhci0-slot0: ============== REGISTER DUMP ==============
> sdhci0-slot0: Sys addr: 0x00000000 | Version:  0x00000200
> sdhci0-slot0: Blk size: 0x00000000 | Blk cnt:  0x00000000
> sdhci0-slot0: Argument: 0x00000000 | Trn mode: 0x00000000
> sdhci0-slot0: Present:  0x01f20000 | Host ctl: 0x00000000
> sdhci0-slot0: Power:    0x00000000 | Blk gap:  0x00000000
> sdhci0-slot0: Wake-up:  0x00000000 | Clock:    0x00000000
> sdhci0-slot0: Timeout:  0x0000000c | Int stat: 0x00000000
> sdhci0-slot0: Int enab: 0x01ff00fb | Sig enab: 0x01ff00fb
> sdhci0-slot0: AC12 err: 0x00000000 | Slot int: 0x00000000
> sdhci0-slot0: Caps:     0x01c021a1 | Max curr: 0x00000040
> sdhci0-slot0: ===========================================

Try this patch please:
--- sdhci.c.prev        2009-01-29 00:53:41.000000000 +0200
+++ sdhci.c     2009-02-01 11:58:42.000000000 +0200
@@ -82,7 +82,8 @@ static const struct sdhci_device {
         u_int           quirks;
  } sdhci_devices[] = {
         { 0x08221180,   0xffff, "RICOH R5C822 SD",
-           SDHCI_QUIRK_FORCE_DMA },
+           SDHCI_QUIRK_FORCE_DMA |
+           SDHCI_QUIRK_NO_CARD_NO_RESET },
         { 0x8034104c,   0xffff, "TI XX21/XX11 SD",
             SDHCI_QUIRK_FORCE_DMA },
         { 0x05501524,   0xffff, "ENE CB712 SD",


Could everybody having this controller send me pciconf and Version 
register from their controller and report me is this bug present on 
their system? I would like to collect some statistics.

-- 
Alexander Motin
From henry.hu.sh at gmail.com  Sun Feb  1 04:32:28 2009
From: henry.hu.sh at gmail.com (Henry Hu)
Date: Sun Feb  1 04:32:35 2009
Subject: Problem about the new sdhci driver
In-Reply-To: <49857482.5080508@FreeBSD.org>
References: <53a1e0710901311949x3b853404oe89cf2ae9a0903f7@mail.gmail.com>
	<49857482.5080508@FreeBSD.org>
Message-ID: <53a1e0710902010432j49111ecey8d9a93acfbe3c64d@mail.gmail.com>

After doing more experiments, I found the cause:
hw.pci.do_power_resume=3
If I set it to 0 and load the driver, it works well with and without the card.
If I set it to 3 and load the driver, then
1. If the card is present, then it would detect the card and the disk
shows up. If I remove the card and insert it again, it cannot detect
it again. And if I unload the driver now and reload it with the card,
it cannot detect the card and it cannot detect card insertion /
removal.
2. If the card is not present, then it cannot detect the card, and if
I remove the card and insert it again, nothing happens.
The 0x01fa0000 state is normal: I found that the detection of
write-protection is independent from card detection. If I pull the
card out completely, the present register is 0x01f20000. If I pull the
card out half-way, the present register is 0x01fa000, the
write-protection bit is 1 and the card-present bit is 0...

So the problem is about power states, not the driver, and no patch is
needed. Since I rarely use the card reader when the laptop is using
battery, I decided to remove it from sysctl .conf ....
Thanks for the help. Good driver!

Cheers,
Henry

On Sun, Feb 1, 2009 at 6:08 PM, Alexander Motin <mav@freebsd.org> wrote:
> Henry Hu wrote:
>>
>> I'm using FreeBSD 7-STABLE, with sdhci driver
>> sdhci.20081029.tgz
>> mmc.20081029.tgz
>>
>> I've found that if I load sdhci driver with card inserted, everything
>> works fine.
>> But if I load sdhci driver first, and then insert card, the card is
>> not detected.Additionally, there is no interrupt.
>> After I've load sdhci driver without card, the controller seems to be
>> in a problematic state. The register dump outputed when the driver
>> loaded showed that Present is 0x01f20000 which is correct since the
>> card is not inserted then. But cards is not detected.
>> Even if I unload the driver and reload with card inserted, the card
>> still cannot be detected, and there's no interrupt. But the Present
>> register changed to 0x01fa0000 which is strange.
>>
>> So I guess there's something wrong with the driver when the card is not
>> present.
>>
>> sdhci0: <RICOH R5C822 SD> mem 0xf0401000-0xf04010ff irq 18 at device 9.1
>> on pci5
>> sdhci0-slot0: 33MHz 4bits 3.3V DMA
>> sdhci0-slot0: ============== REGISTER DUMP ==============
>> sdhci0-slot0: Sys addr: 0x00000000 | Version:  0x00000200
>> sdhci0-slot0: Blk size: 0x00000000 | Blk cnt:  0x00000000
>> sdhci0-slot0: Argument: 0x00000000 | Trn mode: 0x00000000
>> sdhci0-slot0: Present:  0x01f20000 | Host ctl: 0x00000000
>> sdhci0-slot0: Power:    0x00000000 | Blk gap:  0x00000000
>> sdhci0-slot0: Wake-up:  0x00000000 | Clock:    0x00000000
>> sdhci0-slot0: Timeout:  0x0000000c | Int stat: 0x00000000
>> sdhci0-slot0: Int enab: 0x01ff00fb | Sig enab: 0x01ff00fb
>> sdhci0-slot0: AC12 err: 0x00000000 | Slot int: 0x00000000
>> sdhci0-slot0: Caps:     0x01c021a1 | Max curr: 0x00000040
>> sdhci0-slot0: ===========================================
>
> Try this patch please:
> --- sdhci.c.prev        2009-01-29 00:53:41.000000000 +0200
> +++ sdhci.c     2009-02-01 11:58:42.000000000 +0200
> @@ -82,7 +82,8 @@ static const struct sdhci_device {
>        u_int           quirks;
>  } sdhci_devices[] = {
>        { 0x08221180,   0xffff, "RICOH R5C822 SD",
> -           SDHCI_QUIRK_FORCE_DMA },
> +           SDHCI_QUIRK_FORCE_DMA |
> +           SDHCI_QUIRK_NO_CARD_NO_RESET },
>        { 0x8034104c,   0xffff, "TI XX21/XX11 SD",
>            SDHCI_QUIRK_FORCE_DMA },
>        { 0x05501524,   0xffff, "ENE CB712 SD",
>
>
> Could everybody having this controller send me pciconf and Version register
> from their controller and report me is this bug present on their system? I
> would like to collect some statistics.
>
> --
> Alexander Motin
> _______________________________________________
> freebsd-mobile@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-mobile
> To unsubscribe, send any mail to "freebsd-mobile-unsubscribe@freebsd.org"
>
From mav at FreeBSD.org  Sun Feb  1 10:31:45 2009
From: mav at FreeBSD.org (Alexander Motin)
Date: Sun Feb  1 10:31:52 2009
Subject: Problem about the new sdhci driver
In-Reply-To: <53a1e0710902010432j49111ecey8d9a93acfbe3c64d@mail.gmail.com>
References: <53a1e0710901311949x3b853404oe89cf2ae9a0903f7@mail.gmail.com>	
	<49857482.5080508@FreeBSD.org>
	<53a1e0710902010432j49111ecey8d9a93acfbe3c64d@mail.gmail.com>
Message-ID: <4985EA94.1090007@FreeBSD.org>

Henry Hu wrote:
> After doing more experiments, I found the cause:
> hw.pci.do_power_resume=3
> If I set it to 0 and load the driver, it works well with and without the card.
> If I set it to 3 and load the driver, then
> 1. If the card is present, then it would detect the card and the disk
> shows up. If I remove the card and insert it again, it cannot detect
> it again. And if I unload the driver now and reload it with the card,
> it cannot detect the card and it cannot detect card insertion /
> removal.
> 2. If the card is not present, then it cannot detect the card, and if
> I remove the card and insert it again, nothing happens.
> The 0x01fa0000 state is normal: I found that the detection of
> write-protection is independent from card detection. If I pull the
> card out completely, the present register is 0x01f20000. If I pull the
> card out half-way, the present register is 0x01fa000, the
> write-protection bit is 1 and the card-present bit is 0...
> 
> So the problem is about power states, not the driver, and no patch is
> needed. Since I rarely use the card reader when the laptop is using
> battery, I decided to remove it from sysctl .conf ....
> Thanks for the help. Good driver!

And still it would be good to try the patch. Some revisions of this 
controller known behave wrong if being reseted without card inserted. 
This patch enables special quirk to avoid that situation. I think power 
management can be not a reason of problem, but just a trigger.

> On Sun, Feb 1, 2009 at 6:08 PM, Alexander Motin <mav@freebsd.org> wrote:
>> Henry Hu wrote:
>>> I'm using FreeBSD 7-STABLE, with sdhci driver
>>> sdhci.20081029.tgz
>>> mmc.20081029.tgz
>>>
>>> I've found that if I load sdhci driver with card inserted, everything
>>> works fine.
>>> But if I load sdhci driver first, and then insert card, the card is
>>> not detected.Additionally, there is no interrupt.
>>> After I've load sdhci driver without card, the controller seems to be
>>> in a problematic state. The register dump outputed when the driver
>>> loaded showed that Present is 0x01f20000 which is correct since the
>>> card is not inserted then. But cards is not detected.
>>> Even if I unload the driver and reload with card inserted, the card
>>> still cannot be detected, and there's no interrupt. But the Present
>>> register changed to 0x01fa0000 which is strange.
>>>
>>> So I guess there's something wrong with the driver when the card is not
>>> present.
>>>
>>> sdhci0: <RICOH R5C822 SD> mem 0xf0401000-0xf04010ff irq 18 at device 9.1
>>> on pci5
>>> sdhci0-slot0: 33MHz 4bits 3.3V DMA
>>> sdhci0-slot0: ============== REGISTER DUMP ==============
>>> sdhci0-slot0: Sys addr: 0x00000000 | Version:  0x00000200
>>> sdhci0-slot0: Blk size: 0x00000000 | Blk cnt:  0x00000000
>>> sdhci0-slot0: Argument: 0x00000000 | Trn mode: 0x00000000
>>> sdhci0-slot0: Present:  0x01f20000 | Host ctl: 0x00000000
>>> sdhci0-slot0: Power:    0x00000000 | Blk gap:  0x00000000
>>> sdhci0-slot0: Wake-up:  0x00000000 | Clock:    0x00000000
>>> sdhci0-slot0: Timeout:  0x0000000c | Int stat: 0x00000000
>>> sdhci0-slot0: Int enab: 0x01ff00fb | Sig enab: 0x01ff00fb
>>> sdhci0-slot0: AC12 err: 0x00000000 | Slot int: 0x00000000
>>> sdhci0-slot0: Caps:     0x01c021a1 | Max curr: 0x00000040
>>> sdhci0-slot0: ===========================================
>> Try this patch please:
>> --- sdhci.c.prev        2009-01-29 00:53:41.000000000 +0200
>> +++ sdhci.c     2009-02-01 11:58:42.000000000 +0200
>> @@ -82,7 +82,8 @@ static const struct sdhci_device {
>>        u_int           quirks;
>>  } sdhci_devices[] = {
>>        { 0x08221180,   0xffff, "RICOH R5C822 SD",
>> -           SDHCI_QUIRK_FORCE_DMA },
>> +           SDHCI_QUIRK_FORCE_DMA |
>> +           SDHCI_QUIRK_NO_CARD_NO_RESET },
>>        { 0x8034104c,   0xffff, "TI XX21/XX11 SD",
>>            SDHCI_QUIRK_FORCE_DMA },
>>        { 0x05501524,   0xffff, "ENE CB712 SD",
>>
>>
>> Could everybody having this controller send me pciconf and Version register
>> from their controller and report me is this bug present on their system? I
>> would like to collect some statistics.
>>
>> --
>> Alexander Motin
>> _______________________________________________
>> freebsd-mobile@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-mobile
>> To unsubscribe, send any mail to "freebsd-mobile-unsubscribe@freebsd.org"
>>


-- 
Alexander Motin
From henry.hu.sh at gmail.com  Tue Feb  3 05:17:18 2009
From: henry.hu.sh at gmail.com (Henry Hu)
Date: Tue Feb  3 05:17:25 2009
Subject: Problem about the new sdhci driver
In-Reply-To: <4985EA94.1090007@FreeBSD.org>
References: <53a1e0710901311949x3b853404oe89cf2ae9a0903f7@mail.gmail.com>
	<49857482.5080508@FreeBSD.org>
	<53a1e0710902010432j49111ecey8d9a93acfbe3c64d@mail.gmail.com>
	<4985EA94.1090007@FreeBSD.org>
Message-ID: <53a1e0710902030517y4fb692f2nf038c8f6799d58c7@mail.gmail.com>

I've tried patch with no good result. Everything works like before.

On Mon, Feb 2, 2009 at 2:31 AM, Alexander Motin <mav@freebsd.org> wrote:
> Henry Hu wrote:
>>
>> After doing more experiments, I found the cause:
>> hw.pci.do_power_resume=3
>> If I set it to 0 and load the driver, it works well with and without the
>> card.
>> If I set it to 3 and load the driver, then
>> 1. If the card is present, then it would detect the card and the disk
>> shows up. If I remove the card and insert it again, it cannot detect
>> it again. And if I unload the driver now and reload it with the card,
>> it cannot detect the card and it cannot detect card insertion /
>> removal.
>> 2. If the card is not present, then it cannot detect the card, and if
>> I remove the card and insert it again, nothing happens.
>> The 0x01fa0000 state is normal: I found that the detection of
>> write-protection is independent from card detection. If I pull the
>> card out completely, the present register is 0x01f20000. If I pull the
>> card out half-way, the present register is 0x01fa000, the
>> write-protection bit is 1 and the card-present bit is 0...
>>
>> So the problem is about power states, not the driver, and no patch is
>> needed. Since I rarely use the card reader when the laptop is using
>> battery, I decided to remove it from sysctl .conf ....
>> Thanks for the help. Good driver!
>
> And still it would be good to try the patch. Some revisions of this
> controller known behave wrong if being reseted without card inserted. This
> patch enables special quirk to avoid that situation. I think power
> management can be not a reason of problem, but just a trigger.
>
>> On Sun, Feb 1, 2009 at 6:08 PM, Alexander Motin <mav@freebsd.org> wrote:
>>>
>>> Henry Hu wrote:
>>>>
>>>> I'm using FreeBSD 7-STABLE, with sdhci driver
>>>> sdhci.20081029.tgz
>>>> mmc.20081029.tgz
>>>>
>>>> I've found that if I load sdhci driver with card inserted, everything
>>>> works fine.
>>>> But if I load sdhci driver first, and then insert card, the card is
>>>> not detected.Additionally, there is no interrupt.
>>>> After I've load sdhci driver without card, the controller seems to be
>>>> in a problematic state. The register dump outputed when the driver
>>>> loaded showed that Present is 0x01f20000 which is correct since the
>>>> card is not inserted then. But cards is not detected.
>>>> Even if I unload the driver and reload with card inserted, the card
>>>> still cannot be detected, and there's no interrupt. But the Present
>>>> register changed to 0x01fa0000 which is strange.
>>>>
>>>> So I guess there's something wrong with the driver when the card is not
>>>> present.
>>>>
>>>> sdhci0: <RICOH R5C822 SD> mem 0xf0401000-0xf04010ff irq 18 at device 9.1
>>>> on pci5
>>>> sdhci0-slot0: 33MHz 4bits 3.3V DMA
>>>> sdhci0-slot0: ============== REGISTER DUMP ==============
>>>> sdhci0-slot0: Sys addr: 0x00000000 | Version:  0x00000200
>>>> sdhci0-slot0: Blk size: 0x00000000 | Blk cnt:  0x00000000
>>>> sdhci0-slot0: Argument: 0x00000000 | Trn mode: 0x00000000
>>>> sdhci0-slot0: Present:  0x01f20000 | Host ctl: 0x00000000
>>>> sdhci0-slot0: Power:    0x00000000 | Blk gap:  0x00000000
>>>> sdhci0-slot0: Wake-up:  0x00000000 | Clock:    0x00000000
>>>> sdhci0-slot0: Timeout:  0x0000000c | Int stat: 0x00000000
>>>> sdhci0-slot0: Int enab: 0x01ff00fb | Sig enab: 0x01ff00fb
>>>> sdhci0-slot0: AC12 err: 0x00000000 | Slot int: 0x00000000
>>>> sdhci0-slot0: Caps:     0x01c021a1 | Max curr: 0x00000040
>>>> sdhci0-slot0: ===========================================
>>>
>>> Try this patch please:
>>> --- sdhci.c.prev        2009-01-29 00:53:41.000000000 +0200
>>> +++ sdhci.c     2009-02-01 11:58:42.000000000 +0200
>>> @@ -82,7 +82,8 @@ static const struct sdhci_device {
>>>       u_int           quirks;
>>>  } sdhci_devices[] = {
>>>       { 0x08221180,   0xffff, "RICOH R5C822 SD",
>>> -           SDHCI_QUIRK_FORCE_DMA },
>>> +           SDHCI_QUIRK_FORCE_DMA |
>>> +           SDHCI_QUIRK_NO_CARD_NO_RESET },
>>>       { 0x8034104c,   0xffff, "TI XX21/XX11 SD",
>>>           SDHCI_QUIRK_FORCE_DMA },
>>>       { 0x05501524,   0xffff, "ENE CB712 SD",
>>>
>>>
>>> Could everybody having this controller send me pciconf and Version
>>> register
>>> from their controller and report me is this bug present on their system?
>>> I
>>> would like to collect some statistics.
>>>
>>> --
>>> Alexander Motin
>>> _______________________________________________
>>> freebsd-mobile@freebsd.org mailing list
>>> http://lists.freebsd.org/mailman/listinfo/freebsd-mobile
>>> To unsubscribe, send any mail to "freebsd-mobile-unsubscribe@freebsd.org"
>>>
>
>
> --
> Alexander Motin
> _______________________________________________
> freebsd-mobile@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-mobile
> To unsubscribe, send any mail to "freebsd-mobile-unsubscribe@freebsd.org"
>
From guru at unixarea.de  Wed Feb  4 02:21:13 2009
From: guru at unixarea.de (Matthias Apitz)
Date: Wed Feb  4 02:21:20 2009
Subject: EeePC 900 && UMTS 
Message-ID: <20090204102108.GA6027@rebelion.Sisis.de>


Hello,

I'm thinking in buying a USB based UMTS modem to be online with my EeePC
900 while travelling around; in the past I've done tests with the Huawei
E220 G3 Modem and it worked with my normal 7.0-STABLE based laptop.
This is already a year ago, I think -- are there any other options
nowadays? Thx

	matthias
-- 
Matthias Apitz
Manager Technical Support - OCLC GmbH
Gruenwalder Weg 28g - 82041 Oberhaching - Germany
t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211
e <matthias.apitz@oclc.org> - w http://www.oclc.org/ http://www.UnixArea.de/
b http://gurucubano.blogspot.com/
From vince at unsane.co.uk  Wed Feb  4 04:16:31 2009
From: vince at unsane.co.uk (Vincent Hoffman)
Date: Wed Feb  4 04:16:37 2009
Subject: Tethering with HTC Touch Pro -- how?
In-Reply-To: <49817333.8070708@mavhome.dp.ua>
References: <1233145383.00067348.1233133205@10.7.7.3>
	<49817333.8070708@mavhome.dp.ua>
Message-ID: <49898716.701@unsane.co.uk>

On 29/1/09 09:13, Alexander Motin wrote:
> Jack Twilley wrote:
>   
>> I have enabled internet connection sharing on my HTC Touch Pro by
>> modifying the registry.  The phone works for tethering on my Vista box
>> as expected.  How do I make it work on FreeBSD?
>>     
>
> I am successfully using my Qtek S200 with WM6.1 as plain Bluetooth
> GPRS/EDGE modem. BT PAN profile could be better for internet sharing; I
> haven't seen it implemented, but there were some activity. Sharing via
> USB cable requires RNDIS support, which is also not implemented, AFAIK
> due to buggy and undocumented protocol.
>
>   
Just as a quick appendium, bluetooth PAN support got added to -CURRENT a
couple of days ago.
 I'll try and dig out my old HTC Hermes and test it, will report back if
I do.
From mav at mavhome.dp.ua  Wed Feb  4 04:24:27 2009
From: mav at mavhome.dp.ua (Alexander Motin)
Date: Wed Feb  4 04:24:34 2009
Subject: Tethering with HTC Touch Pro -- how?
In-Reply-To: <49898716.701@unsane.co.uk>
References: <1233145383.00067348.1233133205@10.7.7.3>
	<49817333.8070708@mavhome.dp.ua> <49898716.701@unsane.co.uk>
Message-ID: <498988F9.40106@mavhome.dp.ua>

Vincent Hoffman wrote:
> On 29/1/09 09:13, Alexander Motin wrote:
>> Jack Twilley wrote:
>>   
>>> I have enabled internet connection sharing on my HTC Touch Pro by
>>> modifying the registry.  The phone works for tethering on my Vista box
>>> as expected.  How do I make it work on FreeBSD?
>>>     
>> I am successfully using my Qtek S200 with WM6.1 as plain Bluetooth
>> GPRS/EDGE modem. BT PAN profile could be better for internet sharing; I
>> haven't seen it implemented, but there were some activity. Sharing via
>> USB cable requires RNDIS support, which is also not implemented, AFAIK
>> due to buggy and undocumented protocol.
>>   
> Just as a quick appendium, bluetooth PAN support got added to -CURRENT a
> couple of days ago.
>  I'll try and dig out my old HTC Hermes and test it, will report back if
> I do.

I have even tested it already and replied on freebsd-bluetooth@. It
works fine with my Qtek S200 with WM6.1.

-- 
Alexander Motin
From charlie1337 at bigpond.com  Sun Feb  8 18:59:52 2009
From: charlie1337 at bigpond.com (Wilyarti Howard)
Date: Sun Feb  8 19:00:06 2009
Subject: EeePC 701SD
Message-ID: <498F94BC.6090301@bigpond.com>

I am new to this list and wish to inform all those internested that I 
have got FreeBSD 7.1 RELEASE on the EeePC going well.

The only things that DO NOT work are Camera and Wireless.

There were huge problems with speed until I enabled tmpfs for ALL tmp 
directories and put noatime in /etc/fstab.

I also couldnt partion the hard drive for space reason.

Also it will not boot if you have another umass storage device besides 
the SD card because freebsd assigns the USB stick to da0 not the hard drive.

Is there a demand or need by the FreeBSD developers for me to test 
drivers or post info of my Kernel configuration, dmesg and such?

Or is this not a great achievment :)

By the way powerd works with eeemon.ko and you can controll CPU speed, 
screen resolution and see all hardware information.

If anyone desire such information as /etc/rc.conf, /etc/fstab custom 
kernal conf and /boot/loader.conf files I would be happy to supply them!

If only I had such information when I started the 5 day adventure....

Cheers!
-Wilyarti Howard
From guru at unixarea.de  Sun Feb  8 21:56:38 2009
From: guru at unixarea.de (Matthias Apitz)
Date: Sun Feb  8 21:56:46 2009
Subject: EeePC 701SD
In-Reply-To: <498F94BC.6090301@bigpond.com>
References: <498F94BC.6090301@bigpond.com>
Message-ID: <20090209055457.GA1821@rebelion.Sisis.de>

El d?a Monday, February 09, 2009 a las 01:28:12PM +1100, Wilyarti Howard escribi?:

> I am new to this list and wish to inform all those internested that I 
> have got FreeBSD 7.1 RELEASE on the EeePC going well.
> 
> The only things that DO NOT work are Camera and Wireless.
> 
> There were huge problems with speed until I enabled tmpfs for ALL tmp 
> directories and put noatime in /etc/fstab.
> 
> I also couldnt partion the hard drive for space reason.
> 
> Also it will not boot if you have another umass storage device besides 
> the SD card because freebsd assigns the USB stick to da0 not the hard drive.
> 
> Is there a demand or need by the FreeBSD developers for me to test 
> drivers or post info of my Kernel configuration, dmesg and such?
> 
> Or is this not a great achievment :)
> 
> By the way powerd works with eeemon.ko and you can controll CPU speed, 
> screen resolution and see all hardware information.
> 
> If anyone desire such information as /etc/rc.conf, /etc/fstab custom 
> kernal conf and /boot/loader.conf files I would be happy to supply them!
> 
> If only I had such information when I started the 5 day adventure....

It's a bit late, but maybe you can reflect your work with some ideas from here:

http://www.unixarea.de/installEeePC.txt
http://wiki.freebsd.org/AsusEee

:-)

	matthias
-- 
Matthias Apitz
Manager Technical Support - OCLC GmbH
Gruenwalder Weg 28g - 82041 Oberhaching - Germany
t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211
e <matthias.apitz@oclc.org> - w http://www.oclc.org/ http://www.UnixArea.de/
b http://gurucubano.blogspot.com/
From bengta at sics.se  Mon Feb  9 02:45:19 2009
From: bengta at sics.se (Bengt Ahlgren)
Date: Mon Feb  9 02:45:26 2009
Subject: Problems with ath at kern.hz=100
Message-ID: <uh7iqnjzzi9.fsf@P142.sics.se>

Hello!

I was changing kern.hz to 100 on my IBM X40 (Pentium-M) laptop to see
whether that saves some battery, but ran into problems with ath not
working properly.  At first I thought that my hardware was failing,
but changing hz back to 1000 solved the problem.  I am running
7.1-RELEASE-p1 and have the following Atheros chip:

Feb  9 11:13:10 P142 kernel: ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413)
Feb  9 11:13:10 P142 kernel: ath0: <Atheros 5212> mem 0xd0200000-0xd020ffff irq 11 at device 2.0 on pci2
Feb  9 11:13:10 P142 kernel: ath0: [ITHREAD]
Feb  9 11:13:10 P142 kernel: ath0: WARNING: using obsoleted if_watchdog interface
Feb  9 11:13:10 P142 kernel: ath0: Ethernet address: 00:05:4e:4e:1f:c7
Feb  9 11:13:10 P142 kernel: ath0: mac 5.6 phy 4.1 5ghz radio 1.7 2ghz radio 2.3

The symptom is that ath stops sending packets out.  They seem to be
buffered somewhere.  After a while it gets going again, albeit some
packets are lost.  "A while" can be from 5 secs to a minute or so when
continously running a ping.  In the below logs, a ping is started when
ath has stopped sending.

"netstat -I ath0 1" reports that no packets are sent, but the byte
count is still incremented.  When it gets going again, 18 packets are
sent, but the byte count does not reflect that (which perpaps is
logical):

         1     0         56          0     0          0     0
         0     0          0          0     0          0     0
         0     0          0          0     0         98     0
         1     0         56          0     0         98     0
         1     0         56          0     0         98     0
            input         (ath0)           output
   packets  errs      bytes    packets  errs      bytes colls
         0     0          0          0     0         98     0
         1     0         56          0     0         98     0
         1     0         56          0     0         98     0
         1     0         56          0     0         98     0
         0     0          0          0     0         98     0
         0     0          0          0     0         98     0
         0     0          0          0     0         98     0
         0     0          0          0     0         98     0
         0     0          0          0     0         98     0
         1     0         56          0     0         98     0
         1     0         56          0     0         98     0
         2     0        112          0     0         98     0
         0     0          0          0     0         98     0
         4     0        350         18     0        140     0
         2     0        112          0     0          0     0
         1     1         56          0     0          0     0
         1     0         56          0     0          0     0
         0     0          0          0     0          0     0
^C

Here is a tcpdump of the same event:

18:40:59.025364 arp who-has 10.1.1.72 tell 10.1.7.250
18:41:00.049385 arp who-has 10.1.1.72 tell 10.1.7.250
18:41:00.868608 arp who-has 10.1.6.253 tell 10.1.7.250
18:41:01.073387 arp who-has 10.1.1.72 tell 10.1.7.250
18:41:02.761445 IP 10.1.1.107 > 193.10.65.193: ICMP echo request, id 63239, seq 0, length 64
18:41:02.761456 IP 10.1.1.107 > 193.10.65.193: ICMP echo request, id 63239, seq 1, length 64
18:41:02.761461 IP 10.1.1.107 > 193.10.65.193: ICMP echo request, id 63239, seq 2, length 64
18:41:02.761466 IP 10.1.1.107 > 193.10.65.193: ICMP echo request, id 63239, seq 3, length 64
18:41:02.761470 IP 10.1.1.107 > 193.10.65.193: ICMP echo request, id 63239, seq 4, length 64
18:41:02.761474 IP 10.1.1.107 > 193.10.65.193: ICMP echo request, id 63239, seq 5, length 64
18:41:02.761479 IP 10.1.1.107 > 193.10.65.193: ICMP echo request, id 63239, seq 6, length 64
18:41:02.761483 IP 10.1.1.107 > 193.10.65.193: ICMP echo request, id 63239, seq 7, length 64
18:41:02.761487 IP 10.1.1.107 > 193.10.65.193: ICMP echo request, id 63239, seq 8, length 64
18:41:02.761492 IP 10.1.1.107 > 193.10.65.193: ICMP echo request, id 63239, seq 9, length 64
18:41:02.761497 IP 10.1.1.107 > 193.10.65.193: ICMP echo request, id 63239, seq 10, length 64
18:41:02.761502 IP 10.1.1.107 > 193.10.65.193: ICMP echo request, id 63239, seq 11, length 64
18:41:02.761506 IP 10.1.1.107 > 193.10.65.193: ICMP echo request, id 63239, seq 12, length 64
18:41:02.761510 IP 10.1.1.107 > 193.10.65.193: ICMP echo request, id 63239, seq 13, length 64
18:41:02.761515 IP 10.1.1.107 > 193.10.65.193: ICMP echo request, id 63239, seq 14, length 64
18:41:02.761519 IP 10.1.1.107 > 193.10.65.193: ICMP echo request, id 63239, seq 15, length 64
18:41:02.761523 IP 10.1.1.107 > 193.10.65.193: ICMP echo request, id 63239, seq 16, length 64
18:41:02.916556 arp who-has 10.1.1.107 tell 10.1.7.250
18:41:02.916579 arp reply 10.1.1.107 is-at 00:05:4e:4e:1f:c7
18:41:02.917707 IP 193.10.65.193 > 10.1.1.107: ICMP echo reply, id 63239, seq 14, length 64
18:41:02.917906 IP 193.10.65.193 > 10.1.1.107: ICMP echo reply, id 63239, seq 15, length 64
18:41:02.918187 IP 193.10.65.193 > 10.1.1.107: ICMP echo reply, id 63239, seq 16, length 64
18:41:03.531108 arp who-has 10.1.1.72 tell 10.1.7.250
18:41:04.350185 arp who-has 10.1.6.166 tell 10.1.7.250
18:41:04.554984 arp who-has 10.1.1.72 tell 10.1.7.250
18:41:05.578972 arp who-has 10.1.1.72 tell 10.1.7.250
^C
289 packets captured
289 packets received by filter
0 packets dropped by kernel

Any idea on what the problem can be, or how do debug this further?

Regards,

Bengt
From dsh at wizard.volgograd.ru  Mon Feb  9 06:03:36 2009
From: dsh at wizard.volgograd.ru (Denis Shaposhnikov)
Date: Mon Feb  9 06:03:42 2009
Subject: RELENG7 on Samsung R510-FA0K (JFYI)
Message-ID: <20090209164820.00be4837@wizard.volgograd.ru>

Hello,

This is just a report about my new notebook with

  FreeBSD 7.1-STABLE #2: Mon Feb  9 04:36:30 MSK 2009

1. Xorg works with x11-drivers/xf86-video-intel and resolution 1280x800.

2. SD card reader just works.

3. WLAN works with ath_hal-20080528.tgz

   ath0: <Atheros 5424/2424> mem 0xf3000000-0xf300ffff irq 16 at device
   0.0 on pci2

4. Audio works with snd_hda.

5. Touchpad just works:

   psm0: <PS/2 Mouse> flags 0x4 irq 12 on atkbdc0
   psm0: model Synaptics Touchpad, device ID 0

6. Bluetooth seems don't work:

   ugen1: <Broadcom Corp BCM92045NMD, class 224/1, rev 2.00/3.54, addr
   on uhub6

Does anybody know about this anything?

7. Web camera seems don't work:

   ugen0: <Vimicro Corp. Vega USB 2.0 Camera., class 239/2, rev
   2.00/1.00, addr on uhub3

Does anybody know about this anything?

8. Can't control backlight by keys, but can do it using xrandr.

9. ACPI seems to work, but I see strange messages on boot

cpu0: <ACPI CPU> on acpi0
ACPI Error (dsopcode-0350): No pointer back to NS node in buffer obj 0xc4dff7c0 [20070320]
ACPI Exception (dswexec-0556): AE_AML_INTERNAL, While resolving operands for [OpcodeName unavailable] [20070320]
ACPI Error (psparse-0626): Method parse/execution failed [\\_PR_.CPU0._OSC] (Node 0xc4d32380), AE_AML_INTERNAL
acpi_throttle0: <ACPI CPU Throttling> on cpu0
cpu1: <ACPI CPU> on acpi0
ACPI Error (dsopcode-0350): No pointer back to NS node in buffer obj 0xc4dff300 [20070320]
ACPI Exception (dswexec-0556): AE_AML_INTERNAL, While resolving operands for [OpcodeName unavailable] [20070320]
ACPI Error (psparse-0626): Method parse/execution failed [\\_PR_.CPU1._OSC] (Node 0xc4d322a0), AE_AML_INTERNAL
acpi_throttle1: <ACPI CPU Throttling> on cpu1
acpi_throttle1: failed to attach P_CNT
device_attach: acpi_throttle1 attach returned 6
From maksim.yevmenkin at gmail.com  Mon Feb  9 08:03:33 2009
From: maksim.yevmenkin at gmail.com (Maksim Yevmenkin)
Date: Mon Feb  9 08:03:48 2009
Subject: RELENG7 on Samsung R510-FA0K (JFYI)
In-Reply-To: <20090209164820.00be4837@wizard.volgograd.ru>
References: <20090209164820.00be4837@wizard.volgograd.ru>
Message-ID: <bb4a86c70902090743x3e5e2600s7979b0b07ebc2540@mail.gmail.com>

On Mon, Feb 9, 2009 at 5:48 AM, Denis Shaposhnikov
<dsh@wizard.volgograd.ru> wrote:

[...]

> 6. Bluetooth seems don't work:
>
>   ugen1: <Broadcom Corp BCM92045NMD, class 224/1, rev 2.00/3.54, addr
>   on uhub6
>
> Does anybody know about this anything?

did you load the driver? ng_ubt(4) for usb1 or usb_bluetooth_ng for usb2.

thanks,
max
From dsh at wizard.volgograd.ru  Mon Feb  9 08:17:49 2009
From: dsh at wizard.volgograd.ru (Denis Shaposhnikov)
Date: Mon Feb  9 08:17:55 2009
Subject: RELENG7 on Samsung R510-FA0K (JFYI)
In-Reply-To: <bb4a86c70902090743x3e5e2600s7979b0b07ebc2540@mail.gmail.com>
References: <20090209164820.00be4837@wizard.volgograd.ru>
	<bb4a86c70902090743x3e5e2600s7979b0b07ebc2540@mail.gmail.com>
Message-ID: <20090209191740.548cffca@wizard.volgograd.ru>

Hello,

On Mon, 9 Feb 2009 07:43:24 -0800
Maksim Yevmenkin <maksim.yevmenkin@gmail.com> wrote:

> >   ugen1: <Broadcom Corp BCM92045NMD, class 224/1, rev 2.00/3.54,
> > addr on uhub6

> did you load the driver? ng_ubt(4) for usb1 or usb_bluetooth_ng for
> usb2.

I've just tried it

[dsh@localhost ~]% kldstat | tail
15    1 0xc093f000 5500     acpi_video.ko
16    2 0xc0945000 6a44c    acpi.ko
17    1 0xc09b0000 4c70     atapicam.ko
18    1 0xc09b5000 8130     atapicd.ko
19    1 0xc09be000 2dec     wlan_wep.ko
20    1 0xc09c1000 5208     wlan_scan_sta.ko
21    1 0xc53df000 b000     i915.ko
22    1 0xc53ea000 13000    drm.ko
23    1 0xc5e42000 7000     ng_ubt.ko
24    1 0xc5e49000 b000     netgraph.ko

and I don't see anything about it in dmesg output.
From maksim.yevmenkin at gmail.com  Mon Feb  9 08:22:21 2009
From: maksim.yevmenkin at gmail.com (Maksim Yevmenkin)
Date: Mon Feb  9 08:22:28 2009
Subject: RELENG7 on Samsung R510-FA0K (JFYI)
In-Reply-To: <20090209191740.548cffca@wizard.volgograd.ru>
References: <20090209164820.00be4837@wizard.volgograd.ru>
	<bb4a86c70902090743x3e5e2600s7979b0b07ebc2540@mail.gmail.com>
	<20090209191740.548cffca@wizard.volgograd.ru>
Message-ID: <bb4a86c70902090822s10a8a65q2fea5dd60afa39d9@mail.gmail.com>

2009/2/9 Denis Shaposhnikov <dsh@wizard.volgograd.ru>:
> Hello,
>
> On Mon, 9 Feb 2009 07:43:24 -0800
> Maksim Yevmenkin <maksim.yevmenkin@gmail.com> wrote:
>
>> >   ugen1: <Broadcom Corp BCM92045NMD, class 224/1, rev 2.00/3.54,
>> > addr on uhub6
>
>> did you load the driver? ng_ubt(4) for usb1 or usb_bluetooth_ng for
>> usb2.
>
> I've just tried it
>
> [dsh@localhost ~]% kldstat | tail
> 15    1 0xc093f000 5500     acpi_video.ko
> 16    2 0xc0945000 6a44c    acpi.ko
> 17    1 0xc09b0000 4c70     atapicam.ko
> 18    1 0xc09b5000 8130     atapicd.ko
> 19    1 0xc09be000 2dec     wlan_wep.ko
> 20    1 0xc09c1000 5208     wlan_scan_sta.ko
> 21    1 0xc53df000 b000     i915.ko
> 22    1 0xc53ea000 13000    drm.ko
> 23    1 0xc5e42000 7000     ng_ubt.ko
> 24    1 0xc5e49000 b000     netgraph.ko
>
> and I don't see anything about it in dmesg output.

now you need to unplug/replug the device (or use off/on button if you
have it on your laptop). you also can add

ng_ubt_load="YES"

to your loader.conf and reboot

thanks,
max
From webmaster at kibab.com  Mon Feb  9 08:27:02 2009
From: webmaster at kibab.com (Ilya Bakulin)
Date: Mon Feb  9 08:27:08 2009
Subject: RELENG7 on Samsung R510-FA0K (JFYI)
In-Reply-To: <20090209191740.548cffca@wizard.volgograd.ru>
References: <20090209164820.00be4837@wizard.volgograd.ru>
	<bb4a86c70902090743x3e5e2600s7979b0b07ebc2540@mail.gmail.com>
	<20090209191740.548cffca@wizard.volgograd.ru>
Message-ID: <20090209192656.e92af17c.webmaster@kibab.com>

On Mon, 9 Feb 2009 19:17:40 +0300
Denis Shaposhnikov <dsh@wizard.volgograd.ru> wrote:

> and I don't see anything about it in dmesg output.

Add the following line in /boot/loader.conf:
ng_ubt_load="YES"

This driver should be loaded in kernel _before_ USB unumeration.

> 7. Web camera seems don't work:
>   ugen0: <Vimicro Corp. Vega USB 2.0 Camera., class 239/2, rev
>   2.00/1.00, addr on uhub3

Class 239/2 is USB Video Class compliant web camera. UVC is not supported in FreeBSD [yet?].

> 9. ACPI seems to work, but I see strange messages on boot

1st thing you should do is updating your system BIOS. If it doesn't help, you may try to repair AML code by hand (see FreeBSD handbook for further instructions) or, at last, write on freebsd-acpi@ about this problem.

-- 
Ilya Bakulin <webmaster@kibab.com>
xmpp://kibab612@jabber.ru
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-mobile/attachments/20090209/4eafe5ab/attachment.pgp
From smithi at nimnet.asn.au  Mon Feb  9 21:34:16 2009
From: smithi at nimnet.asn.au (Ian Smith)
Date: Mon Feb  9 21:34:23 2009
Subject: Problems with ath at kern.hz=100
In-Reply-To: <uh7iqnjzzi9.fsf@P142.sics.se>
References: <uh7iqnjzzi9.fsf@P142.sics.se>
Message-ID: <20090210154047.N38905@sola.nimnet.asn.au>

On Mon, 9 Feb 2009, Bengt Ahlgren wrote:

 > I was changing kern.hz to 100 on my IBM X40 (Pentium-M) laptop to see
 > whether that saves some battery, but ran into problems with ath not
 > working properly.  At first I thought that my hardware was failing,
 > but changing hz back to 1000 solved the problem.  I am running
 > 7.1-RELEASE-p1 and have the following Atheros chip:
 > 
 > Feb  9 11:13:10 P142 kernel: ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413)
 > Feb  9 11:13:10 P142 kernel: ath0: <Atheros 5212> mem 0xd0200000-0xd020ffff irq 11 at device 2.0 on pci2
 > Feb  9 11:13:10 P142 kernel: ath0: [ITHREAD]
 > Feb  9 11:13:10 P142 kernel: ath0: WARNING: using obsoleted if_watchdog interface
 > Feb  9 11:13:10 P142 kernel: ath0: Ethernet address: 00:05:4e:4e:1f:c7
 > Feb  9 11:13:10 P142 kernel: ath0: mac 5.6 phy 4.1 5ghz radio 1.7 2ghz radio 2.3

There's an order of magnitude room to move between 100 and 1000 Hz.  
You could also try with maybe 250 or 500?

What speed is your Pentium-M?  Are you using powerd?  If so, what 
minimum CPU freq does it drop back to (sysctl debug.cpufreq.lowest)?

Sam has talked of a problem with ath (and maybe other) interrupt rates 
overwhelming slow CPUs to the extent that userland (ie powerd) doesn't 
get a look-in for a while, as I understand it.  A fast CPU clocked back 
to less than say 300MHz IS a slow CPU, until powerd gets to crank it up.

You might find that rc.conf setting economy_cx_lowest="LOW" can save you 
some battery, though this benefit seems somewhat processor-dependent.

HTH, Ian


 > The symptom is that ath stops sending packets out.  They seem to be
 > buffered somewhere.  After a while it gets going again, albeit some
 > packets are lost.  "A while" can be from 5 secs to a minute or so when
 > continously running a ping.  In the below logs, a ping is started when
 > ath has stopped sending.
 > 
 > "netstat -I ath0 1" reports that no packets are sent, but the byte
 > count is still incremented.  When it gets going again, 18 packets are
 > sent, but the byte count does not reflect that (which perpaps is
 > logical):
 > 
 >          1     0         56          0     0          0     0
 >          0     0          0          0     0          0     0
 >          0     0          0          0     0         98     0
 >          1     0         56          0     0         98     0
 >          1     0         56          0     0         98     0
 >             input         (ath0)           output
 >    packets  errs      bytes    packets  errs      bytes colls
 >          0     0          0          0     0         98     0
 >          1     0         56          0     0         98     0
 >          1     0         56          0     0         98     0
 >          1     0         56          0     0         98     0
 >          0     0          0          0     0         98     0
 >          0     0          0          0     0         98     0
 >          0     0          0          0     0         98     0
 >          0     0          0          0     0         98     0
 >          0     0          0          0     0         98     0
 >          1     0         56          0     0         98     0
 >          1     0         56          0     0         98     0
 >          2     0        112          0     0         98     0
 >          0     0          0          0     0         98     0
 >          4     0        350         18     0        140     0
 >          2     0        112          0     0          0     0
 >          1     1         56          0     0          0     0
 >          1     0         56          0     0          0     0
 >          0     0          0          0     0          0     0
 > ^C
 > 
 > Here is a tcpdump of the same event:
 > 
 > 18:40:59.025364 arp who-has 10.1.1.72 tell 10.1.7.250
 > 18:41:00.049385 arp who-has 10.1.1.72 tell 10.1.7.250
 > 18:41:00.868608 arp who-has 10.1.6.253 tell 10.1.7.250
 > 18:41:01.073387 arp who-has 10.1.1.72 tell 10.1.7.250
 > 18:41:02.761445 IP 10.1.1.107 > 193.10.65.193: ICMP echo request, id 63239, seq 0, length 64
 > 18:41:02.761456 IP 10.1.1.107 > 193.10.65.193: ICMP echo request, id 63239, seq 1, length 64
 > 18:41:02.761461 IP 10.1.1.107 > 193.10.65.193: ICMP echo request, id 63239, seq 2, length 64
 > 18:41:02.761466 IP 10.1.1.107 > 193.10.65.193: ICMP echo request, id 63239, seq 3, length 64
 > 18:41:02.761470 IP 10.1.1.107 > 193.10.65.193: ICMP echo request, id 63239, seq 4, length 64
 > 18:41:02.761474 IP 10.1.1.107 > 193.10.65.193: ICMP echo request, id 63239, seq 5, length 64
 > 18:41:02.761479 IP 10.1.1.107 > 193.10.65.193: ICMP echo request, id 63239, seq 6, length 64
 > 18:41:02.761483 IP 10.1.1.107 > 193.10.65.193: ICMP echo request, id 63239, seq 7, length 64
 > 18:41:02.761487 IP 10.1.1.107 > 193.10.65.193: ICMP echo request, id 63239, seq 8, length 64
 > 18:41:02.761492 IP 10.1.1.107 > 193.10.65.193: ICMP echo request, id 63239, seq 9, length 64
 > 18:41:02.761497 IP 10.1.1.107 > 193.10.65.193: ICMP echo request, id 63239, seq 10, length 64
 > 18:41:02.761502 IP 10.1.1.107 > 193.10.65.193: ICMP echo request, id 63239, seq 11, length 64
 > 18:41:02.761506 IP 10.1.1.107 > 193.10.65.193: ICMP echo request, id 63239, seq 12, length 64
 > 18:41:02.761510 IP 10.1.1.107 > 193.10.65.193: ICMP echo request, id 63239, seq 13, length 64
 > 18:41:02.761515 IP 10.1.1.107 > 193.10.65.193: ICMP echo request, id 63239, seq 14, length 64
 > 18:41:02.761519 IP 10.1.1.107 > 193.10.65.193: ICMP echo request, id 63239, seq 15, length 64
 > 18:41:02.761523 IP 10.1.1.107 > 193.10.65.193: ICMP echo request, id 63239, seq 16, length 64
 > 18:41:02.916556 arp who-has 10.1.1.107 tell 10.1.7.250
 > 18:41:02.916579 arp reply 10.1.1.107 is-at 00:05:4e:4e:1f:c7
 > 18:41:02.917707 IP 193.10.65.193 > 10.1.1.107: ICMP echo reply, id 63239, seq 14, length 64
 > 18:41:02.917906 IP 193.10.65.193 > 10.1.1.107: ICMP echo reply, id 63239, seq 15, length 64
 > 18:41:02.918187 IP 193.10.65.193 > 10.1.1.107: ICMP echo reply, id 63239, seq 16, length 64
 > 18:41:03.531108 arp who-has 10.1.1.72 tell 10.1.7.250
 > 18:41:04.350185 arp who-has 10.1.6.166 tell 10.1.7.250
 > 18:41:04.554984 arp who-has 10.1.1.72 tell 10.1.7.250
 > 18:41:05.578972 arp who-has 10.1.1.72 tell 10.1.7.250
 > ^C
 > 289 packets captured
 > 289 packets received by filter
 > 0 packets dropped by kernel
 > 
 > Any idea on what the problem can be, or how do debug this further?
 > 
 > Regards,
 > 
 > Bengt
From dsh at wizard.volgograd.ru  Tue Feb 10 06:18:08 2009
From: dsh at wizard.volgograd.ru (Denis Shaposhnikov)
Date: Tue Feb 10 06:18:14 2009
Subject: RELENG7 on Samsung R510-FA0K (JFYI)
In-Reply-To: <bb4a86c70902090822s10a8a65q2fea5dd60afa39d9@mail.gmail.com>
References: <20090209164820.00be4837@wizard.volgograd.ru>
	<bb4a86c70902090743x3e5e2600s7979b0b07ebc2540@mail.gmail.com>
	<20090209191740.548cffca@wizard.volgograd.ru>
	<bb4a86c70902090822s10a8a65q2fea5dd60afa39d9@mail.gmail.com>
Message-ID: <20090210171800.0314597e@wizard.volgograd.ru>

Hello,

On Mon, 9 Feb 2009 08:22:20 -0800
Maksim Yevmenkin <maksim.yevmenkin@gmail.com> wrote:

> have it on your laptop). you also can add
> 
> ng_ubt_load="YES"
> 
> to your loader.conf and reboot

Thank you, it works now!

ubt0: <Broadcom Corp BCM92045NMD, class 224/1, rev 2.00/3.54, addr 2>
on uhub6
ubt0: Interface 0 endpoints: interrupt=0x81, bulk-in=0x82, bulk-out=0x2
ubt0: Interface 1 (alt.config 4) endpoints: isoc-in=0x83, isoc-out=0x3;
wMaxPacketSize=64; nframes=5, buffer size=320
From bengta at sics.se  Tue Feb 10 08:08:50 2009
From: bengta at sics.se (Bengt Ahlgren)
Date: Tue Feb 10 08:09:01 2009
Subject: Problems with ath at kern.hz=100
In-Reply-To: <20090210154047.N38905@sola.nimnet.asn.au> (Ian Smith's message
	of "Tue\, 10 Feb 2009 16\:13\:23 +1100 \(EST\)")
References: <uh7iqnjzzi9.fsf@P142.sics.se>
	<20090210154047.N38905@sola.nimnet.asn.au>
Message-ID: <uh7d4dql1hh.fsf@P142.sics.se>

Ian Smith <smithi@nimnet.asn.au> writes:

> On Mon, 9 Feb 2009, Bengt Ahlgren wrote:
>
>  > I was changing kern.hz to 100 on my IBM X40 (Pentium-M) laptop to see
>  > whether that saves some battery, but ran into problems with ath not
>  > working properly.  At first I thought that my hardware was failing,
>  > but changing hz back to 1000 solved the problem.  I am running
>  > 7.1-RELEASE-p1 and have the following Atheros chip:
>  > 
>  > Feb  9 11:13:10 P142 kernel: ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413)
>  > Feb  9 11:13:10 P142 kernel: ath0: <Atheros 5212> mem 0xd0200000-0xd020ffff irq 11 at device 2.0 on pci2
>  > Feb  9 11:13:10 P142 kernel: ath0: [ITHREAD]
>  > Feb  9 11:13:10 P142 kernel: ath0: WARNING: using obsoleted if_watchdog interface
>  > Feb  9 11:13:10 P142 kernel: ath0: Ethernet address: 00:05:4e:4e:1f:c7
>  > Feb  9 11:13:10 P142 kernel: ath0: mac 5.6 phy 4.1 5ghz radio 1.7 2ghz radio 2.3
>
> There's an order of magnitude room to move between 100 and 1000 Hz.  
> You could also try with maybe 250 or 500?

I have been running with hz=250 for a while now without the problem
occuring.

> What speed is your Pentium-M?  Are you using powerd?  If so, what 
> minimum CPU freq does it drop back to (sysctl debug.cpufreq.lowest)?

It is a 1200MHz.  I have debug.cpufreq.lowest=600 in order to only use
EST.  I ran for a while at 1200MHz with no powerd and ath still
stopped sending.

> Sam has talked of a problem with ath (and maybe other) interrupt rates 
> overwhelming slow CPUs to the extent that userland (ie powerd) doesn't 
> get a look-in for a while, as I understand it.  A fast CPU clocked back 
> to less than say 300MHz IS a slow CPU, until powerd gets to crank it up.
>
> You might find that rc.conf setting economy_cx_lowest="LOW" can save you 
> some battery, though this benefit seems somewhat processor-dependent.

I tried with dev.cpu.0.cx_lowest=C1 (at 1200MHz), but with no
difference - the problem is still there.

Bengt
From bengta at sics.se  Tue Feb 10 08:10:46 2009
From: bengta at sics.se (Bengt Ahlgren)
Date: Tue Feb 10 08:10:52 2009
Subject: Problems with ath at kern.hz=100
In-Reply-To: <uh7d4dql1hh.fsf@P142.sics.se> (Bengt Ahlgren's message of "Tue\,
	10 Feb 2009 17\:07\:22 +0100")
References: <uh7iqnjzzi9.fsf@P142.sics.se>
	<20090210154047.N38905@sola.nimnet.asn.au>
	<uh7d4dql1hh.fsf@P142.sics.se>
Message-ID: <uh78woel1dx.fsf@P142.sics.se>

Bengt Ahlgren <bengta@sics.se> writes:

> Ian Smith <smithi@nimnet.asn.au> writes:
>
>> On Mon, 9 Feb 2009, Bengt Ahlgren wrote:
>>
>>  > I was changing kern.hz to 100 on my IBM X40 (Pentium-M) laptop to see
>>  > whether that saves some battery, but ran into problems with ath not
>>  > working properly.  At first I thought that my hardware was failing,
>>  > but changing hz back to 1000 solved the problem.  I am running
>>  > 7.1-RELEASE-p1 and have the following Atheros chip:
>>  > 
>>  > Feb  9 11:13:10 P142 kernel: ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413)
>>  > Feb  9 11:13:10 P142 kernel: ath0: <Atheros 5212> mem 0xd0200000-0xd020ffff irq 11 at device 2.0 on pci2
>>  > Feb  9 11:13:10 P142 kernel: ath0: [ITHREAD]
>>  > Feb  9 11:13:10 P142 kernel: ath0: WARNING: using obsoleted if_watchdog interface
>>  > Feb  9 11:13:10 P142 kernel: ath0: Ethernet address: 00:05:4e:4e:1f:c7
>>  > Feb  9 11:13:10 P142 kernel: ath0: mac 5.6 phy 4.1 5ghz radio 1.7 2ghz radio 2.3
>>
>> There's an order of magnitude room to move between 100 and 1000 Hz.  
>> You could also try with maybe 250 or 500?
>
> I have been running with hz=250 for a while now without the problem
> occuring.

Just when sending this off, it also happened with hz=250.

Bengt
From sam at freebsd.org  Tue Feb 10 08:45:29 2009
From: sam at freebsd.org (Sam Leffler)
Date: Tue Feb 10 08:45:35 2009
Subject: Problems with ath at kern.hz=100
In-Reply-To: <20090210154047.N38905@sola.nimnet.asn.au>
References: <uh7iqnjzzi9.fsf@P142.sics.se>
	<20090210154047.N38905@sola.nimnet.asn.au>
Message-ID: <4991ABA0.4050300@freebsd.org>

Ian Smith wrote:
> On Mon, 9 Feb 2009, Bengt Ahlgren wrote:
>
>  > I was changing kern.hz to 100 on my IBM X40 (Pentium-M) laptop to see
>  > whether that saves some battery, but ran into problems with ath not
>  > working properly.  At first I thought that my hardware was failing,
>  > but changing hz back to 1000 solved the problem.  I am running
>  > 7.1-RELEASE-p1 and have the following Atheros chip:
>  > 
>  > Feb  9 11:13:10 P142 kernel: ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413)
>  > Feb  9 11:13:10 P142 kernel: ath0: <Atheros 5212> mem 0xd0200000-0xd020ffff irq 11 at device 2.0 on pci2
>  > Feb  9 11:13:10 P142 kernel: ath0: [ITHREAD]
>  > Feb  9 11:13:10 P142 kernel: ath0: WARNING: using obsoleted if_watchdog interface
>  > Feb  9 11:13:10 P142 kernel: ath0: Ethernet address: 00:05:4e:4e:1f:c7
>  > Feb  9 11:13:10 P142 kernel: ath0: mac 5.6 phy 4.1 5ghz radio 1.7 2ghz radio 2.3
>
> There's an order of magnitude room to move between 100 and 1000 Hz.  
> You could also try with maybe 250 or 500?
>
> What speed is your Pentium-M?  Are you using powerd?  If so, what 
> minimum CPU freq does it drop back to (sysctl debug.cpufreq.lowest)?
>
> Sam has talked of a problem with ath (and maybe other) interrupt rates 
> overwhelming slow CPUs to the extent that userland (ie powerd) doesn't 
> get a look-in for a while, as I understand it.  A fast CPU clocked back 
> to less than say 300MHz IS a slow CPU, until powerd gets to crank it up.
>   

If powerd starvation were happening you'd see livelock not slow 
traffic.  The problem was that MIB overflow interrupts from the card 
were pounding the host but since the cpu clock was lowered they were not 
serviced fast enough.

FWIW I believe the MIB interrupt storm issue is fixed in head.  I posted 
a patch to stable@ to enable backmerge of the necessary code but 
received ~zero feedback in >1 month so RELENG_7 will continue to rot w/ 
old code.

> You might find that rc.conf setting economy_cx_lowest="LOW" can save you 
> some battery, though this benefit seems somewhat processor-dependent.
>
> HTH, Ian
>
>
>  > The symptom is that ath stops sending packets out.  They seem to be
>  > buffered somewhere.  After a while it gets going again, albeit some
>  > packets are lost.  "A while" can be from 5 secs to a minute or so when
>  > continously running a ping.  In the below logs, a ping is started when
>  > ath has stopped sending.
>   
>  > 
>  > "netstat -I ath0 1" reports that no packets are sent, but the byte
>  > count is still incremented.  When it gets going again, 18 packets are
>  > sent, but the byte count does not reflect that (which perpaps is
>  > logical):
>  > 
>  >          1     0         56          0     0          0     0
>  >          0     0          0          0     0          0     0
>  >          0     0          0          0     0         98     0
>  >          1     0         56          0     0         98     0
>  >          1     0         56          0     0         98     0
>  >             input         (ath0)           output
>  >    packets  errs      bytes    packets  errs      bytes colls
>  >          0     0          0          0     0         98     0
>  >          1     0         56          0     0         98     0
>  >          1     0         56          0     0         98     0
>  >          1     0         56          0     0         98     0
>  >          0     0          0          0     0         98     0
>  >          0     0          0          0     0         98     0
>  >          0     0          0          0     0         98     0
>  >          0     0          0          0     0         98     0
>  >          0     0          0          0     0         98     0
>  >          1     0         56          0     0         98     0
>  >          1     0         56          0     0         98     0
>  >          2     0        112          0     0         98     0
>  >          0     0          0          0     0         98     0
>  >          4     0        350         18     0        140     0
>  >          2     0        112          0     0          0     0
>  >          1     1         56          0     0          0     0
>  >          1     0         56          0     0          0     0
>  >          0     0          0          0     0          0     0
>  > ^C
>  > 
>  > Here is a tcpdump of the same event:
>  > 
>  > 18:40:59.025364 arp who-has 10.1.1.72 tell 10.1.7.250
>  > 18:41:00.049385 arp who-has 10.1.1.72 tell 10.1.7.250
>  > 18:41:00.868608 arp who-has 10.1.6.253 tell 10.1.7.250
>  > 18:41:01.073387 arp who-has 10.1.1.72 tell 10.1.7.250
>  > 18:41:02.761445 IP 10.1.1.107 > 193.10.65.193: ICMP echo request, id 63239, seq 0, length 64
>  > 18:41:02.761456 IP 10.1.1.107 > 193.10.65.193: ICMP echo request, id 63239, seq 1, length 64
>  > 18:41:02.761461 IP 10.1.1.107 > 193.10.65.193: ICMP echo request, id 63239, seq 2, length 64
>  > 18:41:02.761466 IP 10.1.1.107 > 193.10.65.193: ICMP echo request, id 63239, seq 3, length 64
>  > 18:41:02.761470 IP 10.1.1.107 > 193.10.65.193: ICMP echo request, id 63239, seq 4, length 64
>  > 18:41:02.761474 IP 10.1.1.107 > 193.10.65.193: ICMP echo request, id 63239, seq 5, length 64
>  > 18:41:02.761479 IP 10.1.1.107 > 193.10.65.193: ICMP echo request, id 63239, seq 6, length 64
>  > 18:41:02.761483 IP 10.1.1.107 > 193.10.65.193: ICMP echo request, id 63239, seq 7, length 64
>  > 18:41:02.761487 IP 10.1.1.107 > 193.10.65.193: ICMP echo request, id 63239, seq 8, length 64
>  > 18:41:02.761492 IP 10.1.1.107 > 193.10.65.193: ICMP echo request, id 63239, seq 9, length 64
>  > 18:41:02.761497 IP 10.1.1.107 > 193.10.65.193: ICMP echo request, id 63239, seq 10, length 64
>  > 18:41:02.761502 IP 10.1.1.107 > 193.10.65.193: ICMP echo request, id 63239, seq 11, length 64
>  > 18:41:02.761506 IP 10.1.1.107 > 193.10.65.193: ICMP echo request, id 63239, seq 12, length 64
>  > 18:41:02.761510 IP 10.1.1.107 > 193.10.65.193: ICMP echo request, id 63239, seq 13, length 64
>  > 18:41:02.761515 IP 10.1.1.107 > 193.10.65.193: ICMP echo request, id 63239, seq 14, length 64
>  > 18:41:02.761519 IP 10.1.1.107 > 193.10.65.193: ICMP echo request, id 63239, seq 15, length 64
>  > 18:41:02.761523 IP 10.1.1.107 > 193.10.65.193: ICMP echo request, id 63239, seq 16, length 64
>  > 18:41:02.916556 arp who-has 10.1.1.107 tell 10.1.7.250
>  > 18:41:02.916579 arp reply 10.1.1.107 is-at 00:05:4e:4e:1f:c7
>  > 18:41:02.917707 IP 193.10.65.193 > 10.1.1.107: ICMP echo reply, id 63239, seq 14, length 64
>  > 18:41:02.917906 IP 193.10.65.193 > 10.1.1.107: ICMP echo reply, id 63239, seq 15, length 64
>  > 18:41:02.918187 IP 193.10.65.193 > 10.1.1.107: ICMP echo reply, id 63239, seq 16, length 64
>  > 18:41:03.531108 arp who-has 10.1.1.72 tell 10.1.7.250
>  > 18:41:04.350185 arp who-has 10.1.6.166 tell 10.1.7.250
>  > 18:41:04.554984 arp who-has 10.1.1.72 tell 10.1.7.250
>  > 18:41:05.578972 arp who-has 10.1.1.72 tell 10.1.7.250
>  > ^C
>  > 289 packets captured
>  > 289 packets received by filter
>  > 0 packets dropped by kernel
>  > 
>  > Any idea on what the problem can be, or how do debug this further?
>
>   

You can use tcpdump to monitor traffic at multiple levels in the hierarchy:

tcpdump -i ath0 -n   # tap at 802.3 level
tcpdump -i ath0 -n -y IEEE802_11   # tap at 802.11 level
tcpdump -i ath0 -n -y IEEE802_11_RADIO   # tap at driver level

and/or you can check statistics using athstats and wlanstats or you can 
turn on debugging msgs in net80211 or the ath driver using wlandebug and 
athdebug.  Some of these may require you to build your kernel w/ debug 
options (e.g. ATH_DEBUG).

    Sam

From bengta at sics.se  Tue Feb 10 09:40:19 2009
From: bengta at sics.se (Bengt Ahlgren)
Date: Tue Feb 10 09:40:24 2009
Subject: Problems with ath at kern.hz=100
In-Reply-To: <4991ABA0.4050300@freebsd.org> (Sam Leffler's message of "Tue\,
	10 Feb 2009 08\:30\:24 -0800")
References: <uh7iqnjzzi9.fsf@P142.sics.se>
	<20090210154047.N38905@sola.nimnet.asn.au>
	<4991ABA0.4050300@freebsd.org>
Message-ID: <uh7fximfatw.fsf@P142.sics.se>

Sam Leffler <sam@freebsd.org> writes:

> Ian Smith wrote:
>> On Mon, 9 Feb 2009, Bengt Ahlgren wrote:

[...]

>> Sam has talked of a problem with ath (and maybe other) interrupt
>> rates overwhelming slow CPUs to the extent that userland (ie powerd)
>> doesn't get a look-in for a while, as I understand it.  A fast CPU
>> clocked back to less than say 300MHz IS a slow CPU, until powerd
>> gets to crank it up.
>>   
>
> If powerd starvation were happening you'd see livelock not slow
> traffic.  The problem was that MIB overflow interrupts from the card
> were pounding the host but since the cpu clock was lowered they were
> not serviced fast enough.
>
> FWIW I believe the MIB interrupt storm issue is fixed in head.  I
> posted a patch to stable@ to enable backmerge of the necessary code
> but received ~zero feedback in >1 month so RELENG_7 will continue to
> rot w/ old code.

The system was not livelocked - it was fully working except for ath
not sending out packets.  I can however try the patch if you think it
is worthwhile.

[...]

>>  >  > Any idea on what the problem can be, or how do debug this
>> further?
>>
>>   
>
> You can use tcpdump to monitor traffic at multiple levels in the hierarchy:
>
> tcpdump -i ath0 -n   # tap at 802.3 level
> tcpdump -i ath0 -n -y IEEE802_11   # tap at 802.11 level
> tcpdump -i ath0 -n -y IEEE802_11_RADIO   # tap at driver level
>
> and/or you can check statistics using athstats and wlanstats or you
> can turn on debugging msgs in net80211 or the ath driver using
> wlandebug and athdebug.  Some of these may require you to build your
> kernel w/ debug options (e.g. ATH_DEBUG).

Does the following mean anything to you?  I did athdebug
watchdog+xmit+calibrate+xmit_proc - more or less random choice, since
I don't know what it really means.  I see a lot of those
ath_calibrate:s with low "x" in "next +x" when it is not sending.
When it is operating normally, it mostly says "next +30" with "tries
0".  But there is no strict correlation, it can sometimes send packets
even when it says "!iqCalDone".

ath_tx_dmasetup: m 0xc37d4a00 len 178
TODS 00:05:4e:4e:1f:c7->00:14:4f:0f:ae:f6(00:13:1a:47:7a:33) data 54M
 0801 2c00 0013 1a47 7a33 0005 4e4e 1fc7 0014 4f0f aef6 f007 aaaa 0300 0000 0800 4500 0092 0128 4000 4006 3426 c10a 42fd c10a 4006 f506 008f 3433 0198 3326 9ce6 5018 ffff c1f2 0000 1703 0100 200d 2e0f 8857 2590 18d0 745b ce33 3874 4089 c851 5aab e5de ef81 8a43 ab98 ad4b 8b17 0301 0040 6b34 58a9 a0e4 b41b 9868 fa90 c69c 95a3 dc6c 99f9 c942 1bf4 219d 5b5f 5711 174d a810 c6d8 2dff 0c88 bb42 c566 6eae 8b7c acff bba3 847b 09d0 a77a e597 fc87 a6c8
ath_tx_handoff: 0: 00000000 014cea3c c12200b6 0000a0b2 0004006c 01e0000c
ath_tx_handoff: link[1](0xdecd8900)=0x14b1bcc0 (0xdecd8cc0) depth 2
ath_tx_processq: tx queue 1 head 0x14b1bcc0 link 0xdecd8cc0
ath_tx_dmasetup: m 0xc37d7800 len 162
TODS 00:05:4e:4e:1f:c7->00:14:4f:0f:ae:f6(00:13:1a:47:7a:33) data 54M
 0801 2c00 0013 1a47 7a33 0005 4e4e 1fc7 0014 4f0f aef6 0008 aaaa 0300 0000 0800 4500 0082 0129 4000 4006 3435 c10a 42fd c10a 4006 f506 008f 3433 0202 3326 9d4b 5018 ffff 24fa 0000 1703 0100 206c 06b7 7a5e 1427 c691 772f b923 07be 4c94 4fa0 80e8 4130 5192 e751 970e 8092 c617 0301 0030 0124 d75d c26b 0a82 13ce 8044 73e8 2cb1 74ab d1f9 ce01 5aca 116d f95c 79db 058e 6f58 c86d 51d2 31b9 345d 02b4 836e fb26
ath_tx_handoff: 0: 00000000 014d183c c12200a6 0000a0a2 0004006c 01e0000c
ath_tx_handoff: link[1](0xdecd8cc0)=0x14b1c080 (0xdecd9080) depth 2
ath_tx_processq: tx queue 1 head 0x14b1c080 link 0xdecd9080
ath_tx_dmasetup: m 0xc37d5200 len 162
TODS 00:05:4e:4e:1f:c7->00:14:4f:0f:ae:f6(00:13:1a:47:7a:33) data 54M
 0801 2c00 0013 1a47 7a33 0005 4e4e 1fc7 0014 4f0f aef6 1008 aaaa 0300 0000 0800 4500 0082 012a 4000 4006 3434 c10a 42fd c10a 4006 f506 008f 3433 025c 3326 9db0 5018 ffff 0df1 0000 1703 0100 20bf 5e4c fea5 c3d7 37af 29f1 3071 9791 6e7d 5cad 559b 00aa 204b e704 eea9 58b4 8017 0301 0030 f92c e0f3 3511 5618 19db fb48 5408 86d2 365b 3a0a ca5a 86c0 cd67 3b33 1333 3a73 ed6a 4410 491a e454 5901 e1b3 4e33 d3f8
ath_tx_handoff: 0: 00000000 014cf23c c12200a6 0000a0a2 0004006c 01e0000c
ath_tx_handoff: link[1](0xdecd9080)=0x14b1c440 (0xdecd9440) depth 2
ath_tx_processq: tx queue 1 head 0x14b1c440 link 0xdecd9440
ath_tx_dmasetup: m 0xc37d4200 len 109
TODS 00:05:4e:4e:1f:c7->00:14:4f:0f:ae:f6(00:13:1a:47:7a:33) data 54M
 0801 2c00 0013 1a47 7a33 0005 4e4e 1fc7 0014 4f0f aef6 2008 aaaa 0300 0000 0800 4500 004d 012b 4000 4006 3468 c10a 42fd c10a 4006 f506 008f 3433 02b6 3326 9e05 5018 ffff a6cb 0000 1503 0100 20c4 db33 8cb3 dbfd 8f42 a0da 812c 1415 7ccd 8031 ada1 d5b3 48f8 45d4 ad00 c2eb 47
ath_tx_handoff: 0: 00000000 014ce23c c1220071 0000a06d 00040064 01e0000c
ath_tx_handoff: link[1](0xdecd9440)=0x14b1c300 (0xdecd9300) depth 2
ath_tx_dmasetup: m 0xc37d3800 len 72
TODS 00:05:4e:4e:1f:c7->00:14:4f:0f:ae:f6(00:13:1a:47:7a:33) data 54M
 0801 2c00 0013 1a47 7a33 0005 4e4e 1fc7 0014 4f0f aef6 3008 aaaa 0300 0000 0800 4500 0028 012c 4000 4006 348c c10a 42fd c10a 4006 f506 008f 3433 02db 3326 9e05 5011 ffff aceb 0000
ath_tx_handoff: 0: 00000000 014cd83c c122004c 0000a048 0004005c 01e0000c
ath_tx_handoff: link[1](0xdecd9300)=0x14b1ca80 (0xdecd9a80) depth 3
ath_tx_processq: tx queue 1 head 0x14b1ca80 link 0xdecd9a80
ath_calibrate: next +2 (!iqCalDone tries 2)
ath_calibrate: next +2 (!iqCalDone tries 3)
ath_calibrate: next +2 (!iqCalDone tries 4)
ath_calibrate: next +4 (!iqCalDone tries 0)
ath_calibrate: next +4 (!iqCalDone tries 1)
ath_calibrate: next +4 (!iqCalDone tries 2)
ath_calibrate: next +4 (!iqCalDone tries 3)

After a while I also saw some:

ath0: [00:13:1a:47:7a:33] pwr save q overflow, drops 19 (size 50)

athstats says:

[root@P142 ~]# athstats
306      data frames received
335      data frames transmit
336      long on-chip tx retries
48       tx failed 'cuz too many retries
48M      current transmit rate
9        beacon miss interrupts
107      tx management frames
199      tx frames discarded prior to association
78       tx frames with no ack marked
407      tx frames with short preamble
259      tx frames with 11g protection
11791    rx failed 'cuz of bad CRC
201147   rx failed 'cuz of PHY err
    116925   OFDM timing
    1        OFDM restart
    84126    CCK timing
    95       CCK restart
243      periodic calibrations
31       avg recv rssi
-97      rx noise floor
4997     switched default/rx antenna
Antenna profile:
[1] tx      363 rx    53933
[2] tx       14 rx    18762

and ifconfig -v:

ath0: flags=8847<UP,BROADCAST,DEBUG,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        ether 00:05:4e:4e:1f:c7
        inet 193.10.66.253 netmask 0xfffffc00 broadcast 193.10.67.255
        media: IEEE 802.11 Wireless Ethernet autoselect (OFDM/48Mbps)
        status: associated
        ssid SICS channel 11 (2462 Mhz 11g) bssid 00:13:1a:47:7a:33
        authmode OPEN privacy OFF deftxkey UNDEF powersavemode OFF
        powersavesleep 100 txpower 31.5 txpowmax 17.0 rtsthreshold 2346
        fragthreshold 2346 bmiss 7 scanvalid 60 bgscan bgscanintvl 300
        bgscanidle 250 roam:rssi11a 7 roam:rate11a 12 roam:rssi11b 7
        roam:rate11b 1 roam:rssi11g 7 roam:rate11g 5 -pureg protmode CTS -ht
        -htcompat -ampdu ampdulimit 8k ampdudensity - -amsdu -shortgi
        htprotmode RTSCTS -puren -wme burst -ff -dturbo roaming AUTO
        bintval 100

Bengt
From sam at freebsd.org  Tue Feb 10 11:53:05 2009
From: sam at freebsd.org (Sam Leffler)
Date: Tue Feb 10 11:53:11 2009
Subject: Problems with ath at kern.hz=100
In-Reply-To: <uh7fximfatw.fsf@P142.sics.se>
References: <uh7iqnjzzi9.fsf@P142.sics.se>	<20090210154047.N38905@sola.nimnet.asn.au>	<4991ABA0.4050300@freebsd.org>
	<uh7fximfatw.fsf@P142.sics.se>
Message-ID: <4991DB1F.7060809@freebsd.org>

Bengt Ahlgren wrote:
> Sam Leffler <sam@freebsd.org> writes:
>
>   
>> Ian Smith wrote:
>>     
>>> On Mon, 9 Feb 2009, Bengt Ahlgren wrote:
>>>       
>
> [...]
>
>   
>>> Sam has talked of a problem with ath (and maybe other) interrupt
>>> rates overwhelming slow CPUs to the extent that userland (ie powerd)
>>> doesn't get a look-in for a while, as I understand it.  A fast CPU
>>> clocked back to less than say 300MHz IS a slow CPU, until powerd
>>> gets to crank it up.
>>>   
>>>       
>> If powerd starvation were happening you'd see livelock not slow
>> traffic.  The problem was that MIB overflow interrupts from the card
>> were pounding the host but since the cpu clock was lowered they were
>> not serviced fast enough.
>>
>> FWIW I believe the MIB interrupt storm issue is fixed in head.  I
>> posted a patch to stable@ to enable backmerge of the necessary code
>> but received ~zero feedback in >1 month so RELENG_7 will continue to
>> rot w/ old code.
>>     
>
> The system was not livelocked - it was fully working except for ath
> not sending out packets.  I can however try the patch if you think it
> is worthwhile.
>
> [...]
>
>   
>>>  >  > Any idea on what the problem can be, or how do debug this
>>> further?
>>>
>>>   
>>>       
>> You can use tcpdump to monitor traffic at multiple levels in the hierarchy:
>>
>> tcpdump -i ath0 -n   # tap at 802.3 level
>> tcpdump -i ath0 -n -y IEEE802_11   # tap at 802.11 level
>> tcpdump -i ath0 -n -y IEEE802_11_RADIO   # tap at driver level
>>
>> and/or you can check statistics using athstats and wlanstats or you
>> can turn on debugging msgs in net80211 or the ath driver using
>> wlandebug and athdebug.  Some of these may require you to build your
>> kernel w/ debug options (e.g. ATH_DEBUG).
>>     
>
> Does the following mean anything to you?  I did athdebug
> watchdog+xmit+calibrate+xmit_proc - more or less random choice, since
> I don't know what it really means.  I see a lot of those
> ath_calibrate:s with low "x" in "next +x" when it is not sending.
> When it is operating normally, it mostly says "next +30" with "tries
> 0".  But there is no strict correlation, it can sometimes send packets
> even when it says "!iqCalDone".
>   

Typically you want to work from the top down; turning on athdebug gives 
you info at the lowest parts of the system which rarely is meaningful 
unless you've already narrowed down a problem.

> ath_tx_dmasetup: m 0xc37d4a00 len 178
> TODS 00:05:4e:4e:1f:c7->00:14:4f:0f:ae:f6(00:13:1a:47:7a:33) data 54M
>  0801 2c00 0013 1a47 7a33 0005 4e4e 1fc7 0014 4f0f aef6 f007 aaaa 0300 0000 0800 4500 0092 0128 4000 4006 3426 c10a 42fd c10a 4006 f506 008f 3433 0198 3326 9ce6 5018 ffff c1f2 0000 1703 0100 200d 2e0f 8857 2590 18d0 745b ce33 3874 4089 c851 5aab e5de ef81 8a43 ab98 ad4b 8b17 0301 0040 6b34 58a9 a0e4 b41b 9868 fa90 c69c 95a3 dc6c 99f9 c942 1bf4 219d 5b5f 5711 174d a810 c6d8 2dff 0c88 bb42 c566 6eae 8b7c acff bba3 847b 09d0 a77a e597 fc87 a6c8
> ath_tx_handoff: 0: 00000000 014cea3c c12200b6 0000a0b2 0004006c 01e0000c
> ath_tx_handoff: link[1](0xdecd8900)=0x14b1bcc0 (0xdecd8cc0) depth 2
> ath_tx_processq: tx queue 1 head 0x14b1bcc0 link 0xdecd8cc0
> ath_tx_dmasetup: m 0xc37d7800 len 162
> TODS 00:05:4e:4e:1f:c7->00:14:4f:0f:ae:f6(00:13:1a:47:7a:33) data 54M
>  0801 2c00 0013 1a47 7a33 0005 4e4e 1fc7 0014 4f0f aef6 0008 aaaa 0300 0000 0800 4500 0082 0129 4000 4006 3435 c10a 42fd c10a 4006 f506 008f 3433 0202 3326 9d4b 5018 ffff 24fa 0000 1703 0100 206c 06b7 7a5e 1427 c691 772f b923 07be 4c94 4fa0 80e8 4130 5192 e751 970e 8092 c617 0301 0030 0124 d75d c26b 0a82 13ce 8044 73e8 2cb1 74ab d1f9 ce01 5aca 116d f95c 79db 058e 6f58 c86d 51d2 31b9 345d 02b4 836e fb26
> ath_tx_handoff: 0: 00000000 014d183c c12200a6 0000a0a2 0004006c 01e0000c
> ath_tx_handoff: link[1](0xdecd8cc0)=0x14b1c080 (0xdecd9080) depth 2
> ath_tx_processq: tx queue 1 head 0x14b1c080 link 0xdecd9080
> ath_tx_dmasetup: m 0xc37d5200 len 162
> TODS 00:05:4e:4e:1f:c7->00:14:4f:0f:ae:f6(00:13:1a:47:7a:33) data 54M
>  0801 2c00 0013 1a47 7a33 0005 4e4e 1fc7 0014 4f0f aef6 1008 aaaa 0300 0000 0800 4500 0082 012a 4000 4006 3434 c10a 42fd c10a 4006 f506 008f 3433 025c 3326 9db0 5018 ffff 0df1 0000 1703 0100 20bf 5e4c fea5 c3d7 37af 29f1 3071 9791 6e7d 5cad 559b 00aa 204b e704 eea9 58b4 8017 0301 0030 f92c e0f3 3511 5618 19db fb48 5408 86d2 365b 3a0a ca5a 86c0 cd67 3b33 1333 3a73 ed6a 4410 491a e454 5901 e1b3 4e33 d3f8
> ath_tx_handoff: 0: 00000000 014cf23c c12200a6 0000a0a2 0004006c 01e0000c
> ath_tx_handoff: link[1](0xdecd9080)=0x14b1c440 (0xdecd9440) depth 2
> ath_tx_processq: tx queue 1 head 0x14b1c440 link 0xdecd9440
> ath_tx_dmasetup: m 0xc37d4200 len 109
> TODS 00:05:4e:4e:1f:c7->00:14:4f:0f:ae:f6(00:13:1a:47:7a:33) data 54M
>  0801 2c00 0013 1a47 7a33 0005 4e4e 1fc7 0014 4f0f aef6 2008 aaaa 0300 0000 0800 4500 004d 012b 4000 4006 3468 c10a 42fd c10a 4006 f506 008f 3433 02b6 3326 9e05 5018 ffff a6cb 0000 1503 0100 20c4 db33 8cb3 dbfd 8f42 a0da 812c 1415 7ccd 8031 ada1 d5b3 48f8 45d4 ad00 c2eb 47
> ath_tx_handoff: 0: 00000000 014ce23c c1220071 0000a06d 00040064 01e0000c
> ath_tx_handoff: link[1](0xdecd9440)=0x14b1c300 (0xdecd9300) depth 2
> ath_tx_dmasetup: m 0xc37d3800 len 72
> TODS 00:05:4e:4e:1f:c7->00:14:4f:0f:ae:f6(00:13:1a:47:7a:33) data 54M
>  0801 2c00 0013 1a47 7a33 0005 4e4e 1fc7 0014 4f0f aef6 3008 aaaa 0300 0000 0800 4500 0028 012c 4000 4006 348c c10a 42fd c10a 4006 f506 008f 3433 02db 3326 9e05 5011 ffff aceb 0000
> ath_tx_handoff: 0: 00000000 014cd83c c122004c 0000a048 0004005c 01e0000c
> ath_tx_handoff: link[1](0xdecd9300)=0x14b1ca80 (0xdecd9a80) depth 3
> ath_tx_processq: tx queue 1 head 0x14b1ca80 link 0xdecd9a80
> ath_calibrate: next +2 (!iqCalDone tries 2)
> ath_calibrate: next +2 (!iqCalDone tries 3)
> ath_calibrate: next +2 (!iqCalDone tries 4)
> ath_calibrate: next +4 (!iqCalDone tries 0)
> ath_calibrate: next +4 (!iqCalDone tries 1)
> ath_calibrate: next +4 (!iqCalDone tries 2)
> ath_calibrate: next +4 (!iqCalDone tries 3)
>
> After a while I also saw some:
>
> ath0: [00:13:1a:47:7a:33] pwr save q overflow, drops 19 (size 50)
>   

Er, did you ever say you were operating in ap mode?

> athstats says:
>
> [root@P142 ~]# athstats
> 306      data frames received
> 335      data frames transmit
> 336      long on-chip tx retries
> 48       tx failed 'cuz too many retries
> 48M      current transmit rate
> 9        beacon miss interrupts
> 107      tx management frames
> 199      tx frames discarded prior to association
> 78       tx frames with no ack marked
> 407      tx frames with short preamble
> 259      tx frames with 11g protection
> 11791    rx failed 'cuz of bad CRC
> 201147   rx failed 'cuz of PHY err
>     116925   OFDM timing
>     1        OFDM restart
>     84126    CCK timing
>     95       CCK restart
> 243      periodic calibrations
> 31       avg recv rssi
> -97      rx noise floor
> 4997     switched default/rx antenna
> Antenna profile:
> [1] tx      363 rx    53933
> [2] tx       14 rx    18762
>
> and ifconfig -v:
>
> ath0: flags=8847<UP,BROADCAST,DEBUG,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
>         ether 00:05:4e:4e:1f:c7
>         inet 193.10.66.253 netmask 0xfffffc00 broadcast 193.10.67.255
>         media: IEEE 802.11 Wireless Ethernet autoselect (OFDM/48Mbps)
>         status: associated
>         ssid SICS channel 11 (2462 Mhz 11g) bssid 00:13:1a:47:7a:33
>         authmode OPEN privacy OFF deftxkey UNDEF powersavemode OFF
>         powersavesleep 100 txpower 31.5 txpowmax 17.0 rtsthreshold 2346
>         fragthreshold 2346 bmiss 7 scanvalid 60 bgscan bgscanintvl 300
>         bgscanidle 250 roam:rssi11a 7 roam:rate11a 12 roam:rssi11b 7
>         roam:rate11b 1 roam:rssi11g 7 roam:rate11g 5 -pureg protmode CTS -ht
>         -htcompat -ampdu ampdulimit 8k ampdudensity - -amsdu -shortgi
>         htprotmode RTSCTS -puren -wme burst -ff -dturbo roaming AUTO
>         bintval 100
>
>   
You've removed all the context of the original problem; I can't recall 
what you were trying to fix.  The ps q drops might be caused by a bug 
that was fixed (I think in RELENG_7).  I don't see what version of code 
you're running so can't tell.

    Sam

From lists at braisel.com  Wed Feb 11 05:47:48 2009
From: lists at braisel.com (=?iso-8859-1?Q?Andr=E9?= Braselmann)
Date: Wed Feb 11 05:47:57 2009
Subject: Acer 5101 AWLMI
Message-ID: <20090211132939.GA845@trashbin.none.lan>

Hi there,

i've got that "crappy" model from Acer mentioned above. "Crappy" because
the Acer 5100 series is famous for broken motherboards, ideally when
you are just 2 month out of the guarantee time.

Anyway, the USB Ports are broken under any OS, EHCI produces just
errors. This machine is running with 7.1-R amd64 smoothy, also acpi for
the battery is working. Below is a dmesg from a kernel built 
with removed ehci/ohci/uhci devices.

What's really annoying is that the synaptics trackpad is hanging after
approx. 3 seconds of moving the mouse pointer (console also in xorg),
moused says in foreground/debug mode nothing. This also occurs under 
OpenBSD 4.4 amd64 and in ubuntu versions prior to 8.10. 
Anyone seen that behaviour before? Or just broken?

The other question: sysctl says S3/S4/S5 states are supported. But when i
invoke them, it says that it's not supported??? Under ubuntu 8.10
hibernate2disk is supported and works out of the box (sorry for mentioning it
;-)

ThX
                                                                 
K.Andr? Braselmann
--
"I have a good reason for finding the system inappropriate 
 for my intended deployment platform"

--- snip dmesg ---

Copyright (c) 1992-2009 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
	The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 7.1-RELEASE #0: Sun Feb  8 18:28:05 CET 2009
    root@trashbin.none.lan:/usr/obj/usr/src/sys/TRASHBIN
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: AMD Turion(tm) 64 Mobile Technology MK-36 (1995.01-MHz K8-class CPU)
  Origin = "AuthenticAMD"  Id = 0x40fc2  Stepping = 2
  Features=0x78bfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2>
  Features2=0x2001<SSE3,CX16>
  AMD Features=0xea500800<SYSCALL,NX,MMX+,FFXSR,RDTSCP,LM,3DNow!+,3DNow!>
  AMD Features2=0x1d<LAHF,SVM,ExtAPIC,CR8>
usable memory = 2068725760 (1972 MB)
avail memory  = 1996247040 (1903 MB)
ACPI APIC Table: <PTLTD  	 APIC  >
MADT: Forcing active-low polarity and level trigger for SCI
ioapic0 <Version 2.1> irqs 0-23 on motherboard
kbd1 at kbdmux0
ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413)
acpi0: <ACRSYS ACRPRDCT> on motherboard
acpi0: [ITHREAD]
acpi0: Power Button (fixed)
acpi0: reservation of 0, 1000 (3) failed
Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000
acpi_timer0: <32-bit timer at 3.579545MHz> port 0x8008-0x800b on acpi0
acpi_ec0: <Embedded Controller: GPE 0x10> port 0x62,0x66 on acpi0
acpi_lid0: <Control Method Lid Switch> on acpi0
acpi_button0: <Power Button> on acpi0
acpi_button1: <Sleep Button> on acpi0
pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
pci0: <ACPI PCI bus> on pcib0
pcib1: <ACPI PCI-PCI bridge> at device 1.0 on pci0
pci1: <ACPI PCI bus> on pcib1
vgapci0: <VGA-compatible display> port 0x9000-0x90ff mem 0xf8000000-0xfbffffff,0xfc000000-0xfc00ffff irq 17 at device 5.0 on pci1
acpi_video0: <ACPI video extension> on vgapci0
pcib2: <ACPI PCI-PCI bridge> at device 4.0 on pci0
pci2: <ACPI PCI bus> on pcib2
pcib3: <ACPI PCI-PCI bridge> at device 5.0 on pci0
pci4: <ACPI PCI bus> on pcib3
pci0: <serial bus, USB> at device 19.0 (no driver attached)
pci0: <serial bus, USB> at device 19.1 (no driver attached)
pci0: <serial bus, USB> at device 19.2 (no driver attached)
pci0: <serial bus, SMBus> at device 20.0 (no driver attached)
atapci0: <ATI IXP400 UDMA133 controller> port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x8420-0x842f at device 20.1 on pci0
ata0: <ATA channel 0> on atapci0
ata0: [ITHREAD]
ata1: <ATA channel 1> on atapci0
ata1: [ITHREAD]
pcm0: <ATI SB450 High Definition Audio Controller> mem 0xfc400000-0xfc403fff irq 16 at device 20.2 on pci0
pcm0: [ITHREAD]
isab0: <PCI-ISA bridge> at device 20.3 on pci0
isa0: <ISA bus> on isab0
pcib4: <ACPI PCI-PCI bridge> at device 20.4 on pci0
pci6: <ACPI PCI bus> on pcib4
rl0: <RealTek 8139 10/100BaseTX> port 0xa000-0xa0ff mem 0xfc100000-0xfc1000ff irq 21 at device 1.0 on pci6
miibus0: <MII bus> on rl0
rlphy0: <RealTek internal media interface> PHY 0 on miibus0
rlphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
rl0: Ethernet address: 00:16:d4:1e:53:06
rl0: [ITHREAD]
ath0: <Atheros 5212> mem 0xfc110000-0xfc11ffff irq 22 at device 2.0 on pci6
ath0: [ITHREAD]
ath0: WARNING: using obsoleted if_watchdog interface
ath0: Ethernet address: 00:16:cf:6d:49:81
ath0: mac 7.8 phy 4.5 radio 5.6
cbb0: <PCI-CardBus Bridge> mem 0xfc101000-0xfc101fff irq 20 at device 4.0 on pci6
cardbus0: <CardBus bus> on cbb0
pccard0: <16-bit PCCard bus> on cbb0
cbb0: [ITHREAD]
pci6: <memory, flash> at device 4.1 (no driver attached)
pci6: <base peripheral> at device 4.2 (no driver attached)
pci6: <memory, flash> at device 4.3 (no driver attached)
pci6: <memory, flash> at device 4.4 (no driver attached)
acpi_tz0: <Thermal Zone> on acpi0
atkbdc0: <Keyboard controller (i8042)> port 0x60,0x64 irq 1 on acpi0
atkbd0: <AT Keyboard> irq 1 on atkbdc0
kbd0 at atkbd0
atkbd0: [GIANT-LOCKED]
atkbd0: [ITHREAD]
psm0: <PS/2 Mouse> irq 12 on atkbdc0
psm0: [GIANT-LOCKED]
psm0: [ITHREAD]
psm0: model Generic PS/2 mouse, device ID 0
battery0: <ACPI Control Method Battery> on acpi0
acpi_acad0: <AC Adapter> on acpi0
cpu0: <ACPI CPU> on acpi0
powernow0: <PowerNow! K8> on cpu0
orm0: <ISA Option ROM> at iomem 0xc0000-0xcefff on isa0
ppc0: cannot reserve I/O port range
sc0: <System console> at flags 0x100 on isa0
sc0: VGA <16 virtual consoles, flags=0x300>
sio0: configured irq 4 not in bitmap of probed irqs 0
sio0: port may not be enabled
sio0: configured irq 4 not in bitmap of probed irqs 0
sio0: port may not be enabled
sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0
sio0: type 8250 or not responding
sio0: [FILTER]
sio1: configured irq 3 not in bitmap of probed irqs 0
sio1: port may not be enabled
vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
Timecounter "TSC" frequency 1995010378 Hz quality 800
Timecounters tick every 1.000 msec
ad0: 114473MB <Hitachi HTS541212H9AT00 HP4OA23C> at ata0-master UDMA100
acd0: DVDR <PHILIPS DVD-RAM SDVD8821/EY01> at ata0-slave UDMA33
pcm0: <HDA Codec: Realtek ALC883>
pcm0: <HDA Driver Revision: 20080420_0052>
Trying to mount root from ufs:/dev/ad0s1a
--- snap dmesg ---
From admin at lissyara.su  Wed Feb 11 09:42:17 2009
From: admin at lissyara.su (Alex Keda)
Date: Wed Feb 11 09:42:24 2009
Subject: Acer 5101 AWLMI
In-Reply-To: <20090211132939.GA845@trashbin.none.lan>
References: <20090211132939.GA845@trashbin.none.lan>
Message-ID: <49930898.7070605@lissyara.su>

Andr? Braselmann ?????:
> Hi there,
>
> i've got that "crappy" model from Acer mentioned above. "Crappy" because
> the Acer 5100 series is famous for broken motherboards, ideally when
> you are just 2 month out of the guarantee time.
>
> Anyway, the USB Ports are broken under any OS, EHCI produces just
> errors. This machine is running with 7.1-R amd64 smoothy, also acpi for
> the battery is working. Below is a dmesg from a kernel built 
> with removed ehci/ohci/uhci devices.
>   
With CURRENT, 2 or 3 month ago it works correct.
I do not how it laptop now, and cannot test today CURRENT with new USB2 
stack
> What's really annoying is that the synaptics trackpad is hanging after
> approx. 3 seconds of moving the mouse pointer (console also in xorg),
> moused says in foreground/debug mode nothing. This also occurs under 
> OpenBSD 4.4 amd64 and in ubuntu versions prior to 8.10. 
> Anyone seen that behaviour before? Or just broken?
>   
For CURRENT, I use
hw.psm.synaptics_support=1
in /boot/loader.conf
and all work OK, last year, or above
> The other question: sysctl says S3/S4/S5 states are supported. But when i
> invoke them, it says that it's not supported??? Under ubuntu 8.10
> hibernate2disk is supported and works out of the box (sorry for mentioning it
> ;-)
uname -a, please.
With amd64 it not work.

From jmt at twilley.org  Wed Feb 11 18:49:44 2009
From: jmt at twilley.org (Jack Twilley)
Date: Wed Feb 11 18:49:51 2009
Subject: Tethering with HTC Touch Pro -- how?
In-Reply-To: <498988F9.40106@mavhome.dp.ua>
References: <1233145383.00067348.1233133205@10.7.7.3>
	<49817333.8070708@mavhome.dp.ua> <49898716.701@unsane.co.uk>
	<498988F9.40106@mavhome.dp.ua>
Message-ID: <49938E13.4060102@twilley.org>

Alexander Motin wrote:
> Vincent Hoffman wrote:
>> On 29/1/09 09:13, Alexander Motin wrote:
>>> Jack Twilley wrote:
>>>   
>>>> I have enabled internet connection sharing on my HTC Touch Pro by
>>>> modifying the registry.  The phone works for tethering on my Vista box
>>>> as expected.  How do I make it work on FreeBSD?
>>>>     
>>> I am successfully using my Qtek S200 with WM6.1 as plain Bluetooth
>>> GPRS/EDGE modem. BT PAN profile could be better for internet sharing; I
>>> haven't seen it implemented, but there were some activity. Sharing via
>>> USB cable requires RNDIS support, which is also not implemented, AFAIK
>>> due to buggy and undocumented protocol.
>>>   
>> Just as a quick appendium, bluetooth PAN support got added to -CURRENT a
>> couple of days ago.
>>  I'll try and dig out my old HTC Hermes and test it, will report back if
>> I do.
> 
> I have even tested it already and replied on freebsd-bluetooth@. It
> works fine with my Qtek S200 with WM6.1.
> 

I went to the freebsd-bluetooth mailing list archives and saw that it 
worked, but nobody's actually posted anything on how to do it, starting 
from a system with a recent -CURRENT and a phone that can do the right 
thing.

I was able to use the FreeBSD Handbook chapter on Bluetooth to do stuff 
like successfully pair my phone and my laptop.  I was able to search for 
nap and opush with sdpcontrol and see a screen or so each of output but 
I didn't quite see what to do next.  The chapter talks about searching 
and browsing services, and I can run the commands and get output, but it 
doesn't quite make enough sense for me to move forward.  If you can 
document what you did to make it work, what commands and configuration 
files and all, that'd be really really helpful to those of us who aren't 
as familiar with Bluetooth as you guys and just want to tether our laptops.

Thanks!

Jack.
From mav at mavhome.dp.ua  Wed Feb 11 23:28:14 2009
From: mav at mavhome.dp.ua (Alexander Motin)
Date: Wed Feb 11 23:28:21 2009
Subject: Tethering with HTC Touch Pro -- how?
In-Reply-To: <1234419790.00074006.1234407602@10.7.7.3>
References: <1233145383.00067348.1233133205@10.7.7.3>
	<1233231789.00067817.1233220802@10.7.7.3>
	<1233761002.00070820.1233750002@10.7.7.3>
	<1233761005.00070824.1233750602@10.7.7.3>
	<1234419790.00074006.1234407602@10.7.7.3>
Message-ID: <4993CF8B.2030103@mavhome.dp.ua>

Jack Twilley wrote:
> Alexander Motin wrote:
>> Vincent Hoffman wrote:
>>> On 29/1/09 09:13, Alexander Motin wrote:
>>>> Jack Twilley wrote:
>>>>  
>>>>> I have enabled internet connection sharing on my HTC Touch Pro by
>>>>> modifying the registry.  The phone works for tethering on my Vista box
>>>>> as expected.  How do I make it work on FreeBSD?
>>>>>     
>>>> I am successfully using my Qtek S200 with WM6.1 as plain Bluetooth
>>>> GPRS/EDGE modem. BT PAN profile could be better for internet sharing; I
>>>> haven't seen it implemented, but there were some activity. Sharing via
>>>> USB cable requires RNDIS support, which is also not implemented, AFAIK
>>>> due to buggy and undocumented protocol.
>>>>   
>>> Just as a quick appendium, bluetooth PAN support got added to -CURRENT a
>>> couple of days ago.
>>>  I'll try and dig out my old HTC Hermes and test it, will report back if
>>> I do.
>>
>> I have even tested it already and replied on freebsd-bluetooth@. It
>> works fine with my Qtek S200 with WM6.1.
> 
> I went to the freebsd-bluetooth mailing list archives and saw that it 
> worked, but nobody's actually posted anything on how to do it, starting 
> from a system with a recent -CURRENT and a phone that can do the right 
> thing.
> 
> I was able to use the FreeBSD Handbook chapter on Bluetooth to do stuff 
> like successfully pair my phone and my laptop.  I was able to search for 
> nap and opush with sdpcontrol and see a screen or so each of output but 
> I didn't quite see what to do next.  The chapter talks about searching 
> and browsing services, and I can run the commands and get output, but it 
> doesn't quite make enough sense for me to move forward.  If you can 
> document what you did to make it work, what commands and configuration 
> files and all, that'd be really really helpful to those of us who aren't 
> as familiar with Bluetooth as you guys and just want to tether our laptops.

I have written such script for myself:

#!/bin/sh

trap "/usr/bin/killall btpand" SIGINT

ifconfig tap10 create && \
btpand -d acer -a s200 -s NAP -i tap10 && \
sleep 1 && \
dhclient tap10 && \
echo Running... && \
while pgrep btpand >/dev/null
do
     sleep 2
done &&
printf 'Terminated\a'
echo
ifconfig tap10 destroy

acer is the my system name and s200 is my phone name, both addresses 
added to /etc/bluetooth/hosts. If devices are peered, no other 
configuration required. The only thing needed in my case is to l2ping 
phone several times before connecting, to wake it's BT up.

-- 
Alexander Motin
From mav at mavhome.dp.ua  Wed Feb 11 23:30:42 2009
From: mav at mavhome.dp.ua (Alexander Motin)
Date: Wed Feb 11 23:30:48 2009
Subject: Tethering with HTC Touch Pro -- how?
In-Reply-To: <4993CF8B.2030103@mavhome.dp.ua>
References: <1233145383.00067348.1233133205@10.7.7.3>
	<1233231789.00067817.1233220802@10.7.7.3>
	<1233761002.00070820.1233750002@10.7.7.3>
	<1233761005.00070824.1233750602@10.7.7.3>
	<1234419790.00074006.1234407602@10.7.7.3>
	<4993CF8B.2030103@mavhome.dp.ua>
Message-ID: <4993D01F.5070507@mavhome.dp.ua>

Alexander Motin wrote:
> Jack Twilley wrote:
>> Alexander Motin wrote:
>>> Vincent Hoffman wrote:
>>>> On 29/1/09 09:13, Alexander Motin wrote:
>>>>> Jack Twilley wrote:
>>>>>  
>>>>>> I have enabled internet connection sharing on my HTC Touch Pro by
>>>>>> modifying the registry.  The phone works for tethering on my Vista 
>>>>>> box
>>>>>> as expected.  How do I make it work on FreeBSD?
>>>>>>     
>>>>> I am successfully using my Qtek S200 with WM6.1 as plain Bluetooth
>>>>> GPRS/EDGE modem. BT PAN profile could be better for internet 
>>>>> sharing; I
>>>>> haven't seen it implemented, but there were some activity. Sharing via
>>>>> USB cable requires RNDIS support, which is also not implemented, AFAIK
>>>>> due to buggy and undocumented protocol.
>>>>>   
>>>> Just as a quick appendium, bluetooth PAN support got added to 
>>>> -CURRENT a
>>>> couple of days ago.
>>>>  I'll try and dig out my old HTC Hermes and test it, will report 
>>>> back if
>>>> I do.
>>>
>>> I have even tested it already and replied on freebsd-bluetooth@. It
>>> works fine with my Qtek S200 with WM6.1.
>>
>> I went to the freebsd-bluetooth mailing list archives and saw that it 
>> worked, but nobody's actually posted anything on how to do it, 
>> starting from a system with a recent -CURRENT and a phone that can do 
>> the right thing.
>>
>> I was able to use the FreeBSD Handbook chapter on Bluetooth to do 
>> stuff like successfully pair my phone and my laptop.  I was able to 
>> search for nap and opush with sdpcontrol and see a screen or so each 
>> of output but I didn't quite see what to do next.  The chapter talks 
>> about searching and browsing services, and I can run the commands and 
>> get output, but it doesn't quite make enough sense for me to move 
>> forward.  If you can document what you did to make it work, what 
>> commands and configuration files and all, that'd be really really 
>> helpful to those of us who aren't as familiar with Bluetooth as you 
>> guys and just want to tether our laptops.
> 
> I have written such script for myself:
> 
> #!/bin/sh
> 
> trap "/usr/bin/killall btpand" SIGINT
> 
> ifconfig tap10 create && \
> btpand -d acer -a s200 -s NAP -i tap10 && \
> sleep 1 && \
> dhclient tap10 && \
> echo Running... && \
> while pgrep btpand >/dev/null
> do
>     sleep 2
> done &&
> printf 'Terminated\a'
> echo
> ifconfig tap10 destroy
> 
> acer is the my system name and s200 is my phone name, both addresses 
> added to /etc/bluetooth/hosts. If devices are peered, no other 
> configuration required. The only thing needed in my case is to l2ping 
> phone several times before connecting, to wake it's BT up.

Surely you should also run "Internet sharing" application on phone.

-- 
Alexander Motin
From smithi at nimnet.asn.au  Thu Feb 12 22:08:37 2009
From: smithi at nimnet.asn.au (Ian Smith)
Date: Thu Feb 12 22:08:44 2009
Subject: Problems with ath at kern.hz=100
In-Reply-To: <4991ABA0.4050300@freebsd.org>
References: <uh7iqnjzzi9.fsf@P142.sics.se>
	<20090210154047.N38905@sola.nimnet.asn.au>
	<4991ABA0.4050300@freebsd.org>
Message-ID: <20090213165848.N38905@sola.nimnet.asn.au>

On Tue, 10 Feb 2009, Sam Leffler wrote:
 > Ian Smith wrote:
 > > On Mon, 9 Feb 2009, Bengt Ahlgren wrote:
 > > 
 > >  > I was changing kern.hz to 100 on my IBM X40 (Pentium-M) laptop to see
 > >  > whether that saves some battery, but ran into problems with ath not
 > >  > working properly.  At first I thought that my hardware was failing,
 > >  > but changing hz back to 1000 solved the problem.  I am running
 > >  > 7.1-RELEASE-p1 and have the following Atheros chip:
 > >  >  > Feb  9 11:13:10 P142 kernel: ath_hal: 0.9.20.3 (AR5210, AR5211,
 > > AR5212, RF5111, RF5112, RF2413, RF5413)
 > >  > Feb  9 11:13:10 P142 kernel: ath0: <Atheros 5212> mem
 > > 0xd0200000-0xd020ffff irq 11 at device 2.0 on pci2
 > >  > Feb  9 11:13:10 P142 kernel: ath0: [ITHREAD]
 > >  > Feb  9 11:13:10 P142 kernel: ath0: WARNING: using obsoleted if_watchdog
 > > interface
 > >  > Feb  9 11:13:10 P142 kernel: ath0: Ethernet address: 00:05:4e:4e:1f:c7
 > >  > Feb  9 11:13:10 P142 kernel: ath0: mac 5.6 phy 4.1 5ghz radio 1.7 2ghz
 > > radio 2.3
 > > 
 > > There's an order of magnitude room to move between 100 and 1000 Hz.  You
 > > could also try with maybe 250 or 500?
 > > 
 > > What speed is your Pentium-M?  Are you using powerd?  If so, what minimum
 > > CPU freq does it drop back to (sysctl debug.cpufreq.lowest)?
 > > 
 > > Sam has talked of a problem with ath (and maybe other) interrupt rates
 > > overwhelming slow CPUs to the extent that userland (ie powerd) doesn't get
 > > a look-in for a while, as I understand it.  A fast CPU clocked back to less
 > > than say 300MHz IS a slow CPU, until powerd gets to crank it up.
 > >   
 > 
 > If powerd starvation were happening you'd see livelock not slow traffic.  The
 > problem was that MIB overflow interrupts from the card were pounding the host
 > but since the cpu clock was lowered they were not serviced fast enough.
 > 
 > FWIW I believe the MIB interrupt storm issue is fixed in head.  I posted a
 > patch to stable@ to enable backmerge of the necessary code but received ~zero
 > feedback in >1 month so RELENG_7 will continue to rot w/ old code.

Thanks for the clarification, Sam.

I did see your patch but due to ongoing Severe Weather Events here I've 
not had enough (solar) power to even upgrade my thinkpad to RELENG_7 for 
months, and the nearest access point is kilometres away, so I've had to 
shelve wireless dreaming until I can move house.  Lame excuses i know ..

[..]

 > You can use tcpdump to monitor traffic at multiple levels in the hierarchy:
 > 
 > tcpdump -i ath0 -n   # tap at 802.3 level
 > tcpdump -i ath0 -n -y IEEE802_11   # tap at 802.11 level
 > tcpdump -i ath0 -n -y IEEE802_11_RADIO   # tap at driver level
 > 
 > and/or you can check statistics using athstats and wlanstats or you can turn
 > on debugging msgs in net80211 or the ath driver using wlandebug and athdebug.
 > Some of these may require you to build your kernel w/ debug options (e.g.
 > ATH_DEBUG).

All filed for now.

cheers, Ian
From jmt at twilley.org  Fri Feb 13 14:01:56 2009
From: jmt at twilley.org (Jack Twilley)
Date: Fri Feb 13 14:02:03 2009
Subject: Tethering with HTC Touch Pro -- how?
In-Reply-To: <4993D01F.5070507@mavhome.dp.ua>
References: <1233145383.00067348.1233133205@10.7.7.3>	<1233231789.00067817.1233220802@10.7.7.3>	<1233761002.00070820.1233750002@10.7.7.3>	<1233761005.00070824.1233750602@10.7.7.3>	<1234419790.00074006.1234407602@10.7.7.3>	<4993CF8B.2030103@mavhome.dp.ua>
	<4993D01F.5070507@mavhome.dp.ua>
Message-ID: <4995EDCC.1090207@twilley.org>

Alexander Motin wrote:
> Alexander Motin wrote:
>> Jack Twilley wrote:
>>> Alexander Motin wrote:
>>>> Vincent Hoffman wrote:
>>>>> On 29/1/09 09:13, Alexander Motin wrote:
>>>>>> Jack Twilley wrote:
>>>>>>  
>>>>>>> I have enabled internet connection sharing on my HTC Touch Pro by
>>>>>>> modifying the registry.  The phone works for tethering on my 
>>>>>>> Vista box
>>>>>>> as expected.  How do I make it work on FreeBSD?
>>>>>>>     
>>>>>> I am successfully using my Qtek S200 with WM6.1 as plain Bluetooth
>>>>>> GPRS/EDGE modem. BT PAN profile could be better for internet 
>>>>>> sharing; I
>>>>>> haven't seen it implemented, but there were some activity. Sharing 
>>>>>> via
>>>>>> USB cable requires RNDIS support, which is also not implemented, 
>>>>>> AFAIK
>>>>>> due to buggy and undocumented protocol.
>>>>>>   
>>>>> Just as a quick appendium, bluetooth PAN support got added to 
>>>>> -CURRENT a
>>>>> couple of days ago.
>>>>>  I'll try and dig out my old HTC Hermes and test it, will report 
>>>>> back if
>>>>> I do.
>>>>
>>>> I have even tested it already and replied on freebsd-bluetooth@. It
>>>> works fine with my Qtek S200 with WM6.1.
>>>
>>> I went to the freebsd-bluetooth mailing list archives and saw that it 
>>> worked, but nobody's actually posted anything on how to do it, 
>>> starting from a system with a recent -CURRENT and a phone that can do 
>>> the right thing.
>>>
>>> I was able to use the FreeBSD Handbook chapter on Bluetooth to do 
>>> stuff like successfully pair my phone and my laptop.  I was able to 
>>> search for nap and opush with sdpcontrol and see a screen or so each 
>>> of output but I didn't quite see what to do next.  The chapter talks 
>>> about searching and browsing services, and I can run the commands and 
>>> get output, but it doesn't quite make enough sense for me to move 
>>> forward.  If you can document what you did to make it work, what 
>>> commands and configuration files and all, that'd be really really 
>>> helpful to those of us who aren't as familiar with Bluetooth as you 
>>> guys and just want to tether our laptops.
>>
>> I have written such script for myself:
>>
>> #!/bin/sh
>>
>> trap "/usr/bin/killall btpand" SIGINT
>>
>> ifconfig tap10 create && \
>> btpand -d acer -a s200 -s NAP -i tap10 && \
>> sleep 1 && \
>> dhclient tap10 && \
>> echo Running... && \
>> while pgrep btpand >/dev/null
>> do
>>     sleep 2
>> done &&
>> printf 'Terminated\a'
>> echo
>> ifconfig tap10 destroy
>>
>> acer is the my system name and s200 is my phone name, both addresses 
>> added to /etc/bluetooth/hosts. If devices are peered, no other 
>> configuration required. The only thing needed in my case is to l2ping 
>> phone several times before connecting, to wake it's BT up.
> 
> Surely you should also run "Internet sharing" application on phone.
> 

Your script was great.  I was able to get a connection, and DHCP 
configured the interface.  I was able to ping hosts on the Internet and 
resolve names, but I couldn't ssh to my colo box nor was I able to 
browse the web or chat via IM.  Still some work to be done but I can't 
blame FreeBSD. :-)

Thank you again for all your help!

Jack.
From ivakras1 at gmail.com  Sat Feb 14 06:10:08 2009
From: ivakras1 at gmail.com (Dmitry Kolosov)
Date: Sat Feb 14 06:10:15 2009
Subject: Tethering with HTC Touch Pro -- how?
In-Reply-To: <498988F9.40106@mavhome.dp.ua>
References: <1233145383.00067348.1233133205@10.7.7.3>
	<49898716.701@unsane.co.uk> <498988F9.40106@mavhome.dp.ua>
Message-ID: <200902141646.02359.ivakras1@gmail.com>

On Wednesday 04 February 2009 15:24:25 Alexander Motin wrote:
> Vincent Hoffman wrote:
> > On 29/1/09 09:13, Alexander Motin wrote:
> >> Jack Twilley wrote:
> >>> I have enabled internet connection sharing on my HTC Touch Pro by
> >>> modifying the registry.  The phone works for tethering on my Vista box
> >>> as expected.  How do I make it work on FreeBSD?
> >>
> >> I am successfully using my Qtek S200 with WM6.1 as plain Bluetooth
> >> GPRS/EDGE modem. BT PAN profile could be better for internet sharing; I
> >> haven't seen it implemented, but there were some activity. Sharing via
> >> USB cable requires RNDIS support, which is also not implemented, AFAIK
> >> due to buggy and undocumented protocol.
> >
> > Just as a quick appendium, bluetooth PAN support got added to -CURRENT a
> > couple of days ago.
> >  I'll try and dig out my old HTC Hermes and test it, will report back if
> > I do.
>
> I have even tested it already and replied on freebsd-bluetooth@. It
> works fine with my Qtek S200 with WM6.1.

I cant find any instrustions how\where to download\install\configure btpand for 
7-STABLE environment. Or maybe i should just wait some time and btpand will be 
included in 7-STABLE update? If so, how long that time will be?
From maksim.yevmenkin at gmail.com  Sat Feb 14 10:46:31 2009
From: maksim.yevmenkin at gmail.com (Maksim Yevmenkin)
Date: Sat Feb 14 10:46:37 2009
Subject: Tethering with HTC Touch Pro -- how?
In-Reply-To: <200902141646.02359.ivakras1@gmail.com>
References: <1233145383.00067348.1233133205@10.7.7.3>
	<49898716.701@unsane.co.uk> <498988F9.40106@mavhome.dp.ua>
	<200902141646.02359.ivakras1@gmail.com>
Message-ID: <bb4a86c70902141046g265e1416ie105f5adbcc21a65@mail.gmail.com>

On Sat, Feb 14, 2009 at 5:46 AM, Dmitry Kolosov <ivakras1@gmail.com> wrote:
> On Wednesday 04 February 2009 15:24:25 Alexander Motin wrote:
>> Vincent Hoffman wrote:
>> > On 29/1/09 09:13, Alexander Motin wrote:
>> >> Jack Twilley wrote:
>> >>> I have enabled internet connection sharing on my HTC Touch Pro by
>> >>> modifying the registry.  The phone works for tethering on my Vista box
>> >>> as expected.  How do I make it work on FreeBSD?
>> >>
>> >> I am successfully using my Qtek S200 with WM6.1 as plain Bluetooth
>> >> GPRS/EDGE modem. BT PAN profile could be better for internet sharing; I
>> >> haven't seen it implemented, but there were some activity. Sharing via
>> >> USB cable requires RNDIS support, which is also not implemented, AFAIK
>> >> due to buggy and undocumented protocol.
>> >
>> > Just as a quick appendium, bluetooth PAN support got added to -CURRENT a
>> > couple of days ago.
>> >  I'll try and dig out my old HTC Hermes and test it, will report back if
>> > I do.
>>
>> I have even tested it already and replied on freebsd-bluetooth@. It
>> works fine with my Qtek S200 with WM6.1.
>
> I cant find any instrustions how\where to download\install\configure btpand for
> 7-STABLE environment. Or maybe i should just wait some time and btpand will be
> included in 7-STABLE update? If so, how long that time will be?

svn/cvs is your friend :)

===

SVN rev 187938 on 2009-01-30 22:23:21Z by emax

Add btpand(8) daemon from NetBSD. This daemon provides support for
Bluetooth Network Access Point (NAP), Group Ad-hoc Network (GN) and
Personal Area Network User (PANU) profiles.

Obtained from:	NetBSD
MFC after:	1 month

===

thanks,
max
From webmaster at kibab.com  Sun Feb 15 09:40:35 2009
From: webmaster at kibab.com (Ilya Bakulin)
Date: Sun Feb 15 09:40:42 2009
Subject: Tethering with HTC Touch Pro -- how?
In-Reply-To: <4995EDCC.1090207@twilley.org>
References: <1233145383.00067348.1233133205@10.7.7.3>
	<1233231789.00067817.1233220802@10.7.7.3>
	<1233761002.00070820.1233750002@10.7.7.3>
	<1233761005.00070824.1233750602@10.7.7.3>
	<1234419790.00074006.1234407602@10.7.7.3>
	<4993CF8B.2030103@mavhome.dp.ua> <4993D01F.5070507@mavhome.dp.ua>
	<4995EDCC.1090207@twilley.org>
Message-ID: <20090215204025.51c16438.webmaster@kibab.com>

On Fri, 13 Feb 2009 14:01:48 -0800
Jack Twilley <jmt@twilley.org> wrote:

> Your script was great.  I was able to get a connection, and DHCP 
> configured the interface.  I was able to ping hosts on the Internet and 
> resolve names, but I couldn't ssh to my colo box nor was I able to 
> browse the web or chat via IM.  Still some work to be done but I can't 
> blame FreeBSD. :-)

You may try to use built-in Internet sharing on PDA.
Alternatively, look at ICSControl application (freeware), you may find it here: http://forum.xda-developers.com/showthread.php?t=377047

Using this utility you may turn on NAT in device. After that you should access Internet without problems. Tested it myself, works great.

-- 
Ilya Bakulin <webmaster@kibab.com>
xmpp://kibab612@jabber.ru
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-mobile/attachments/20090215/8dfc0a6b/attachment.pgp
From bengta at sics.se  Tue Feb 17 11:28:05 2009
From: bengta at sics.se (Bengt Ahlgren)
Date: Tue Feb 17 11:28:13 2009
Subject: Problems with ath at kern.hz=100
In-Reply-To: <4991DB1F.7060809@freebsd.org> (Sam Leffler's message of "Tue\,
	10 Feb 2009 11\:53\:03 -0800")
References: <uh7iqnjzzi9.fsf@P142.sics.se>
	<20090210154047.N38905@sola.nimnet.asn.au>
	<4991ABA0.4050300@freebsd.org> <uh7fximfatw.fsf@P142.sics.se>
	<4991DB1F.7060809@freebsd.org>
Message-ID: <uh7y6w4zwsq.fsf@P142.sics.se>

Sam Leffler <sam@freebsd.org> writes:

[...]

> You've removed all the context of the original problem; I can't recall
> what you were trying to fix.  The ps q drops might be caused by a bug
> that was fixed (I think in RELENG_7).  I don't see what version of
> code you're running so can't tell.

Sorry, a summary of the problem:

The system frequently comes into a state where outgoing packets are
held somewhere.  The condition persists for seconds to minutes.  It
goes away by itself, but some of the packets are usually lost.  This
occurs on ath, FreeBSD 7.1-REL, no SMP, with kern.hz=100 (but not with
hz=1000).  Original mail with description can be found here:

http://lists.freebsd.org/pipermail/freebsd-mobile/2009-February/011343.html

I have done some more investigation, inserting debug prints in
ath_start (if_ath.c 1.177.2.2.2.1), one just after IFQ_DRV_DEQUEUE
(line 1576), another just before the call to ieee80211_pwrsave (line
1614).

Packets are dequeued, but ieee80211_pwrsave is called and nothing
happens.  Below is the output from "athdebug xmit" with these extra
two DPRINTF:s during the queue-up.  Then after a while packets are
sent again.

Bengt

ath_start: dequeue packet 0x0
ath_start: dequeue packet 0x0
ath_start: dequeue packet 0x0
ath_start: dequeue packet 0xc37d3000
ath_start: power save, packet=0xc37d3000
ath_start: dequeue packet 0x0
ath_start: dequeue packet 0xc37d4800
ath_start: power save, packet=0xc37d4800
ath_start: dequeue packet 0x0
ath_start: dequeue packet 0xc37d4600
ath_start: power save, packet=0xc37d4600
ath_start: dequeue packet 0x0
ath_start: dequeue packet 0xc37d6c00
ath_start: power save, packet=0xc37d6c00
ath_start: dequeue packet 0x0
ath_start: dequeue packet 0xc37db000
ath_start: power save, packet=0xc37db000
ath_start: dequeue packet 0x0
ath_start: dequeue packet 0xc37d9e00
ath_start: power save, packet=0xc37d9e00
ath_start: dequeue packet 0x0
ath_start: dequeue packet 0xc37d5800
ath_start: power save, packet=0xc37d5800
ath_start: dequeue packet 0x0
ath_start: dequeue packet 0xc37da800
ath_start: power save, packet=0xc37da800
ath_start: dequeue packet 0x0
ath_start: dequeue packet 0xc37da100
ath_start: power save, packet=0xc37da100
ath_start: dequeue packet 0x0
ath_start: dequeue packet 0xc37dab00
ath_start: power save, packet=0xc37dab00
ath_start: dequeue packet 0x0
ath_start: dequeue packet 0xc38ef900
ath_start: power save, packet=0xc38ef900
ath_start: dequeue packet 0x0
ath_start: dequeue packet 0xc37d4d00
ath_start: power save, packet=0xc37d4d00
ath_start: dequeue packet 0x0
ath_start: dequeue packet 0xc37d9b00
ath_start: power save, packet=0xc37d9b00
ath_start: dequeue packet 0x0
ath_start: dequeue packet 0xc37d9500
ath_start: power save, packet=0xc37d9500
ath_start: dequeue packet 0x0
ath_tx_dmasetup: m 0xc37d3500 len 42
NODS 00:05:4e:4e:1f:c7->ff:ff:ff:ff:ff:ff(ff:ff:ff:ff:ff:ff) probe_req 1M
 4000 0000 ffff ffff ffff 0005 4e4e 1fc7 ffff ffff ffff 9001 0000 0108 8284 8b96 0c12 1824 3204 3048 606c
ath_tx_handoff: 0: 00000000 014cd5b0 6122002e 0100802a 00040000 0000001b
ath_tx_handoff: TXDP[1] = 0x1d3df500 (0xdecdc500) depth 1
ath_starath_start: dequeue packet 0x0
t: dequeue packet 0x0
ath_tx_dmasetup: m 0xc37d9400 len 46
NODS 00:05:4e:4e:1f:c7->ff:ff:ff:ff:ff:ff(ff:ff:ff:ff:ff:ff) probe_req 1M
 4000 0000 ffff ffff ffff 0005 4e4e 1fc7 ffff ffff ffff a001 0004 5349 4353 0108 8284 8b96 0c12 1824 3204 3048 606c
ath_tx_handoff: 0: 00000000 014d34b0 61220032 0100802e 00040000 0000001b
ath_tx_handoff: link[1](0xdecdc500)=0x1d3df8c0 (0xdecdc8c0) depth 2
ath_start: dequeue packet 0x0
ath_start: dequeue packet 0x0
ath_start: dequeue packet 0x0
ath_start: dequeue packet 0xc37d9600
ath_start: power save, packet=0xc37d9600
ath_start: dequeue packet 0x0
ath_start: dequeue packet 0xc37d7d00
ath_start: power save, packet=0xc37d7d00
ath_start: dequeue packet 0x0
ath_start: dequeue packet 0xc37d9100
ath_start: power save, packet=0xc37d9100
ath_start: dequeue packet 0x0
ath_start: dequeue packet 0xc38a1500
ath_start: power save, packet=0xc38a1500
ath_start: dequeue packet 0x0
ath_start: dequeue packet 0xc37d6800
ath_start: power save, packet=0xc37d6800
ath_start: dequeue packet 0x0
ath_start: dequeue packet 0xc37d8800
ath_start: power save, packet=0xc37d8800
ath_start: dequeue packet 0x0
ath_start: dequeue packet 0xc37d5a00
ath_start: power save, packet=0xc37d5a00
ath_start: dequeue packet 0x0
ath_start: dequeue packet 0xc37d4400
ath_start: power save, packet=0xc37d4400
ath_start: dequeue packet 0x0
ath_start: dequeue packet 0xc37da400
ath_start: power save, packet=0xc37da400
ath_start: dequeue packet 0x0
ath_start: dequeue packet 0xc37d5d00
ath_start: power save, packet=0xc37d5d00
ath_start: dequeue packet 0x0
ath_start: dequeue packet 0xc37d7000
ath_start: power save, packet=0xc37d7000
ath_start: dequeue packet 0x0
ath_start: dequeue packet 0xc37db400
ath_start: power save, packet=0xc37db400
ath_start: dequeue packet 0x0
ath_start: dequeue packet 0xc37d6400
ath_start: power save, packet=0xc37d6400
ath_start: dequeue packet 0x0
ath_start: dequeue packet 0xc37d6700
ath_start: power save, packet=0xc37d6700
ath_start: dequeue packet 0x0
ath_start: dequeue packet 0xc37d5700
ath_start: power save, packet=0xc37d5700
ath_start: dequeue packet 0x0
ath_start: dequeue packet 0xc37d8100
ath_start: power save, packet=0xc37d8100
ath_start: dequeue packet 0x0
ath_start: dequeue packet 0xc37d8d00
ath_start: power save, packet=0xc37d8d00
ath_start: dequeue packet 0x0
ath_start: dequeue packet 0xc37d4a00
ath_start: power save, packet=0xc37d4a00
ath_start: dequeue packet 0x0
ath_start: dequeue packet 0xc37d8a00
ath_start: power save, packet=0xc37d8a00
ath_start: dequeue packet 0x0
ath_start: dequeue packet 0xc37d9400
ath_start: power save, packet=0xc37d9400
ath_start: dequeue packet 0x0
ath_start: dequeue packet 0xc37d8400
ath_start: power save, packet=0xc37d8400
ath_start: dequeue packet 0x0
ath_start: dequeue packet 0xc37d3400
ath_start: power save, packet=0xc37d3400
ath_start: dequeue packet 0x0
ath_start: dequeue packet 0xc37d4500
ath_start: power save, packet=0xc37d4500
ath_start: dequeue packet 0x0
ath_start: dequeue packet 0xc37d7400
ath_start: power save, packet=0xc37d7400
ath_start: dequeue packet 0x0
ath_start: dequeue packet 0xc37d8000
ath_start: power save, packet=0xc37d8000
ath_start: dequeue packet 0x0
ath_start: dequeue packet 0xc38f0700
ath_start: power save, packet=0xc38f0700
ath_start: dequeue packet 0x0
ath_tx_dmasetup: m 0xc37d8900 len 24
TODS 00:05:4e:4e:1f:c7->00:13:1a:47:7a:33(00:13:1a:47:7a:33) data 48M
 4801 2c00 0013 1a47 7a33 0005 4e4e 1fc7 0013 1a47 7a33 b001
ath_tx_handoff: 0: 00000000 014d29e8 4122001c 00008018 03328000 00006d08
ath_tx_handoff: TXDP[1] = 0x1d3d4600 (0xdecd1600) depth 1
ath_start:ath_start: dequeue packet 0x0
 dequeue packet 0x0
ath_start: dequeue packet 0xc37d3000
ath_tx_dmasetup: m 0xc37d3000 len 116
TODS 00:05:4e:4e:1f:c7->00:e0:18:88:02:e6(00:13:1a:47:7a:33) data 48M
 0801 2c00 0013 1a47 7a33 0005 4e4e 1fc7 00e0 1888 02e6 c001 aaaa 0300 0000 0800 4500 0054 06e2 0000 4001 6cf4 c10a 42fd c10a 41c1 0800 ecc4 4a06 0000 499b 0c67 000a 8025 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 3637
ath_tx_handoff: 0: 00000000 014cd064 41220078 00008074 03328000 00006d08
ath_tx_handoff: link[1](0xdecd1600)=0x1d3d44c0 (0xdecd14c0) depth 2
ath_start: dequeue packet 0xc37d4800
ath_tx_dmasetup: m 0xc37d4800 len 116
TODS 00:05:4e:4e:1f:c7->00:e0:18:88:02:e6(00:13:1a:47:7a:33) data 48M
 0801 2c00 0013 1a47 7a33 0005 4e4e 1fc7 00e0 1888 02e6 d001 aaaa 0300 0000 0800 4500 0054 06e3 0000 4001 6cf3 c10a 42fd c10a 41c1 0800 ca0e 4a06 0001 499b 0c68 000a a2d9 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 3637
ath_tx_handoff: 0: 00000000 014ce864 41220078 00008074 03328000 00006d08
ath_tx_handoff: link[1](0xdecd14c0)=0x1d3d4b00 (0xdecd1b00) depth 3
ath_start: dequeue packet 0xc37d4600
ath_tx_dmasetup: m 0xc37d4600 len 116
TODS 00:05:4e:4e:1f:c7->00:e0:18:88:02:e6(00:13:1a:47:7a:33) data 48M
 0801 2c00 0013 1a47 7a33 0005 4e4e 1fc7 00e0 1888 02e6 e001 aaaa 0300 0000 0800 4500 0054 06e4 0000 4001 6cf2 c10a 42fd c10a 41c1 0800 a2ec 4a06 0002 499b 0c69 000a c9f9 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 3637
ath_tx_handoff: 0: 00000000 014ce664 41220078 00008074 03328000 00006d08
ath_tx_handoff: link[1](0xdecd1b00)=0x1d3d4c40 (0xdecd1c40) depth 4
ath_start: dequeue packet 0xc37d6c00
ath_tx_dmasetup: m 0xc37d6c00 len 116
TODS 00:05:4e:4e:1f:c7->00:e0:18:88:02:e6(00:13:1a:47:7a:33) data 48M
 0801 2c00 0013 1a47 7a33 0005 4e4e 1fc7 00e0 1888 02e6 f001 aaaa 0300 0000 0800 4500 0054 06e5 0000 4001 6cf1 c10a 42fd c10a 41c1 0800 7bca 4a06 0003 499b 0c6a 000a f119 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 3637
ath_tx_handoff: 0: 00000000 014d0c64 41220078 00008074 03328000 00006d08
ath_tx_handoff: link[1](0xdecd1c40)=0x1d3d4740 (0xdecd1740) depth 5
ath_start: dequeue packet 0xc37db000
ath_tx_dmasetup: m 0xc37db000 len 116
TODS 00:05:4e:4e:1f:c7->00:e0:18:88:02:e6(00:13:1a:47:7a:33) data 54M
 0801 2c00 0013 1a47 7a33 0005 4e4e 1fc7 00e0 1888 02e6 0002 aaaa 0300 0000 0800 4500 0054 06e6 0000 4001 6cf0 c10a 42fd c10a 41c1 0800 54a8 4a06 0004 499b 0c6b 000b 1839 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 3637
ath_tx_handoff: 0: 00000000 014d5064 61220078 00008074 03328000 00006d0c
ath_tx_handoff: link[1](0xdecd1740)=0x1d3d4d80 (0xdecd1d80) depth 6
ath_start: dequeue packet 0xc37d9e00
ath_tx_dmasetup: m 0xc37d9e00 len 116
TODS 00:05:4e:4e:1f:c7->00:e0:18:88:02:e6(00:13:1a:47:7a:33) data 48M
 0801 2c00 0013 1a47 7a33 0005 4e4e 1fc7 00e0 1888 02e6 1002 aaaa 0300 0000 0800 4500 0054 06e7 0000 4001 6cef c10a 42fd c10a 41c1 0800 2d83 4a06 0005 499b 0c6c 000b 3f5c 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 3637
ath_tx_handoff: 0: 00000000 014d3e64 41220078 00008074 03328000 00006d08
ath_tx_handoff: link[1](0xdecd1d80)=0x1d3d5000 (0xdecd2000) depth 7
ath_start: dequeue packet 0xc37d5800
ath_tx_dmasetup: m 0xc37d5800 len 116
TODS 00:05:4e:4e:1f:c7->00:e0:18:88:02:e6(00:13:1a:47:7a:33) data 48M
 0801 2c00 0013 1a47 7a33 0005 4e4e 1fc7 00e0 1888 02e6 2002 aaaa 0300 0000 0800 4500 0054 06e8 0000 4001 6cee c10a 42fd c10a 41c1 0800 0665 4a06 0006 499b 0c6d 000b 6678 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 3637
ath_tx_handoff: 0: 00000000 014cf864 41220078 00008074 03328000 00006d08
ath_tx_handoff: link[1](0xdecd2000)=0x1d3d5280 (0xdecd2280) depth 8
ath_start: dequeue packet 0xc37da800
ath_tx_dmasetup: m 0xc37da800 len 116
TODS 00:05:4e:4e:1f:c7->00:e0:18:88:02:e6(00:13:1a:47:7a:33) data 48M
 0801 2c00 0013 1a47 7a33 0005 4e4e 1fc7 00e0 1888 02e6 3002 aaaa 0300 0000 0800 4500 0054 06e9 0000 4001 6ced c10a 42fd c10a 41c1 0800 df42 4a06 0007 499b 0c6e 000b 8d98 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 3637
ath_tx_handoff: 0: 00000000 014d4864 41220078 00008074 03328000 00006d08
ath_tx_handoff: link[1](0xdecd2280)=0x1d3d53c0 (0xdecd23c0) depth 9
ath_start: dequeue packet 0xc37da100
ath_tx_dmasetup: m 0xc37da100 len 116
TODS 00:05:4e:4e:1f:c7->00:e0:18:88:02:e6(00:13:1a:47:7a:33) data 48M
 0801 2c00 0013 1a47 7a33 0005 4e4e 1fc7 00e0 1888 02e6 4002 aaaa 0300 0000 0800 4500 0054 06ea 0000 4001 6cec c10a 42fd c10a 41c1 0800 b821 4a06 0008 499b 0c6f 000b b4b7 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 3637
ath_tx_handoff: 0: 00000000 014d4164 41220078 00008074 03328000 00006d08
ath_tx_handoff: link[1](0xdecd23c0)=0x1d3d4ec0 (0xdecd1ec0) depth 10
ath_start: dequeue packet 0xc37dab00
ath_tx_dmasetup: m 0xc37dab00 len 116
TODS 00:05:4e:4e:1f:c7->00:e0:18:88:02:e6(00:13:1a:47:7a:33) data 48M
 0801 2c00 0013 1a47 7a33 0005 4e4e 1fc7 00e0 1888 02e6 5002 aaaa 0300 0000 0800 4500 0054 06eb 0000 4001 6ceb c10a 42fd c10a 41c1 0800 90f8 4a06 0009 499b 0c70 000b dbde 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 3637
ath_tx_handoff: 0: 00000000 014d4b64 61220078 00008074 03328000 00006d08
ath_tx_handoff: link[1](0xdecd1ec0)=0x1d3d5500 (0xdecd2500) depth 11
ath_start: dequeue packet 0xc38ef900
ath_tx_dmasetup: m 0xc38ef900 len 116
TODS 00:05:4e:4e:1f:c7->00:e0:18:88:02:e6(00:13:1a:47:7a:33) data 48M
 0801 2c00 0013 1a47 7a33 0005 4e4e 1fc7 00e0 1888 02e6 6002 aaaa 0300 0000 0800 4500 0054 06ec 0000 4001 6cea c10a 42fd c10a 41c1 0800 69c4 4a06 000a 499b 0c71 000c 0310 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 3637
ath_tx_handoff: 0: 00000000 01fe2964 41220078 00008074 03328000 00006d08
ath_tx_handoff: link[1](0xdecd2500)=0x1d3d5640 (0xdecd2640) depth 12
ath_start: dequeue packet 0xc37d4d00
ath_tx_dmasetup: m 0xc37d4d00 len 116
TODS 00:05:4e:4e:1f:c7->00:e0:18:88:02:e6(00:13:1a:47:7a:33) data 48M
 0801 2c00 0013 1a47 7a33 0005 4e4e 1fc7 00e0 1888 02e6 7002 aaaa 0300 0000 0800 4500 0054 06ed 0000 4001 6ce9 c10a 42fd c10a 41c1 0800 42be 4a06 000b 499b 0c72 000c 2a14 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 3637
ath_tx_handoff: 0: 00000000 014ced64 41220078 00008074 03328000 00006d08
ath_tx_handoff: link[1](0xdecd2640)=0x1d3d5140 (0xdecd2140) depth 13
ath_start: dequeue packet 0xc37d9b00
ath_tx_dmasetup: m 0xc37d9b00 len 116
TODS 00:05:4e:4e:1f:c7->00:e0:18:88:02:e6(00:13:1a:47:7a:33) data 48M
 0801 2c00 0013 1a47 7a33 0005 4e4e 1fc7 00e0 1888 02e6 8002 aaaa 0300 0000 0800 4500 0054 06ee 0000 4001 6ce8 c10a 42fd c10a 41c1 0800 1b98 4a06 000c 499b 0c73 000c 5138 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 3637
ath_tx_handoff: 0: 00000000 014d3b64 41220078 00008074 03328000 00006d08
ath_tx_handoff: link[1](0xdecd2140)=0x1d3d5780 (0xdecd2780) depth 14
ath_start: dequeue packet 0xc37d9500
ath_tx_dmasetup: m 0xc37d9500 len 116
TODS 00:05:4e:4e:1f:c7->00:e0:18:88:02:e6(00:13:1a:47:7a:33) data 48M
 0801 2c00 0013 1a47 7a33 0005 4e4e 1fc7 00e0 1888 02e6 9002 aaaa 0300 0000 0800 4500 0054 06ef 0000 4001 6ce7 c10a 42fd c10a 41c1 0800 f476 4a06 000d 499b 0c74 000c 7857 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 3637
ath_tx_handoff: 0: 00000000 014d3564 41220078 00008074 03328000 00006d08
ath_tx_handoff: link[1](0xdecd2780)=0x1d3d5a00 (0xdecd2a00) depth 15
ath_start: dequeue packet 0xc37d9600
ath_tx_dmasetup: m 0xc37d9600 len 116
TODS 00:05:4e:4e:1f:c7->00:e0:18:88:02:e6(00:13:1a:47:7a:33) data 48M
 0801 2c00 0013 1a47 7a33 0005 4e4e 1fc7 00e0 1888 02e6 a002 aaaa 0300 0000 0800 4500 0054 06f0 0000 4001 6ce6 c10a 42fd c10a 41c1 0800 cd56 4a06 000e 499b 0c75 000c 9f75 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 3637
ath_tx_handoff: 0: 00000000 014d3664 61220078 00008074 03328000 00006d08
ath_tx_handoff: link[1](0xdecd2a00)=0x1d3d5c80 (0xdecd2c80) depth 16
ath_start: dequeue packet 0xc37d7d00
ath_tx_dmasetup: m 0xc37d7d00 len 116
TODS 00:05:4e:4e:1f:c7->00:e0:18:88:02:e6(00:13:1a:47:7a:33) data 54M
 0801 2c00 0013 1a47 7a33 0005 4e4e 1fc7 00e0 1888 02e6 b002 aaaa 0300 0000 0800 4500 0054 06f1 0000 4001 6ce5 c10a 42fd c10a 41c1 0800 a634 4a06 000f 499b 0c76 000c c695 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 3637
ath_tx_handoff: 0: 00000000 014d1d64 41220078 00008074 03328000 00006d0c
ath_tx_handoff: link[1](0xdecd2c80)=0x1d3d5dc0 (0xdecd2dc0) depth 17
ath_start: dequeue packet 0xc37d9100
ath_tx_dmasetup: m 0xc37d9100 len 116
TODS 00:05:4e:4e:1f:c7->00:e0:18:88:02:e6(00:13:1a:47:7a:33) data 48M
 0801 2c00 0013 1a47 7a33 0005 4e4e 1fc7 00e0 1888 02e6 c002 aaaa 0300 0000 0800 4500 0054 06f2 0000 4001 6ce4 c10a 42fd c10a 41c1 0800 7f13 4a06 0010 499b 0c77 000c edb4 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 3637
ath_tx_handoff: 0: 00000000 014d3164 41220078 00008074 03328000 00006d08
ath_tx_handoff: link[1](0xdecd2dc0)=0x1d3d58c0 (0xdecd28c0) depth 18
ath_start: dequeue packet 0xc38a1500
ath_tx_dmasetup: m 0xc38a1500 len 116
TODS 00:05:4e:4e:1f:c7->00:e0:18:88:02:e6(00:13:1a:47:7a:33) data 48M
 0801 2c00 0013 1a47 7a33 0005 4e4e 1fc7 00e0 1888 02e6 d002 aaaa 0300 0000 0800 4500 0054 06f3 0000 4001 6ce3 c10a 42fd c10a 41c1 0800 57f1 4a06 0011 499b 0c78 000d 14d4 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 3637
ath_tx_handoff: 0: 00000000 01f58564 41220078 00008074 03328000 00006d08
ath_tx_handoff: link[1](0xdecd28c0)=0x1d3d5f00 (0xdecd2f00) depth 19
ath_start: dequeue packet 0xc37d6800
ath_tx_dmasetup: m 0xc37d6800 len 116
TODS 00:05:4e:4e:1f:c7->00:e0:18:88:02:e6(00:13:1a:47:7a:33) data 48M
 0801 2c00 0013 1a47 7a33 0005 4e4e 1fc7 00e0 1888 02e6 e002 aaaa 0300 0000 0800 4500 0054 06f4 0000 4001 6ce2 c10a 42fd c10a 41c1 0800 30d2 4a06 0012 499b 0c79 000d 3bf1 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 3637
ath_tx_handoff: 0: 00000000 014d0864 41220078 00008074 03328000 00006d08
ath_tx_handoff: link[1](0xdecd2f00)=0x1d3d6040 (0xdecd3040) depth 20
ath_start: dequeue packet 0xc37d8800
ath_tx_dmasetup: m 0xc37d8800 len 116
TODS 00:05:4e:4e:1f:c7->00:e0:18:88:02:e6(00:13:1a:47:7a:33) data 48M
 0801 2c00 0013 1a47 7a33 0005 4e4e 1fc7 00e0 1888 02e6 f002 aaaa 0300 0000 0800 4500 0054 06f5 0000 4001 6ce1 c10a 42fd c10a 41c1 0800 09a4 4a06 0013 499b 0c7a 000d 631d 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 3637
ath_tx_handoff: 0: 00000000 014d2864 61220078 00008074 03328000 00006d08
ath_tx_handoff: link[1](0xdecd3040)=0x1d3d5b40 (0xdecd2b40) depth 21
ath_start: dequeue packet 0xc37d5a00
ath_tx_dmasetup: m 0xc37d5a00 len 116
TODS 00:05:4e:4e:1f:c7->00:e0:18:88:02:e6(00:13:1a:47:7a:33) data 48M
 0801 2c00 0013 1a47 7a33 0005 4e4e 1fc7 00e0 1888 02e6 0003 aaaa 0300 0000 0800 4500 0054 06f6 0000 4001 6ce0 c10a 42fd c10a 41c1 0800 e279 4a06 0014 499b 0c7b 000d 8a45 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 3637
ath_tx_handoff: 0: 00000000 014cfa64 41220078 00008074 03328000 00006d08
ath_tx_handoff: link[1](0xdecd2b40)=0x1d3d6180 (0xdecd3180) depth 22
ath_start: dequeue packet 0xc37d4400
ath_tx_dmasetup: m 0xc37d4400 len 116
TODS 00:05:4e:4e:1f:c7->00:e0:18:88:02:e6(00:13:1a:47:7a:33) data 48M
 0801 2c00 0013 1a47 7a33 0005 4e4e 1fc7 00e0 1888 02e6 1003 aaaa 0300 0000 0800 4500 0054 06f7 0000 4001 6cdf c10a 42fd c10a 41c1 0800 bb6d 4a06 0015 499b 0c7c 000d b14f 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 3637
ath_tx_handoff: 0: 00000000 014ce464 41220078 00008074 03328000 00006d08
ath_tx_handoff: link[1](0xdecd3180)=0x1d3d6400 (0xdecd3400) depth 23
ath_start: dequeue packet 0xc37da400
ath_tx_dmasetup: m 0xc37da400 len 116
TODS 00:05:4e:4e:1f:c7->00:e0:18:88:02:e6(00:13:1a:47:7a:33) data 48M
 0801 2c00 0013 1a47 7a33 0005 4e4e 1fc7 00e0 1888 02e6 2003 aaaa 0300 0000 0800 4500 0054 06f8 0000 4001 6cde c10a 42fd c10a 41c1 0800 9448 4a06 0016 499b 0c7d 000d d872 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 3637
ath_tx_handoff: 0: 00000000 014d4464 41220078 00008074 03328000 00006d08
ath_tx_handoff: link[1](0xdecd3400)=0x1d3d6680 (0xdecd3680) depth 24
ath_start: dequeue packet 0xc37d5d00
ath_tx_dmasetup: m 0xc37d5d00 len 116
TODS 00:05:4e:4e:1f:c7->00:e0:18:88:02:e6(00:13:1a:47:7a:33) data 48M
 0801 2c00 0013 1a47 7a33 0005 4e4e 1fc7 00e0 1888 02e6 3003 aaaa 0300 0000 0800 4500 0054 06f9 0000 4001 6cdd c10a 42fd c10a 41c1 0800 6d1e 4a06 0017 499b 0c7e 000d ff9a 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 3637
ath_tx_handoff: 0: 00000000 014cfd64 41220078 00008074 03328000 00006d08
ath_tx_handoff: link[1](0xdecd3680)=0x1d3d67c0 (0xdecd37c0) depth 25
ath_start: dequeue packet 0xc37d7000
ath_tx_dmasetup: m 0xc37d7000 len 116
TODS 00:05:4e:4e:1f:c7->00:e0:18:88:02:e6(00:13:1a:47:7a:33) data 48M
 0801 2c00 0013 1a47 7a33 0005 4e4e 1fc7 00e0 1888 02e6 4003 aaaa 0300 0000 0800 4500 0054 06fa 0000 4001 6cdc c10a 42fd c10a 41c1 0800 4606 4a06 0018 499b 0c7f 000e 26b0 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 3637
ath_tx_handoff: 0: 00000000 014d1064 61220078 00008074 03328000 00006d08
ath_tx_handoff: link[1](0xdecd37c0)=0x1d3d62c0 (0xdecd32c0) depth 26
ath_start: dequeue packet 0xc37db400
ath_tx_dmasetup: m 0xc37db400 len 116
TODS 00:05:4e:4e:1f:c7->00:e0:18:88:02:e6(00:13:1a:47:7a:33) data 48M
 0801 2c00 0013 1a47 7a33 0005 4e4e 1fc7 00e0 1888 02e6 5003 aaaa 0300 0000 0800 4500 0054 06fb 0000 4001 6cdb c10a 42fd c10a 41c1 0800 1ee3 4a06 0019 499b 0c80 000e 4dd1 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 3637
ath_tx_handoff: 0: 00000000 014d5464 41220078 00008074 03328000 00006d08
ath_tx_handoff: link[1](0xdecd32c0)=0x1d3d6900 (0xdecd3900) depth 27
ath_start: dequeue packet 0xc37d6400
ath_tx_dmasetup: m 0xc37d6400 len 116
TODS 00:05:4e:4e:1f:c7->00:e0:18:88:02:e6(00:13:1a:47:7a:33) data 54M
 0801 2c00 0013 1a47 7a33 0005 4e4e 1fc7 00e0 1888 02e6 6003 aaaa 0300 0000 0800 4500 0054 06fc 0000 4001 6cda c10a 42fd c10a 41c1 0800 f7c2 4a06 001a 499b 0c81 000e 74ef 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 3637
ath_tx_handoff: 0: 00000000 014d0464 41220078 00008074 03328000 00006d0c
ath_tx_handoff: link[1](0xdecd3900)=0x1d3d6a40 (0xdecd3a40) depth 28
ath_start: dequeue packet 0xc37d6700
ath_tx_dmasetup: m 0xc37d6700 len 116
TODS 00:05:4e:4e:1f:c7->00:e0:18:88:02:e6(00:13:1a:47:7a:33) data 48M
 0801 2c00 0013 1a47 7a33 0005 4e4e 1fc7 00e0 1888 02e6 7003 aaaa 0300 0000 0800 4500 0054 06fd 0000 4001 6cd9 c10a 42fd c10a 41c1 0800 d0a1 4a06 001b 499b 0c82 000e 9c0e 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 3637
ath_tx_handoff: 0: 00000000 014d0764 41220078 00008074 03328000 00006d08
ath_tx_handoff: link[1](0xdecd3a40)=0x1d3d6540 (0xdecd3540) depth 29
ath_start: dequeue packet 0xc37d5700
ath_tx_dmasetup: m 0xc37d5700 len 116
TODS 00:05:4e:4e:1f:c7->00:e0:18:88:02:e6(00:13:1a:47:7a:33) data 48M
 0801 2c00 0013 1a47 7a33 0005 4e4e 1fc7 00e0 1888 02e6 8003 aaaa 0300 0000 0800 4500 0054 06fe 0000 4001 6cd8 c10a 42fd c10a 41c1 0800 a980 4a06 001c 499b 0c83 000e c32d 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 3637
ath_tx_handoff: 0: 00000000 014cf764 41220078 00008074 03328000 00006d08
ath_tx_handoff: link[1](0xdecd3540)=0x1d3d6b80 (0xdecd3b80) depth 30
ath_start: dequeue packet 0xc37d8100
ath_tx_dmasetup: m 0xc37d8100 len 116
TODS 00:05:4e:4e:1f:c7->00:e0:18:88:02:e6(00:13:1a:47:7a:33) data 48M
 0801 2c00 0013 1a47 7a33 0005 4e4e 1fc7 00e0 1888 02e6 9003 aaaa 0300 0000 0800 4500 0054 06ff 0000 4001 6cd7 c10a 42fd c10a 41c1 0800 825a 4a06 001d 499b 0c84 000e ea51 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 3637
ath_tx_handoff: 0: 00000000 014d2164 61220078 00008074 03328000 00006d08
ath_tx_handoff: link[1](0xdecd3b80)=0x1d3d6e00 (0xdecd3e00) depth 31
ath_start: dequeue packet 0xc37d8d00
ath_tx_dmasetup: m 0xc37d8d00 len 116
TODS 00:05:4e:4e:1f:c7->00:e0:18:88:02:e6(00:13:1a:47:7a:33) data 48M
 0801 2c00 0013 1a47 7a33 0005 4e4e 1fc7 00e0 1888 02e6 a003 aaaa 0300 0000 0800 4500 0054 0700 0000 4001 6cd6 c10a 42fd c10a 41c1 0800 5b20 4a06 001e 499b 0c85 000f 1189 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 3637
ath_tx_handoff: 0: 00000000 014d2d64 41220078 00008074 03328000 00006d08
ath_tx_handoff: link[1](0xdecd3e00)=0x1d3d6f40 (0xdecd3f40) depth 32
ath_start: dequeue packet 0xc37d4a00
ath_tx_dmasetup: m 0xc37d4a00 len 116
TODS 00:05:4e:4e:1f:c7->00:e0:18:88:02:e6(00:13:1a:47:7a:33) data 48M
 0801 2c00 0013 1a47 7a33 0005 4e4e 1fc7 00e0 1888 02e6 b003 aaaa 0300 0000 0800 4500 0054 0701 0000 4001 6cd5 c10a 42fd c10a 41c1 0800 341e 4a06 001f 499b 0c86 000f 3889 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 3637
ath_tx_handoff: 0: 00000000 014cea64 41220078 00008074 03328000 00006d08
ath_tx_handoff: link[1](0xdecd3f40)=0x1d3d6cc0 (0xdecd3cc0) depth 33
ath_start: dequeue packet 0xc37d8a00
ath_tx_dmasetup: m 0xc37d8a00 len 116
TODS 00:05:4e:4e:1f:c7->00:e0:18:88:02:e6(00:13:1a:47:7a:33) data 48M
 0801 2c00 0013 1a47 7a33 0005 4e4e 1fc7 00e0 1888 02e6 c003 aaaa 0300 0000 0800 4500 0054 0702 0000 4001 6cd4 c10a 42fd c10a 41c1 0800 4f44 4a06 0020 499b 0c88 0000 1d6f 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 3637
ath_tx_handoff: 0: 00000000 014d2a64 41220078 00008074 03328000 00006d08
ath_tx_handoff: link[1](0xdecd3cc0)=0x1d3d7080 (0xdecd4080) depth 34
ath_start: dequeue packet 0xc37d9400
ath_tx_dmasetup: m 0xc37d9400 len 116
TODS 00:05:4e:4e:1f:c7->00:e0:18:88:02:e6(00:13:1a:47:7a:33) data 48M
 0801 2c00 0013 1a47 7a33 0005 4e4e 1fc7 00e0 1888 02e6 d003 aaaa 0300 0000 0800 4500 0054 0703 0000 4001 6cd3 c10a 42fd c10a 41c1 0800 2827 4a06 0021 499b 0c89 0000 448a 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 3637
ath_tx_handoff: 0: 00000000 014d3464 41220078 00008074 03328000 00006d08
ath_tx_handoff: link[1](0xdecd4080)=0x1d3d7300 (0xdecd4300) depth 35
ath_start: dequeue packet 0xc37d8400
ath_tx_dmasetup: m 0xc37d8400 len 116
TODS 00:05:4e:4e:1f:c7->00:e0:18:88:02:e6(00:13:1a:47:7a:33) data 48M
 0801 2c00 0013 1a47 7a33 0005 4e4e 1fc7 00e0 1888 02e6 e003 aaaa 0300 0000 0800 4500 0054 0704 0000 4001 6cd2 c10a 42fd c10a 41c1 0800 0105 4a06 0022 499b 0c8a 0000 6baa 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 3637
ath_tx_handoff: 0: 00000000 014d2464 61220078 00008074 03328000 00006d08
ath_tx_handoff: link[1](0xdecd4300)=0x1d3d7440 (0xdecd4440) depth 36
ath_start: dequeue packet 0xc37d3400
ath_tx_dmasetup: m 0xc37d3400 len 116
TODS 00:05:4e:4e:1f:c7->00:e0:18:88:02:e6(00:13:1a:47:7a:33) data 48M
 0801 2c00 0013 1a47 7a33 0005 4e4e 1fc7 00e0 1888 02e6 f003 aaaa 0300 0000 0800 4500 0054 0705 0000 4001 6cd1 c10a 42fd c10a 41c1 0800 d9e3 4a06 0023 499b 0c8b 0000 92c9 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 3637
ath_tx_handoff: 0: 00000000 014cd464 41220078 00008074 03328000 00006d08
ath_tx_handoff: link[1](0xdecd4440)=0x1d3d71c0 (0xdecd41c0) depth 37
ath_start: dequeue packet 0xc37d4500
ath_tx_dmasetup: m 0xc37d4500 len 116
TODS 00:05:4e:4e:1f:c7->00:e0:18:88:02:e6(00:13:1a:47:7a:33) data 48M
 0801 2c00 0013 1a47 7a33 0005 4e4e 1fc7 00e0 1888 02e6 0004 aaaa 0300 0000 0800 4500 0054 0706 0000 4001 6cd0 c10a 42fd c10a 41c1 0800 b2bd 4a06 0024 499b 0c8c 0000 b9ed 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 3637
ath_tx_handoff: 0: 00000000 014ce564 41220078 00008074 03328000 00006d08
ath_tx_handoff: link[1](0xdecd41c0)=0x1d3d7580 (0xdecd4580) depth 38
ath_start: dequeue packet 0xc37d7400
ath_tx_dmasetup: m 0xc37d7400 len 116
TODS 00:05:4e:4e:1f:c7->00:e0:18:88:02:e6(00:13:1a:47:7a:33) data 54M
 0801 2c00 0013 1a47 7a33 0005 4e4e 1fc7 00e0 1888 02e6 1004 aaaa 0300 0000 0800 4500 0054 0707 0000 4001 6ccf c10a 42fd c10a 41c1 0800 8ba0 4a06 0025 499b 0c8d 0000 e108 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 3637
ath_tx_handoff: 0: 00000000 014d1464 41220078 00008074 03328000 00006d0c
ath_tx_handoff: link[1](0xdecd4580)=0x1d3d76c0 (0xdecd46c0) depth 39
ath_start: dequeue packet 0xc37d8000
ath_tx_dmasetup: m 0xc37d8000 len 116
TODS 00:05:4e:4e:1f:c7->00:e0:18:88:02:e6(00:13:1a:47:7a:33) data 48M
 0801 2c00 0013 1a47 7a33 0005 4e4e 1fc7 00e0 1888 02e6 2004 aaaa 0300 0000 0800 4500 0054 0708 0000 4001 6cce c10a 42fd c10a 41c1 0800 6480 4a06 0026 499b 0c8e 0001 0826 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 3637
ath_tx_handoff: 0: 00000000 014d2064 41220078 00008074 03328000 00006d08
ath_tx_handoff: link[1](0xdecd46c0)=0x1d3d7940 (0xdecd4940) depth 40
ath_start: dequeue packet 0xc38f0700
ath_tx_dmasetup: m 0xc38f0700 len 116
TODS 00:05:4e:4e:1f:c7->00:e0:18:88:02:e6(00:13:1a:47:7a:33) data 48M
 0801 2c00 0013 1a47 7a33 0005 4e4e 1fc7 00e0 1888 02e6 3004 aaaa 0300 0000 0800 4500 0054 0709 0000 4001 6ccd c10a 42fd c10a 41c1 0800 3d50 4a06 0027 499b 0c8f 0001 2f54 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 3637
ath_tx_handoff: 0: 00000000 01fe3764 61220078 00008074 03328000 00006d08
ath_tx_handoff: link[1](0xdecd4940)=0x1d3d7a80 (0xdecd4a80) depth 41
ath_start: dequeue packet 0x0
ath_start: dequeue packet 0x0
ath_start: dequeue packet 0x0
ath_start: dequeue packet 0x0
From sam at freebsd.org  Tue Feb 17 12:30:53 2009
From: sam at freebsd.org (Sam Leffler)
Date: Tue Feb 17 12:30:59 2009
Subject: Problems with ath at kern.hz=100
In-Reply-To: <uh7y6w4zwsq.fsf@P142.sics.se>
References: <uh7iqnjzzi9.fsf@P142.sics.se>	<20090210154047.N38905@sola.nimnet.asn.au>	<4991ABA0.4050300@freebsd.org>
	<uh7fximfatw.fsf@P142.sics.se>	<4991DB1F.7060809@freebsd.org>
	<uh7y6w4zwsq.fsf@P142.sics.se>
Message-ID: <499B1E7B.2030908@freebsd.org>

Bengt Ahlgren wrote:
> Sam Leffler <sam@freebsd.org> writes:
>
> [...]
>
>   
>> You've removed all the context of the original problem; I can't recall
>> what you were trying to fix.  The ps q drops might be caused by a bug
>> that was fixed (I think in RELENG_7).  I don't see what version of
>> code you're running so can't tell.
>>     
>
> Sorry, a summary of the problem:
>
> The system frequently comes into a state where outgoing packets are
> held somewhere.  The condition persists for seconds to minutes.  It
> goes away by itself, but some of the packets are usually lost.  This
> occurs on ath, FreeBSD 7.1-REL, no SMP, with kern.hz=100 (but not with
> hz=1000).  Original mail with description can be found here:
>
> http://lists.freebsd.org/pipermail/freebsd-mobile/2009-February/011343.html
>
> I have done some more investigation, inserting debug prints in
> ath_start (if_ath.c 1.177.2.2.2.1), one just after IFQ_DRV_DEQUEUE
> (line 1576), another just before the call to ieee80211_pwrsave (line
> 1614).
>
> Packets are dequeued, but ieee80211_pwrsave is called and nothing
> happens.  Below is the output from "athdebug xmit" with these extra
> two DPRINTF:s during the queue-up.  Then after a while packets are
> sent again.
>
> Bengt
>
>   
<...debug output removed...>

Did you try RELENG_7? ap mode power save was fixed post 7.1 release.

Sam

From kalin at el.net  Tue Feb 17 14:48:42 2009
From: kalin at el.net (kalin m)
Date: Tue Feb 17 14:48:54 2009
Subject: sms gprs gsm edge
Message-ID: <499B3888.2000701@el.net>


hi all...

just looking for a few pointers for setting up a sms gateway.
if somebody would like to share some knowledge on successfully 
implemented hardware (gprs/gsm/edge modems/drivers) and software like 
kannel, smstools, etc...

for example i just talked to a salesperson at a company called moxa 
(http://www.moxa.com/product/oncell_g3100.htm) and was looking at their 
g3100 model gprs modem. according to their own specifications they have 
freebsd drivers. anybody has had any experience with those?!

any information will be appreciated.. 

thank you....

From 000.fbsd at quip.cz  Tue Feb 17 15:40:46 2009
From: 000.fbsd at quip.cz (Miroslav Lachman)
Date: Tue Feb 17 15:40:54 2009
Subject: sms gprs gsm edge
In-Reply-To: <499B3888.2000701@el.net>
References: <499B3888.2000701@el.net>
Message-ID: <499B464C.5020409@quip.cz>

kalin m wrote:
> 
> hi all...
> 
> just looking for a few pointers for setting up a sms gateway.
> if somebody would like to share some knowledge on successfully 
> implemented hardware (gprs/gsm/edge modems/drivers) and software like 
> kannel, smstools, etc...
> 
> for example i just talked to a salesperson at a company called moxa 
> (http://www.moxa.com/product/oncell_g3100.htm) and was looking at their 
> g3100 model gprs modem. according to their own specifications they have 
> freebsd drivers. anybody has had any experience with those?!
> 
> any information will be appreciated..
> thank you....

I used Siemens MC35i GSM modem over COM1 with smstools few years ago 
(with FreeBSD 4.x). No special drivers needed. It was used to send and 
receive SMS with our custom PHP web application.

I don't know what is your definition of "sms gateway".

Miroslav Lachman
From peo at intersonic.se  Tue Feb 17 15:45:13 2009
From: peo at intersonic.se (Per olof Ljungmark)
Date: Tue Feb 17 15:45:19 2009
Subject: sms gprs gsm edge
In-Reply-To: <499B3888.2000701@el.net>
References: <499B3888.2000701@el.net>
Message-ID: <499B4878.7060103@intersonic.se>

kalin m wrote:
> 
> hi all...
> 
> just looking for a few pointers for setting up a sms gateway.
> if somebody would like to share some knowledge on successfully 
> implemented hardware (gprs/gsm/edge modems/drivers) and software like 
> kannel, smstools, etc...
> 
> for example i just talked to a salesperson at a company called moxa 
> (http://www.moxa.com/product/oncell_g3100.htm) and was looking at their 
> g3100 model gprs modem. according to their own specifications they have 
> freebsd drivers. anybody has had any experience with those?!
> 

Hi,

I know that a collegue here used a Siemens TC65 GSM Modem together with 
smstools and sms_client from ports to set up a sms paging system that 
works well. If you'd like I could ask him to send you more detailed info 
on how it was implemented.

I also believe that the engine in this modem is available in various 
packages, the TC65 is a standalone unit needing only the sim card and 
antenna to work.

It is connected over a usb to serial adapter and required no special 
drivers.

--
per
From bengta at sics.se  Wed Feb 18 01:52:20 2009
From: bengta at sics.se (Bengt Ahlgren)
Date: Wed Feb 18 01:52:27 2009
Subject: Problems with ath at kern.hz=100
In-Reply-To: <499B1E7B.2030908@freebsd.org> (Sam Leffler's message of "Tue\,
	17 Feb 2009 12\:30\:51 -0800")
References: <uh7iqnjzzi9.fsf@P142.sics.se>
	<20090210154047.N38905@sola.nimnet.asn.au>
	<4991ABA0.4050300@freebsd.org> <uh7fximfatw.fsf@P142.sics.se>
	<4991DB1F.7060809@freebsd.org> <uh7y6w4zwsq.fsf@P142.sics.se>
	<499B1E7B.2030908@freebsd.org>
Message-ID: <uh7eixwm5o9.fsf@P142.sics.se>

Sam Leffler <sam@freebsd.org> writes:

> Bengt Ahlgren wrote:
>> Sam Leffler <sam@freebsd.org> writes:
>>
>> [...]
>>
>>   
>>> You've removed all the context of the original problem; I can't recall
>>> what you were trying to fix.  The ps q drops might be caused by a bug
>>> that was fixed (I think in RELENG_7).  I don't see what version of
>>> code you're running so can't tell.
>>>     
>>
>> Sorry, a summary of the problem:
>>
>> The system frequently comes into a state where outgoing packets are
>> held somewhere.  The condition persists for seconds to minutes.  It
>> goes away by itself, but some of the packets are usually lost.  This
>> occurs on ath, FreeBSD 7.1-REL, no SMP, with kern.hz=100 (but not with
>> hz=1000).  Original mail with description can be found here:
>>
>> http://lists.freebsd.org/pipermail/freebsd-mobile/2009-February/011343.html
>>
>> I have done some more investigation, inserting debug prints in
>> ath_start (if_ath.c 1.177.2.2.2.1), one just after IFQ_DRV_DEQUEUE
>> (line 1576), another just before the call to ieee80211_pwrsave (line
>> 1614).
>>
>> Packets are dequeued, but ieee80211_pwrsave is called and nothing
>> happens.  Below is the output from "athdebug xmit" with these extra
>> two DPRINTF:s during the queue-up.  Then after a while packets are
>> sent again.
>>
>> Bengt
>>
>>   
> <...debug output removed...>
>
> Did you try RELENG_7? ap mode power save was fixed post 7.1 release.

I can do that, but I am not using ap mode.  Will it still be useful?

Bengt
From bengta at sics.se  Wed Feb 18 05:23:16 2009
From: bengta at sics.se (Bengt Ahlgren)
Date: Wed Feb 18 05:23:26 2009
Subject: Problems with ath at kern.hz=100
In-Reply-To: <uh7eixwm5o9.fsf@P142.sics.se> (Bengt Ahlgren's message of "Wed\,
	18 Feb 2009 10\:54\:14 +0100")
References: <uh7iqnjzzi9.fsf@P142.sics.se>
	<20090210154047.N38905@sola.nimnet.asn.au>
	<4991ABA0.4050300@freebsd.org> <uh7fximfatw.fsf@P142.sics.se>
	<4991DB1F.7060809@freebsd.org> <uh7y6w4zwsq.fsf@P142.sics.se>
	<499B1E7B.2030908@freebsd.org> <uh7eixwm5o9.fsf@P142.sics.se>
Message-ID: <uh7eixvlvwo.fsf@P142.sics.se>

Bengt Ahlgren <bengta@sics.se> writes:

> Sam Leffler <sam@freebsd.org> writes:
>
>> Bengt Ahlgren wrote:
>>> Sam Leffler <sam@freebsd.org> writes:
>>>
>>> [...]
>>>
>>>   
>>>> You've removed all the context of the original problem; I can't recall
>>>> what you were trying to fix.  The ps q drops might be caused by a bug
>>>> that was fixed (I think in RELENG_7).  I don't see what version of
>>>> code you're running so can't tell.
>>>>     
>>>
>>> Sorry, a summary of the problem:
>>>
>>> The system frequently comes into a state where outgoing packets are
>>> held somewhere.  The condition persists for seconds to minutes.  It
>>> goes away by itself, but some of the packets are usually lost.  This
>>> occurs on ath, FreeBSD 7.1-REL, no SMP, with kern.hz=100 (but not with
>>> hz=1000).  Original mail with description can be found here:
>>>
>>> http://lists.freebsd.org/pipermail/freebsd-mobile/2009-February/011343.html
>>>
>>> I have done some more investigation, inserting debug prints in
>>> ath_start (if_ath.c 1.177.2.2.2.1), one just after IFQ_DRV_DEQUEUE
>>> (line 1576), another just before the call to ieee80211_pwrsave (line
>>> 1614).
>>>
>>> Packets are dequeued, but ieee80211_pwrsave is called and nothing
>>> happens.  Below is the output from "athdebug xmit" with these extra
>>> two DPRINTF:s during the queue-up.  Then after a while packets are
>>> sent again.
>>>
>>> Bengt
>>>
>>>   
>> <...debug output removed...>
>>
>> Did you try RELENG_7? ap mode power save was fixed post 7.1 release.
>
> I can do that, but I am not using ap mode.  Will it still be useful?

Hmm, I see no difference in ath between 7.1-REL and RELENG_7 (besides
CVS ID strings)???  Are you meaning HEAD?  If so, can I just drop in
src/sys/dev/ath from HEAD in 7.1R?

Bengt
From sam at freebsd.org  Wed Feb 18 08:21:13 2009
From: sam at freebsd.org (Sam Leffler)
Date: Wed Feb 18 08:21:19 2009
Subject: Problems with ath at kern.hz=100
In-Reply-To: <uh7eixvlvwo.fsf@P142.sics.se>
References: <uh7iqnjzzi9.fsf@P142.sics.se>	<20090210154047.N38905@sola.nimnet.asn.au>	<4991ABA0.4050300@freebsd.org>
	<uh7fximfatw.fsf@P142.sics.se>	<4991DB1F.7060809@freebsd.org>
	<uh7y6w4zwsq.fsf@P142.sics.se>	<499B1E7B.2030908@freebsd.org>
	<uh7eixwm5o9.fsf@P142.sics.se> <uh7eixvlvwo.fsf@P142.sics.se>
Message-ID: <499C3578.9080007@freebsd.org>

Bengt Ahlgren wrote:
> Bengt Ahlgren <bengta@sics.se> writes:
>
>   
>> Sam Leffler <sam@freebsd.org> writes:
>>
>>     
>>> Bengt Ahlgren wrote:
>>>       
>>>> Sam Leffler <sam@freebsd.org> writes:
>>>>
>>>> [...]
>>>>
>>>>   
>>>>         
>>>>> You've removed all the context of the original problem; I can't recall
>>>>> what you were trying to fix.  The ps q drops might be caused by a bug
>>>>> that was fixed (I think in RELENG_7).  I don't see what version of
>>>>> code you're running so can't tell.
>>>>>     
>>>>>           
>>>> Sorry, a summary of the problem:
>>>>
>>>> The system frequently comes into a state where outgoing packets are
>>>> held somewhere.  The condition persists for seconds to minutes.  It
>>>> goes away by itself, but some of the packets are usually lost.  This
>>>> occurs on ath, FreeBSD 7.1-REL, no SMP, with kern.hz=100 (but not with
>>>> hz=1000).  Original mail with description can be found here:
>>>>
>>>> http://lists.freebsd.org/pipermail/freebsd-mobile/2009-February/011343.html
>>>>
>>>> I have done some more investigation, inserting debug prints in
>>>> ath_start (if_ath.c 1.177.2.2.2.1), one just after IFQ_DRV_DEQUEUE
>>>> (line 1576), another just before the call to ieee80211_pwrsave (line
>>>> 1614).
>>>>
>>>> Packets are dequeued, but ieee80211_pwrsave is called and nothing
>>>> happens.  Below is the output from "athdebug xmit" with these extra
>>>> two DPRINTF:s during the queue-up.  Then after a while packets are
>>>> sent again.
>>>>
>>>> Bengt
>>>>
>>>>   
>>>>         
>>> <...debug output removed...>
>>>
>>> Did you try RELENG_7? ap mode power save was fixed post 7.1 release.
>>>       
>> I can do that, but I am not using ap mode.  Will it still be useful?
>>     
>
>   

No changes were made related to sta mode.

> Hmm, I see no difference in ath between 7.1-REL and RELENG_7 (besides
> CVS ID strings)???  Are you meaning HEAD?  If so, can I just drop in
> src/sys/dev/ath from HEAD in 7.1R?
>   
Code in HEAD is totally different.

Sam

From bengta at sics.se  Wed Feb 18 10:18:07 2009
From: bengta at sics.se (Bengt Ahlgren)
Date: Wed Feb 18 10:18:14 2009
Subject: Problems with ath at kern.hz=100
In-Reply-To: <uh7eixvlvwo.fsf@P142.sics.se> (Bengt Ahlgren's message of "Wed\,
	18 Feb 2009 14\:25\:11 +0100")
References: <uh7iqnjzzi9.fsf@P142.sics.se>
	<20090210154047.N38905@sola.nimnet.asn.au>
	<4991ABA0.4050300@freebsd.org> <uh7fximfatw.fsf@P142.sics.se>
	<4991DB1F.7060809@freebsd.org> <uh7y6w4zwsq.fsf@P142.sics.se>
	<499B1E7B.2030908@freebsd.org> <uh7eixwm5o9.fsf@P142.sics.se>
	<uh7eixvlvwo.fsf@P142.sics.se>
Message-ID: <uh7skmby5da.fsf@P142.sics.se>

Bengt Ahlgren <bengta@sics.se> writes:

> Bengt Ahlgren <bengta@sics.se> writes:
>
>> Sam Leffler <sam@freebsd.org> writes:
>>
>>> Bengt Ahlgren wrote:
>>>> Sam Leffler <sam@freebsd.org> writes:
>>>>
>>>> [...]
>>>>
>>>>   
>>>>> You've removed all the context of the original problem; I can't recall
>>>>> what you were trying to fix.  The ps q drops might be caused by a bug
>>>>> that was fixed (I think in RELENG_7).  I don't see what version of
>>>>> code you're running so can't tell.
>>>>>     
>>>>
>>>> Sorry, a summary of the problem:
>>>>
>>>> The system frequently comes into a state where outgoing packets are
>>>> held somewhere.  The condition persists for seconds to minutes.  It
>>>> goes away by itself, but some of the packets are usually lost.  This
>>>> occurs on ath, FreeBSD 7.1-REL, no SMP, with kern.hz=100 (but not with
>>>> hz=1000).  Original mail with description can be found here:
>>>>
>>>> http://lists.freebsd.org/pipermail/freebsd-mobile/2009-February/011343.html
>>>>
>>>> I have done some more investigation, inserting debug prints in
>>>> ath_start (if_ath.c 1.177.2.2.2.1), one just after IFQ_DRV_DEQUEUE
>>>> (line 1576), another just before the call to ieee80211_pwrsave (line
>>>> 1614).
>>>>
>>>> Packets are dequeued, but ieee80211_pwrsave is called and nothing
>>>> happens.  Below is the output from "athdebug xmit" with these extra
>>>> two DPRINTF:s during the queue-up.  Then after a while packets are
>>>> sent again.
>>>>
>>>> Bengt
>>>>
>>>>   
>>> <...debug output removed...>
>>>
>>> Did you try RELENG_7? ap mode power save was fixed post 7.1 release.
>>
>> I can do that, but I am not using ap mode.  Will it still be useful?
>
> Hmm, I see no difference in ath between 7.1-REL and RELENG_7 (besides
> CVS ID strings)???  Are you meaning HEAD?  If so, can I just drop in
> src/sys/dev/ath from HEAD in 7.1R?

You are meaning sys/net80211, right?  I dropped the RELENG_7 version
of that into my 7.1-REL tree:

# ident /boot/kernel/kernel | grep ieee80211_power
     $FreeBSD: src/sys/net80211/ieee80211_power.c,v 1.2.2.1 2009/01/26 20:24:04 dwhite Exp $

but there is no difference.  ifconfig shows that powersavemode is off,
and it can't be turned on either.  Perhaps normal?

# ifconfig -v ath0
ath0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        ether 00:05:4e:4e:1f:c7
        inet 193.10.66.253 netmask 0xfffffc00 broadcast 193.10.67.255
        media: IEEE 802.11 Wireless Ethernet autoselect (OFDM/36Mbps)
        status: associated
        ssid SICS channel 1 (2412 Mhz 11g) bssid 00:13:1a:47:7a:33
        authmode OPEN privacy OFF deftxkey UNDEF powersavemode OFF
        powersavesleep 100 txpower 31.5 txpowmax 17.0 rtsthreshold 2346
        fragthreshold 2346 bmiss 7 scanvalid 60 bgscan bgscanintvl 300
        bgscanidle 250 roam:rssi11a 7 roam:rate11a 12 roam:rssi11b 7
        roam:rate11b 1 roam:rssi11g 7 roam:rate11g 5 -pureg protmode CTS -ht
        -htcompat -ampdu ampdulimit 8k ampdudensity - -amsdu -shortgi
        htprotmode RTSCTS -puren -wme burst -ff -dturbo roaming AUTO
        bintval 100

# ifconfig ath0 powersave
ifconfig: SIOCS80211: Invalid argument

OK, now what?  I turned on "wlandebug power+state" which revealed this
during packet queueup.  There is one second between each frame (ping
packets):

ath0: [00:13:1a:47:7a:33] sta power save mode on
ath0: [00:13:1a:47:7a:33] save frame with age 40, 1 now queued
ath0: [00:13:1a:47:7a:33] save frame with age 0, 2 now queued
ath0: [00:13:1a:47:7a:33] save frame with age 0, 3 now queued
ath0: [00:13:1a:47:7a:33] save frame with age 0, 4 now queued
ath0: [00:13:1a:47:7a:33] save frame with age 0, 5 now queued
ath0: [00:13:1a:47:7a:33] save frame with age 0, 6 now queued
ath0: [00:13:1a:47:7a:33] save frame with age 0, 7 now queued
ath0: [00:13:1a:47:7a:33] save frame with age 0, 8 now queued
ath0: [00:13:1a:47:7a:33] save frame with age 0, 9 now queued
ath0: [00:13:1a:47:7a:33] save frame with age 0, 10 now queued
ath0: [00:13:1a:47:7a:33] save frame with age 0, 11 now queued
ath0: [00:13:1a:47:7a:33] save frame with age 0, 12 now queued
ath0: [00:13:1a:47:7a:33] save frame with age 0, 13 now queued
ath0: [00:13:1a:47:7a:33] save frame with age 0, 14 now queued
ath0: [00:13:1a:47:7a:33] save frame with age 0, 15 now queued
ath0: [00:13:1a:47:7a:33] save frame with age 0, 16 now queued
ath0: [00:13:1a:47:7a:33] save frame with age 0, 17 now queued
ath0: [00:13:1a:47:7a:33] save frame with age 0, 18 now queued
ath0: [00:13:1a:47:7a:33] save frame with age 0, 19 now queued
ath0: [00:13:1a:47:7a:33] save frame with age 0, 20 now queued
ath0: [00:13:1a:47:7a:33] save frame with age 0, 21 now queued
ath0: [00:13:1a:47:7a:33] save frame with age 0, 22 now queued
ath0: [00:13:1a:47:7a:33] save frame with age 0, 23 now queued
ath0: [00:13:1a:47:7a:33] save frame with age 0, 24 now queued
ath0: [00:13:1a:47:7a:33] save frame with age 0, 25 now queued
ath0: [00:13:1a:47:7a:33] save frame with age 0, 26 now queued
ath0: [00:13:1a:47:7a:33] save frame with age 0, 27 now queued
ath0: [00:13:1a:47:7a:33] save frame with age 0, 28 now queued
ath0: [00:13:1a:47:7a:33] save frame with age 0, 29 now queued
ath0: [00:13:1a:47:7a:33] save frame with age 0, 30 now queued
ath0: [00:13:1a:47:7a:33] save frame with age 0, 31 now queued
ath0: [00:13:1a:47:7a:33] save frame with age 0, 32 now queued
ath0: [00:13:1a:47:7a:33] sta power save mode off
ath0: [00:13:1a:47:7a:33] flush ps queue, 32 packets queued

After reading some code, trying with "wlanstats scan", both at hz=100
and 1000, I discovered that while it is scanning, it uses the power
save logic to hold packets.  But something goes wrong when hz is too
low.

Below is the printout of the log for a full scan with "wlanstats
scan+power+state".  It takes several minutes because it halts after
several "scan_next: stopped".  So, the scanning is the culprit.  I bet
that there is a race condition in the scanning logic!

One thing to note is that callout_reset is called with ticks=0 in
several places.  That will be interpreted as 1, that is, the callout
won't be called immediately, but at the next clock tick.

Bengt

ath0: ieee80211_bg_scan: active scan, ticks 84796 duration 15
ath0: [00:13:1a:47:7a:33] sta power save mode on
ath0: scan_next: chan   1g ->   1g [active, dwell min 2 max 15]
ath0: ieee80211_add_scan: chan   1g min dwell met (84799 > 84799)
ath0: scan_next: chan   1g ->   6g [active, dwell min 2 max 12]
ath0: ieee80211_add_scan: chan   6g min dwell met (84802 > 84802)
ath0: scan_next: chan   6g ->  11g [active, dwell min 2 max 9]
ath0: ieee80211_add_scan: chan  11g min dwell met (84807 > 84805)
ath0: scan_next: chan  11g ->   7g [active, dwell min 2 max 4]
ath0: scan_next: stopped, [ticks 84812, dwell min 2 scanend 84812]
ath0: ieee80211_bg_scan: active scan, ticks 87315 duration 15
ath0: scan_next: chan   1g ->  13g [passive, dwell min 2 max 14]
ath0: scan_next: stopped, [ticks 87330, dwell min 2 scanend 87330]
ath0: ieee80211_bg_scan: active scan, ticks 87335 duration 15
ath0: scan_next: chan   1g ->  52a [passive, dwell min 2 max 14]
ath0: scan_next: stopped, [ticks 87350, dwell min 2 scanend 87350]
ath0: ieee80211_bg_scan: active scan, ticks 87356 duration 15
ath0: scan_next: chan   1g ->  56a [passive, dwell min 2 max 14]
ath0: scan_next: stopped, [ticks 87371, dwell min 2 scanend 87371]
ath0: ieee80211_bg_scan: active scan, ticks 87377 duration 15
ath0: scan_next: chan   1g ->  60a [passive, dwell min 2 max 14]
ath0: scan_next: stopped, [ticks 87392, dwell min 2 scanend 87392]
ath0: ieee80211_bg_scan: active scan, ticks 87397 duration 15
ath0: scan_next: chan   1g ->  64a [passive, dwell min 2 max 14]
ath0: scan_next: stopped, [ticks 87412, dwell min 2 scanend 87412]
ath0: ieee80211_bg_scan: active scan, ticks 87478 duration 15
ath0: scan_next: chan   1g ->  36a [passive, dwell min 2 max 14]
ath0: scan_next: stopped, [ticks 87493, dwell min 2 scanend 87493]
ath0: ieee80211_bg_scan: active scan, ticks 87499 duration 15
ath0: scan_next: chan   1g ->  40a [passive, dwell min 2 max 14]
ath0: scan_next: stopped, [ticks 87514, dwell min 2 scanend 87514]
ath0: ieee80211_bg_scan: active scan, ticks 87519 duration 15
ath0: scan_next: chan   1g ->  44a [passive, dwell min 2 max 14]
ath0: scan_next: stopped, [ticks 87534, dwell min 2 scanend 87534]
ath0: ieee80211_bg_scan: active scan, ticks 87540 duration 15
ath0: scan_next: chan   1g ->  48a [passive, dwell min 2 max 14]
ath0: scan_next: stopped, [ticks 87555, dwell min 2 scanend 87555]
ath0: ieee80211_bg_scan: active scan, ticks 87560 duration 15
ath0: scan_next: chan   1g ->  34a [passive, dwell min 2 max 14]
ath0: scan_next: stopped, [ticks 87575, dwell min 2 scanend 87575]
ath0: ieee80211_bg_scan: active scan, ticks 87581 duration 15
ath0: scan_next: chan   1g ->  38a [passive, dwell min 2 max 14]
ath0: scan_next: stopped, [ticks 87596, dwell min 2 scanend 87596]
ath0: ieee80211_bg_scan: active scan, ticks 87601 duration 15
ath0: scan_next: chan   1g ->  42a [passive, dwell min 2 max 14]
ath0: scan_next: stopped, [ticks 87616, dwell min 2 scanend 87616]
ath0: ieee80211_bg_scan: active scan, ticks 87622 duration 15
ath0: scan_next: chan   1g ->  46a [passive, dwell min 2 max 14]
ath0: scan_next: stopped, [ticks 87637, dwell min 2 scanend 87637]
ath0: ieee80211_bg_scan: active scan, ticks 87642 duration 15
ath0: scan_next: chan   1g ->   2g [active, dwell min 2 max 14]
ath0: scan_next: stopped, [ticks 87657, dwell min 2 scanend 87657]
ath0: ieee80211_bg_scan: active scan, ticks 90151 duration 15
ath0: scan_next: chan   1g ->   3g [active, dwell min 2 max 14]
ath0: scan_next: stopped, [ticks 90166, dwell min 2 scanend 90166]
ath0: ieee80211_bg_scan: active scan, ticks 92660 duration 15
ath0: scan_next: chan   1g ->   4g [active, dwell min 2 max 14]
ath0: scan_next: stopped, [ticks 92675, dwell min 2 scanend 92675]
ath0: beacon miss
ath0: ieee80211_bg_scan: active scan, ticks 95271 duration 15
ath0: scan_next: chan   1g ->   5g [active, dwell min 2 max 14]
ath0: scan_next: stopped, [ticks 95286, dwell min 2 scanend 95286]
ath0: beacon miss
ath0: ieee80211_bg_scan: active scan, ticks 99715 duration 15
ath0: scan_next: chan   1g ->   8g [active, dwell min 2 max 14]
ath0: scan_next: stopped, [ticks 99730, dwell min 2 scanend 99730]
ath0: ieee80211_bg_scan: active scan, ticks 102224 duration 15
ath0: scan_next: chan   1g ->   9g [active, dwell min 2 max 14]
ath0: scan_next: stopped, [ticks 102239, dwell min 2 scanend 102239]
ath0: ieee80211_bg_scan: active scan, ticks 104732 duration 15
ath0: scan_next: chan   1g ->  10g [active, dwell min 2 max 14]
ath0: scan_next: stopped, [ticks 104747, dwell min 2 scanend 104747]
ath0: ieee80211_bg_scan: active scan, ticks 107241 duration 15
ath0: scan_next: chan   1g ->  12g [passive, dwell min 2 max 14]
ath0: scan_next: stopped, [ticks 107256, dwell min 2 scanend 107256]
ath0: ieee80211_bg_scan: active scan, ticks 107263 duration 15
ath0: scan_next: chan   1g ->  14b [passive, dwell min 2 max 14]
ath0: scan_next: stopped, [ticks 107278, dwell min 2 scanend 107278]
ath0: ieee80211_bg_scan: active scan, ticks 107282 duration 15
ath0: scan_next: chan   1g -> 149a [passive, dwell min 2 max 14]
ath0: scan_next: stopped, [ticks 107297, dwell min 2 scanend 107297]
ath0: ieee80211_bg_scan: active scan, ticks 107303 duration 15
ath0: scan_next: chan   1g -> 153a [passive, dwell min 2 max 14]
ath0: scan_next: stopped, [ticks 107318, dwell min 2 scanend 107318]
ath0: ieee80211_bg_scan: active scan, ticks 107323 duration 15
ath0: scan_next: chan   1g -> 157a [passive, dwell min 2 max 14]
ath0: scan_next: stopped, [ticks 107338, dwell min 2 scanend 107338]
ath0: ieee80211_bg_scan: active scan, ticks 107344 duration 15
ath0: scan_next: chan   1g -> 161a [passive, dwell min 2 max 14]
ath0: scan_next: stopped, [ticks 107359, dwell min 2 scanend 107359]
ath0: ieee80211_bg_scan: active scan, ticks 107366 duration 15
ath0: scan_next: chan   1g -> 165a [passive, dwell min 2 max 14]
ath0: scan_next: stopped, [ticks 107381, dwell min 2 scanend 107381]
ath0: ieee80211_bg_scan: active scan, ticks 107385 duration 15
ath0: scan_next: chan   1g -> 100a [passive, dwell min 2 max 14]
ath0: scan_next: stopped, [ticks 107400, dwell min 2 scanend 107400]
ath0: ieee80211_bg_scan: active scan, ticks 107405 duration 15
ath0: scan_next: chan   1g -> 104a [passive, dwell min 2 max 14]
ath0: scan_next: stopped, [ticks 107420, dwell min 2 scanend 107420]
ath0: ieee80211_bg_scan: active scan, ticks 107426 duration 15
ath0: scan_next: chan   1g -> 108a [passive, dwell min 2 max 14]
ath0: scan_next: stopped, [ticks 107441, dwell min 2 scanend 107441]
ath0: ieee80211_bg_scan: active scan, ticks 107446 duration 15
ath0: scan_next: chan   1g -> 112a [passive, dwell min 2 max 14]
ath0: scan_next: stopped, [ticks 107461, dwell min 2 scanend 107461]
ath0: ieee80211_bg_scan: active scan, ticks 107467 duration 15
ath0: scan_next: chan   1g -> 116a [passive, dwell min 2 max 14]
ath0: scan_next: stopped, [ticks 107482, dwell min 2 scanend 107482]
ath0: ieee80211_bg_scan: active scan, ticks 107487 duration 15
ath0: scan_next: chan   1g -> 120a [passive, dwell min 2 max 14]
ath0: scan_next: stopped, [ticks 107502, dwell min 2 scanend 107502]
ath0: ieee80211_bg_scan: active scan, ticks 107507 duration 15
ath0: scan_next: chan   1g -> 124a [passive, dwell min 2 max 14]
ath0: scan_next: stopped, [ticks 107522, dwell min 2 scanend 107522]
ath0: ieee80211_bg_scan: active scan, ticks 107528 duration 15
ath0: scan_next: chan   1g -> 128a [passive, dwell min 2 max 14]
ath0: scan_next: stopped, [ticks 107543, dwell min 2 scanend 107543]
ath0: ieee80211_bg_scan: active scan, ticks 107548 duration 15
ath0: scan_next: chan   1g -> 132a [passive, dwell min 2 max 14]
ath0: scan_next: stopped, [ticks 107563, dwell min 2 scanend 107563]
ath0: ieee80211_bg_scan: active scan, ticks 107569 duration 15
ath0: scan_next: chan   1g -> 136a [passive, dwell min 2 max 14]
ath0: scan_next: stopped, [ticks 107584, dwell min 2 scanend 107584]
ath0: ieee80211_bg_scan: active scan, ticks 107589 duration 15
ath0: scan_next: chan   1g -> 140a [passive, dwell min 2 max 14]
ath0: scan_next: done, [ticks 107604, dwell min 2 scanend 107604]
ath0: [00:13:1a:47:7a:33] sta power save mode off
ath0: notify scan done
From sam at freebsd.org  Wed Feb 18 10:27:39 2009
From: sam at freebsd.org (Sam Leffler)
Date: Wed Feb 18 10:27:50 2009
Subject: Problems with ath at kern.hz=100
In-Reply-To: <uh7skmby5da.fsf@P142.sics.se>
References: <uh7iqnjzzi9.fsf@P142.sics.se>	<20090210154047.N38905@sola.nimnet.asn.au>	<4991ABA0.4050300@freebsd.org>
	<uh7fximfatw.fsf@P142.sics.se>	<4991DB1F.7060809@freebsd.org>
	<uh7y6w4zwsq.fsf@P142.sics.se>	<499B1E7B.2030908@freebsd.org>
	<uh7eixwm5o9.fsf@P142.sics.se>	<uh7eixvlvwo.fsf@P142.sics.se>
	<uh7skmby5da.fsf@P142.sics.se>
Message-ID: <499C5319.10306@freebsd.org>

Bengt Ahlgren wrote:
> Bengt Ahlgren <bengta@sics.se> writes:
>
>   
>> Bengt Ahlgren <bengta@sics.se> writes:
>>
>>     
>>> Sam Leffler <sam@freebsd.org> writes:
>>>
>>>       
>>>> Bengt Ahlgren wrote:
>>>>         
>>>>> Sam Leffler <sam@freebsd.org> writes:
>>>>>
>>>>> [...]
>>>>>
>>>>>   
>>>>>           
>>>>>> You've removed all the context of the original problem; I can't recall
>>>>>> what you were trying to fix.  The ps q drops might be caused by a bug
>>>>>> that was fixed (I think in RELENG_7).  I don't see what version of
>>>>>> code you're running so can't tell.
>>>>>>     
>>>>>>             
>>>>> Sorry, a summary of the problem:
>>>>>
>>>>> The system frequently comes into a state where outgoing packets are
>>>>> held somewhere.  The condition persists for seconds to minutes.  It
>>>>> goes away by itself, but some of the packets are usually lost.  This
>>>>> occurs on ath, FreeBSD 7.1-REL, no SMP, with kern.hz=100 (but not with
>>>>> hz=1000).  Original mail with description can be found here:
>>>>>
>>>>> http://lists.freebsd.org/pipermail/freebsd-mobile/2009-February/011343.html
>>>>>
>>>>> I have done some more investigation, inserting debug prints in
>>>>> ath_start (if_ath.c 1.177.2.2.2.1), one just after IFQ_DRV_DEQUEUE
>>>>> (line 1576), another just before the call to ieee80211_pwrsave (line
>>>>> 1614).
>>>>>
>>>>> Packets are dequeued, but ieee80211_pwrsave is called and nothing
>>>>> happens.  Below is the output from "athdebug xmit" with these extra
>>>>> two DPRINTF:s during the queue-up.  Then after a while packets are
>>>>> sent again.
>>>>>
>>>>> Bengt
>>>>>
>>>>>   
>>>>>           
>>>> <...debug output removed...>
>>>>
>>>> Did you try RELENG_7? ap mode power save was fixed post 7.1 release.
>>>>         
>>> I can do that, but I am not using ap mode.  Will it still be useful?
>>>       
>> Hmm, I see no difference in ath between 7.1-REL and RELENG_7 (besides
>> CVS ID strings)???  Are you meaning HEAD?  If so, can I just drop in
>> src/sys/dev/ath from HEAD in 7.1R?
>>     
>
> You are meaning sys/net80211, right?  I dropped the RELENG_7 version
> of that into my 7.1-REL tree:
>
> # ident /boot/kernel/kernel | grep ieee80211_power
>      $FreeBSD: src/sys/net80211/ieee80211_power.c,v 1.2.2.1 2009/01/26 20:24:04 dwhite Exp $
>
> but there is no difference.  ifconfig shows that powersavemode is off,
> and it can't be turned on either.  Perhaps normal?
>   

Yes, there is no sta mode power save support for ath (or any other 
driver that depends on net80211 for doing it).

> # ifconfig -v ath0
> ath0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
>         ether 00:05:4e:4e:1f:c7
>         inet 193.10.66.253 netmask 0xfffffc00 broadcast 193.10.67.255
>         media: IEEE 802.11 Wireless Ethernet autoselect (OFDM/36Mbps)
>         status: associated
>         ssid SICS channel 1 (2412 Mhz 11g) bssid 00:13:1a:47:7a:33
>         authmode OPEN privacy OFF deftxkey UNDEF powersavemode OFF
>         powersavesleep 100 txpower 31.5 txpowmax 17.0 rtsthreshold 2346
>         fragthreshold 2346 bmiss 7 scanvalid 60 bgscan bgscanintvl 300
>         bgscanidle 250 roam:rssi11a 7 roam:rate11a 12 roam:rssi11b 7
>         roam:rate11b 1 roam:rssi11g 7 roam:rate11g 5 -pureg protmode CTS -ht
>         -htcompat -ampdu ampdulimit 8k ampdudensity - -amsdu -shortgi
>         htprotmode RTSCTS -puren -wme burst -ff -dturbo roaming AUTO
>         bintval 100
>
> # ifconfig ath0 powersave
> ifconfig: SIOCS80211: Invalid argument
>
> OK, now what?  I turned on "wlandebug power+state" which revealed this
> during packet queueup.  There is one second between each frame (ping
> packets):
>
> ath0: [00:13:1a:47:7a:33] sta power save mode on
> ath0: [00:13:1a:47:7a:33] save frame with age 40, 1 now queued
> ath0: [00:13:1a:47:7a:33] save frame with age 0, 2 now queued
> ath0: [00:13:1a:47:7a:33] save frame with age 0, 3 now queued
> ath0: [00:13:1a:47:7a:33] save frame with age 0, 4 now queued
> ath0: [00:13:1a:47:7a:33] save frame with age 0, 5 now queued
> ath0: [00:13:1a:47:7a:33] save frame with age 0, 6 now queued
> ath0: [00:13:1a:47:7a:33] save frame with age 0, 7 now queued
> ath0: [00:13:1a:47:7a:33] save frame with age 0, 8 now queued
> ath0: [00:13:1a:47:7a:33] save frame with age 0, 9 now queued
> ath0: [00:13:1a:47:7a:33] save frame with age 0, 10 now queued
> ath0: [00:13:1a:47:7a:33] save frame with age 0, 11 now queued
> ath0: [00:13:1a:47:7a:33] save frame with age 0, 12 now queued
> ath0: [00:13:1a:47:7a:33] save frame with age 0, 13 now queued
> ath0: [00:13:1a:47:7a:33] save frame with age 0, 14 now queued
> ath0: [00:13:1a:47:7a:33] save frame with age 0, 15 now queued
> ath0: [00:13:1a:47:7a:33] save frame with age 0, 16 now queued
> ath0: [00:13:1a:47:7a:33] save frame with age 0, 17 now queued
> ath0: [00:13:1a:47:7a:33] save frame with age 0, 18 now queued
> ath0: [00:13:1a:47:7a:33] save frame with age 0, 19 now queued
> ath0: [00:13:1a:47:7a:33] save frame with age 0, 20 now queued
> ath0: [00:13:1a:47:7a:33] save frame with age 0, 21 now queued
> ath0: [00:13:1a:47:7a:33] save frame with age 0, 22 now queued
> ath0: [00:13:1a:47:7a:33] save frame with age 0, 23 now queued
> ath0: [00:13:1a:47:7a:33] save frame with age 0, 24 now queued
> ath0: [00:13:1a:47:7a:33] save frame with age 0, 25 now queued
> ath0: [00:13:1a:47:7a:33] save frame with age 0, 26 now queued
> ath0: [00:13:1a:47:7a:33] save frame with age 0, 27 now queued
> ath0: [00:13:1a:47:7a:33] save frame with age 0, 28 now queued
> ath0: [00:13:1a:47:7a:33] save frame with age 0, 29 now queued
> ath0: [00:13:1a:47:7a:33] save frame with age 0, 30 now queued
> ath0: [00:13:1a:47:7a:33] save frame with age 0, 31 now queued
> ath0: [00:13:1a:47:7a:33] save frame with age 0, 32 now queued
> ath0: [00:13:1a:47:7a:33] sta power save mode off
> ath0: [00:13:1a:47:7a:33] flush ps queue, 32 packets queued
>
> After reading some code, trying with "wlanstats scan", both at hz=100
> and 1000, I discovered that while it is scanning, it uses the power
> save logic to hold packets.  But something goes wrong when hz is too
> low.
>   

The ap is told the sta is in power save while off channel but scanning 
should return to the bss channel often to collect frames the ap might 
have buffered for it. Also any bg scan should be canceled if there are 
outbound frames; it appears from the above this is not happening.

> Below is the printout of the log for a full scan with "wlanstats
> scan+power+state".  It takes several minutes because it halts after
> several "scan_next: stopped".  So, the scanning is the culprit.  I bet
> that there is a race condition in the scanning logic!
>
> One thing to note is that callout_reset is called with ticks=0 in
> several places.  That will be interpreted as 1, that is, the callout
> won't be called immediately, but at the next clock tick.
>
> Bengt
>
> ath0: ieee80211_bg_scan: active scan, ticks 84796 duration 15
> ath0: [00:13:1a:47:7a:33] sta power save mode on
> ath0: scan_next: chan   1g ->   1g [active, dwell min 2 max 15]
> ath0: ieee80211_add_scan: chan   1g min dwell met (84799 > 84799)
> ath0: scan_next: chan   1g ->   6g [active, dwell min 2 max 12]
> ath0: ieee80211_add_scan: chan   6g min dwell met (84802 > 84802)
> ath0: scan_next: chan   6g ->  11g [active, dwell min 2 max 9]
> ath0: ieee80211_add_scan: chan  11g min dwell met (84807 > 84805)
> ath0: scan_next: chan  11g ->   7g [active, dwell min 2 max 4]
> ath0: scan_next: stopped, [ticks 84812, dwell min 2 scanend 84812]
> ath0: ieee80211_bg_scan: active scan, ticks 87315 duration 15
> ath0: scan_next: chan   1g ->  13g [passive, dwell min 2 max 14]
> ath0: scan_next: stopped, [ticks 87330, dwell min 2 scanend 87330]
> ath0: ieee80211_bg_scan: active scan, ticks 87335 duration 15
> ath0: scan_next: chan   1g ->  52a [passive, dwell min 2 max 14]
> ath0: scan_next: stopped, [ticks 87350, dwell min 2 scanend 87350]
> ath0: ieee80211_bg_scan: active scan, ticks 87356 duration 15
> ath0: scan_next: chan   1g ->  56a [passive, dwell min 2 max 14]
> ath0: scan_next: stopped, [ticks 87371, dwell min 2 scanend 87371]
> ath0: ieee80211_bg_scan: active scan, ticks 87377 duration 15
> ath0: scan_next: chan   1g ->  60a [passive, dwell min 2 max 14]
> ath0: scan_next: stopped, [ticks 87392, dwell min 2 scanend 87392]
> ath0: ieee80211_bg_scan: active scan, ticks 87397 duration 15
> ath0: scan_next: chan   1g ->  64a [passive, dwell min 2 max 14]
> ath0: scan_next: stopped, [ticks 87412, dwell min 2 scanend 87412]
> ath0: ieee80211_bg_scan: active scan, ticks 87478 duration 15
> ath0: scan_next: chan   1g ->  36a [passive, dwell min 2 max 14]
> ath0: scan_next: stopped, [ticks 87493, dwell min 2 scanend 87493]
> ath0: ieee80211_bg_scan: active scan, ticks 87499 duration 15
> ath0: scan_next: chan   1g ->  40a [passive, dwell min 2 max 14]
> ath0: scan_next: stopped, [ticks 87514, dwell min 2 scanend 87514]
> ath0: ieee80211_bg_scan: active scan, ticks 87519 duration 15
> ath0: scan_next: chan   1g ->  44a [passive, dwell min 2 max 14]
> ath0: scan_next: stopped, [ticks 87534, dwell min 2 scanend 87534]
> ath0: ieee80211_bg_scan: active scan, ticks 87540 duration 15
> ath0: scan_next: chan   1g ->  48a [passive, dwell min 2 max 14]
> ath0: scan_next: stopped, [ticks 87555, dwell min 2 scanend 87555]
> ath0: ieee80211_bg_scan: active scan, ticks 87560 duration 15
> ath0: scan_next: chan   1g ->  34a [passive, dwell min 2 max 14]
> ath0: scan_next: stopped, [ticks 87575, dwell min 2 scanend 87575]
> ath0: ieee80211_bg_scan: active scan, ticks 87581 duration 15
> ath0: scan_next: chan   1g ->  38a [passive, dwell min 2 max 14]
> ath0: scan_next: stopped, [ticks 87596, dwell min 2 scanend 87596]
> ath0: ieee80211_bg_scan: active scan, ticks 87601 duration 15
> ath0: scan_next: chan   1g ->  42a [passive, dwell min 2 max 14]
> ath0: scan_next: stopped, [ticks 87616, dwell min 2 scanend 87616]
> ath0: ieee80211_bg_scan: active scan, ticks 87622 duration 15
> ath0: scan_next: chan   1g ->  46a [passive, dwell min 2 max 14]
> ath0: scan_next: stopped, [ticks 87637, dwell min 2 scanend 87637]
> ath0: ieee80211_bg_scan: active scan, ticks 87642 duration 15
> ath0: scan_next: chan   1g ->   2g [active, dwell min 2 max 14]
> ath0: scan_next: stopped, [ticks 87657, dwell min 2 scanend 87657]
> ath0: ieee80211_bg_scan: active scan, ticks 90151 duration 15
> ath0: scan_next: chan   1g ->   3g [active, dwell min 2 max 14]
> ath0: scan_next: stopped, [ticks 90166, dwell min 2 scanend 90166]
> ath0: ieee80211_bg_scan: active scan, ticks 92660 duration 15
> ath0: scan_next: chan   1g ->   4g [active, dwell min 2 max 14]
> ath0: scan_next: stopped, [ticks 92675, dwell min 2 scanend 92675]
> ath0: beacon miss
> ath0: ieee80211_bg_scan: active scan, ticks 95271 duration 15
> ath0: scan_next: chan   1g ->   5g [active, dwell min 2 max 14]
> ath0: scan_next: stopped, [ticks 95286, dwell min 2 scanend 95286]
> ath0: beacon miss
> ath0: ieee80211_bg_scan: active scan, ticks 99715 duration 15
> ath0: scan_next: chan   1g ->   8g [active, dwell min 2 max 14]
> ath0: scan_next: stopped, [ticks 99730, dwell min 2 scanend 99730]
> ath0: ieee80211_bg_scan: active scan, ticks 102224 duration 15
> ath0: scan_next: chan   1g ->   9g [active, dwell min 2 max 14]
> ath0: scan_next: stopped, [ticks 102239, dwell min 2 scanend 102239]
> ath0: ieee80211_bg_scan: active scan, ticks 104732 duration 15
> ath0: scan_next: chan   1g ->  10g [active, dwell min 2 max 14]
> ath0: scan_next: stopped, [ticks 104747, dwell min 2 scanend 104747]
> ath0: ieee80211_bg_scan: active scan, ticks 107241 duration 15
> ath0: scan_next: chan   1g ->  12g [passive, dwell min 2 max 14]
> ath0: scan_next: stopped, [ticks 107256, dwell min 2 scanend 107256]
> ath0: ieee80211_bg_scan: active scan, ticks 107263 duration 15
> ath0: scan_next: chan   1g ->  14b [passive, dwell min 2 max 14]
> ath0: scan_next: stopped, [ticks 107278, dwell min 2 scanend 107278]
> ath0: ieee80211_bg_scan: active scan, ticks 107282 duration 15
> ath0: scan_next: chan   1g -> 149a [passive, dwell min 2 max 14]
> ath0: scan_next: stopped, [ticks 107297, dwell min 2 scanend 107297]
> ath0: ieee80211_bg_scan: active scan, ticks 107303 duration 15
> ath0: scan_next: chan   1g -> 153a [passive, dwell min 2 max 14]
> ath0: scan_next: stopped, [ticks 107318, dwell min 2 scanend 107318]
> ath0: ieee80211_bg_scan: active scan, ticks 107323 duration 15
> ath0: scan_next: chan   1g -> 157a [passive, dwell min 2 max 14]
> ath0: scan_next: stopped, [ticks 107338, dwell min 2 scanend 107338]
> ath0: ieee80211_bg_scan: active scan, ticks 107344 duration 15
> ath0: scan_next: chan   1g -> 161a [passive, dwell min 2 max 14]
> ath0: scan_next: stopped, [ticks 107359, dwell min 2 scanend 107359]
> ath0: ieee80211_bg_scan: active scan, ticks 107366 duration 15
> ath0: scan_next: chan   1g -> 165a [passive, dwell min 2 max 14]
> ath0: scan_next: stopped, [ticks 107381, dwell min 2 scanend 107381]
> ath0: ieee80211_bg_scan: active scan, ticks 107385 duration 15
> ath0: scan_next: chan   1g -> 100a [passive, dwell min 2 max 14]
> ath0: scan_next: stopped, [ticks 107400, dwell min 2 scanend 107400]
> ath0: ieee80211_bg_scan: active scan, ticks 107405 duration 15
> ath0: scan_next: chan   1g -> 104a [passive, dwell min 2 max 14]
> ath0: scan_next: stopped, [ticks 107420, dwell min 2 scanend 107420]
> ath0: ieee80211_bg_scan: active scan, ticks 107426 duration 15
> ath0: scan_next: chan   1g -> 108a [passive, dwell min 2 max 14]
> ath0: scan_next: stopped, [ticks 107441, dwell min 2 scanend 107441]
> ath0: ieee80211_bg_scan: active scan, ticks 107446 duration 15
> ath0: scan_next: chan   1g -> 112a [passive, dwell min 2 max 14]
> ath0: scan_next: stopped, [ticks 107461, dwell min 2 scanend 107461]
> ath0: ieee80211_bg_scan: active scan, ticks 107467 duration 15
> ath0: scan_next: chan   1g -> 116a [passive, dwell min 2 max 14]
> ath0: scan_next: stopped, [ticks 107482, dwell min 2 scanend 107482]
> ath0: ieee80211_bg_scan: active scan, ticks 107487 duration 15
> ath0: scan_next: chan   1g -> 120a [passive, dwell min 2 max 14]
> ath0: scan_next: stopped, [ticks 107502, dwell min 2 scanend 107502]
> ath0: ieee80211_bg_scan: active scan, ticks 107507 duration 15
> ath0: scan_next: chan   1g -> 124a [passive, dwell min 2 max 14]
> ath0: scan_next: stopped, [ticks 107522, dwell min 2 scanend 107522]
> ath0: ieee80211_bg_scan: active scan, ticks 107528 duration 15
> ath0: scan_next: chan   1g -> 128a [passive, dwell min 2 max 14]
> ath0: scan_next: stopped, [ticks 107543, dwell min 2 scanend 107543]
> ath0: ieee80211_bg_scan: active scan, ticks 107548 duration 15
> ath0: scan_next: chan   1g -> 132a [passive, dwell min 2 max 14]
> ath0: scan_next: stopped, [ticks 107563, dwell min 2 scanend 107563]
> ath0: ieee80211_bg_scan: active scan, ticks 107569 duration 15
> ath0: scan_next: chan   1g -> 136a [passive, dwell min 2 max 14]
> ath0: scan_next: stopped, [ticks 107584, dwell min 2 scanend 107584]
> ath0: ieee80211_bg_scan: active scan, ticks 107589 duration 15
> ath0: scan_next: chan   1g -> 140a [passive, dwell min 2 max 14]
> ath0: scan_next: done, [ticks 107604, dwell min 2 scanend 107604]
> ath0: [00:13:1a:47:7a:33] sta power save mode off
> ath0: notify scan done
>
>   
The above looks wrong; the bg scan should leave the bss channel briefly 
then return to check for frames. Instead it appears it's never 
returning. Also any outbound packets should cause the bg scan to be 
canceled (look for ieee80211_cancel_scan in ath_start).

Sam

From bengta at sics.se  Thu Feb 19 07:22:54 2009
From: bengta at sics.se (Bengt Ahlgren)
Date: Thu Feb 19 07:23:02 2009
Subject: Problems with ath at kern.hz=100
In-Reply-To: <499C5319.10306@freebsd.org> (Sam Leffler's message of "Wed\,
	18 Feb 2009 10\:27\:37 -0800")
References: <uh7iqnjzzi9.fsf@P142.sics.se>
	<20090210154047.N38905@sola.nimnet.asn.au>
	<4991ABA0.4050300@freebsd.org> <uh7fximfatw.fsf@P142.sics.se>
	<4991DB1F.7060809@freebsd.org> <uh7y6w4zwsq.fsf@P142.sics.se>
	<499B1E7B.2030908@freebsd.org> <uh7eixwm5o9.fsf@P142.sics.se>
	<uh7eixvlvwo.fsf@P142.sics.se> <uh7skmby5da.fsf@P142.sics.se>
	<499C5319.10306@freebsd.org>
Message-ID: <uh7fxia8n5q.fsf@P142.sics.se>

Sam Leffler <sam@freebsd.org> writes:

> Bengt Ahlgren wrote:
>> Bengt Ahlgren <bengta@sics.se> writes:
>>
>>   
>>> Bengt Ahlgren <bengta@sics.se> writes:
>>>
>>>     
>>>> Sam Leffler <sam@freebsd.org> writes:
>>>>
>>>>       
>>>>> Bengt Ahlgren wrote:
>>>>>         
>>>>>> Sam Leffler <sam@freebsd.org> writes:
>>>>>>
>>>>>> [...]
>>>>>>
>>>>>>             
>>>>>>> You've removed all the context of the original problem; I can't recall
>>>>>>> what you were trying to fix.  The ps q drops might be caused by a bug
>>>>>>> that was fixed (I think in RELENG_7).  I don't see what version of
>>>>>>> code you're running so can't tell.
>>>>>>>                 
>>>>>> Sorry, a summary of the problem:
>>>>>>
>>>>>> The system frequently comes into a state where outgoing packets are
>>>>>> held somewhere.  The condition persists for seconds to minutes.  It
>>>>>> goes away by itself, but some of the packets are usually lost.  This
>>>>>> occurs on ath, FreeBSD 7.1-REL, no SMP, with kern.hz=100 (but not with
>>>>>> hz=1000).  Original mail with description can be found here:
>>>>>>
>>>>>> http://lists.freebsd.org/pipermail/freebsd-mobile/2009-February/011343.html
>>>>>>
>>>>>> I have done some more investigation, inserting debug prints in
>>>>>> ath_start (if_ath.c 1.177.2.2.2.1), one just after IFQ_DRV_DEQUEUE
>>>>>> (line 1576), another just before the call to ieee80211_pwrsave (line
>>>>>> 1614).
>>>>>>
>>>>>> Packets are dequeued, but ieee80211_pwrsave is called and nothing
>>>>>> happens.  Below is the output from "athdebug xmit" with these extra
>>>>>> two DPRINTF:s during the queue-up.  Then after a while packets are
>>>>>> sent again.
>>>>>>
>>>>>> Bengt
>>>>>>
>>>>>>             
>>>>> <...debug output removed...>
>>>>>
>>>>> Did you try RELENG_7? ap mode power save was fixed post 7.1 release.
>>>>>         
>>>> I can do that, but I am not using ap mode.  Will it still be useful?
>>>>       
>>> Hmm, I see no difference in ath between 7.1-REL and RELENG_7 (besides
>>> CVS ID strings)???  Are you meaning HEAD?  If so, can I just drop in
>>> src/sys/dev/ath from HEAD in 7.1R?
>>>     
>>
>> You are meaning sys/net80211, right?  I dropped the RELENG_7 version
>> of that into my 7.1-REL tree:
>>
>> # ident /boot/kernel/kernel | grep ieee80211_power
>>      $FreeBSD: src/sys/net80211/ieee80211_power.c,v 1.2.2.1 2009/01/26 20:24:04 dwhite Exp $
>>
>> but there is no difference.  ifconfig shows that powersavemode is off,
>> and it can't be turned on either.  Perhaps normal?
>>   
>
> Yes, there is no sta mode power save support for ath (or any other
> driver that depends on net80211 for doing it).
>
>> # ifconfig -v ath0
>> ath0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
>>         ether 00:05:4e:4e:1f:c7
>>         inet 193.10.66.253 netmask 0xfffffc00 broadcast 193.10.67.255
>>         media: IEEE 802.11 Wireless Ethernet autoselect (OFDM/36Mbps)
>>         status: associated
>>         ssid SICS channel 1 (2412 Mhz 11g) bssid 00:13:1a:47:7a:33
>>         authmode OPEN privacy OFF deftxkey UNDEF powersavemode OFF
>>         powersavesleep 100 txpower 31.5 txpowmax 17.0 rtsthreshold 2346
>>         fragthreshold 2346 bmiss 7 scanvalid 60 bgscan bgscanintvl 300
>>         bgscanidle 250 roam:rssi11a 7 roam:rate11a 12 roam:rssi11b 7
>>         roam:rate11b 1 roam:rssi11g 7 roam:rate11g 5 -pureg protmode CTS -ht
>>         -htcompat -ampdu ampdulimit 8k ampdudensity - -amsdu -shortgi
>>         htprotmode RTSCTS -puren -wme burst -ff -dturbo roaming AUTO
>>         bintval 100
>>
>> # ifconfig ath0 powersave
>> ifconfig: SIOCS80211: Invalid argument
>>
>> OK, now what?  I turned on "wlandebug power+state" which revealed this
>> during packet queueup.  There is one second between each frame (ping
>> packets):
>>
>> ath0: [00:13:1a:47:7a:33] sta power save mode on
>> ath0: [00:13:1a:47:7a:33] save frame with age 40, 1 now queued
>> ath0: [00:13:1a:47:7a:33] save frame with age 0, 2 now queued
>> ath0: [00:13:1a:47:7a:33] save frame with age 0, 3 now queued
>> ath0: [00:13:1a:47:7a:33] save frame with age 0, 4 now queued
>> ath0: [00:13:1a:47:7a:33] save frame with age 0, 5 now queued
>> ath0: [00:13:1a:47:7a:33] save frame with age 0, 6 now queued
>> ath0: [00:13:1a:47:7a:33] save frame with age 0, 7 now queued
>> ath0: [00:13:1a:47:7a:33] save frame with age 0, 8 now queued
>> ath0: [00:13:1a:47:7a:33] save frame with age 0, 9 now queued
>> ath0: [00:13:1a:47:7a:33] save frame with age 0, 10 now queued
>> ath0: [00:13:1a:47:7a:33] save frame with age 0, 11 now queued
>> ath0: [00:13:1a:47:7a:33] save frame with age 0, 12 now queued
>> ath0: [00:13:1a:47:7a:33] save frame with age 0, 13 now queued
>> ath0: [00:13:1a:47:7a:33] save frame with age 0, 14 now queued
>> ath0: [00:13:1a:47:7a:33] save frame with age 0, 15 now queued
>> ath0: [00:13:1a:47:7a:33] save frame with age 0, 16 now queued
>> ath0: [00:13:1a:47:7a:33] save frame with age 0, 17 now queued
>> ath0: [00:13:1a:47:7a:33] save frame with age 0, 18 now queued
>> ath0: [00:13:1a:47:7a:33] save frame with age 0, 19 now queued
>> ath0: [00:13:1a:47:7a:33] save frame with age 0, 20 now queued
>> ath0: [00:13:1a:47:7a:33] save frame with age 0, 21 now queued
>> ath0: [00:13:1a:47:7a:33] save frame with age 0, 22 now queued
>> ath0: [00:13:1a:47:7a:33] save frame with age 0, 23 now queued
>> ath0: [00:13:1a:47:7a:33] save frame with age 0, 24 now queued
>> ath0: [00:13:1a:47:7a:33] save frame with age 0, 25 now queued
>> ath0: [00:13:1a:47:7a:33] save frame with age 0, 26 now queued
>> ath0: [00:13:1a:47:7a:33] save frame with age 0, 27 now queued
>> ath0: [00:13:1a:47:7a:33] save frame with age 0, 28 now queued
>> ath0: [00:13:1a:47:7a:33] save frame with age 0, 29 now queued
>> ath0: [00:13:1a:47:7a:33] save frame with age 0, 30 now queued
>> ath0: [00:13:1a:47:7a:33] save frame with age 0, 31 now queued
>> ath0: [00:13:1a:47:7a:33] save frame with age 0, 32 now queued
>> ath0: [00:13:1a:47:7a:33] sta power save mode off
>> ath0: [00:13:1a:47:7a:33] flush ps queue, 32 packets queued
>>
>> After reading some code, trying with "wlanstats scan", both at hz=100
>> and 1000, I discovered that while it is scanning, it uses the power
>> save logic to hold packets.  But something goes wrong when hz is too
>> low.
>>   
>
> The ap is told the sta is in power save while off channel but scanning
> should return to the bss channel often to collect frames the ap might
> have buffered for it. Also any bg scan should be canceled if there are
> outbound frames; it appears from the above this is not happening.
>
>> Below is the printout of the log for a full scan with "wlanstats
>> scan+power+state".  It takes several minutes because it halts after
>> several "scan_next: stopped".  So, the scanning is the culprit.  I bet
>> that there is a race condition in the scanning logic!
>>
>> One thing to note is that callout_reset is called with ticks=0 in
>> several places.  That will be interpreted as 1, that is, the callout
>> won't be called immediately, but at the next clock tick.
>>
>> Bengt
>>
>> ath0: ieee80211_bg_scan: active scan, ticks 84796 duration 15
>> ath0: [00:13:1a:47:7a:33] sta power save mode on
>> ath0: scan_next: chan   1g ->   1g [active, dwell min 2 max 15]
>> ath0: ieee80211_add_scan: chan   1g min dwell met (84799 > 84799)
>> ath0: scan_next: chan   1g ->   6g [active, dwell min 2 max 12]
>> ath0: ieee80211_add_scan: chan   6g min dwell met (84802 > 84802)
>> ath0: scan_next: chan   6g ->  11g [active, dwell min 2 max 9]
>> ath0: ieee80211_add_scan: chan  11g min dwell met (84807 > 84805)
>> ath0: scan_next: chan  11g ->   7g [active, dwell min 2 max 4]
>> ath0: scan_next: stopped, [ticks 84812, dwell min 2 scanend 84812]
>> ath0: ieee80211_bg_scan: active scan, ticks 87315 duration 15
>> ath0: scan_next: chan   1g ->  13g [passive, dwell min 2 max 14]
>> ath0: scan_next: stopped, [ticks 87330, dwell min 2 scanend 87330]
>> ath0: ieee80211_bg_scan: active scan, ticks 87335 duration 15
>> ath0: scan_next: chan   1g ->  52a [passive, dwell min 2 max 14]
>> ath0: scan_next: stopped, [ticks 87350, dwell min 2 scanend 87350]
>> ath0: ieee80211_bg_scan: active scan, ticks 87356 duration 15
>> ath0: scan_next: chan   1g ->  56a [passive, dwell min 2 max 14]
>> ath0: scan_next: stopped, [ticks 87371, dwell min 2 scanend 87371]
>> ath0: ieee80211_bg_scan: active scan, ticks 87377 duration 15
>> ath0: scan_next: chan   1g ->  60a [passive, dwell min 2 max 14]
>> ath0: scan_next: stopped, [ticks 87392, dwell min 2 scanend 87392]
>> ath0: ieee80211_bg_scan: active scan, ticks 87397 duration 15
>> ath0: scan_next: chan   1g ->  64a [passive, dwell min 2 max 14]
>> ath0: scan_next: stopped, [ticks 87412, dwell min 2 scanend 87412]
>> ath0: ieee80211_bg_scan: active scan, ticks 87478 duration 15
>> ath0: scan_next: chan   1g ->  36a [passive, dwell min 2 max 14]
>> ath0: scan_next: stopped, [ticks 87493, dwell min 2 scanend 87493]
>> ath0: ieee80211_bg_scan: active scan, ticks 87499 duration 15
>> ath0: scan_next: chan   1g ->  40a [passive, dwell min 2 max 14]
>> ath0: scan_next: stopped, [ticks 87514, dwell min 2 scanend 87514]
>> ath0: ieee80211_bg_scan: active scan, ticks 87519 duration 15
>> ath0: scan_next: chan   1g ->  44a [passive, dwell min 2 max 14]
>> ath0: scan_next: stopped, [ticks 87534, dwell min 2 scanend 87534]
>> ath0: ieee80211_bg_scan: active scan, ticks 87540 duration 15
>> ath0: scan_next: chan   1g ->  48a [passive, dwell min 2 max 14]
>> ath0: scan_next: stopped, [ticks 87555, dwell min 2 scanend 87555]
>> ath0: ieee80211_bg_scan: active scan, ticks 87560 duration 15
>> ath0: scan_next: chan   1g ->  34a [passive, dwell min 2 max 14]
>> ath0: scan_next: stopped, [ticks 87575, dwell min 2 scanend 87575]
>> ath0: ieee80211_bg_scan: active scan, ticks 87581 duration 15
>> ath0: scan_next: chan   1g ->  38a [passive, dwell min 2 max 14]
>> ath0: scan_next: stopped, [ticks 87596, dwell min 2 scanend 87596]
>> ath0: ieee80211_bg_scan: active scan, ticks 87601 duration 15
>> ath0: scan_next: chan   1g ->  42a [passive, dwell min 2 max 14]
>> ath0: scan_next: stopped, [ticks 87616, dwell min 2 scanend 87616]
>> ath0: ieee80211_bg_scan: active scan, ticks 87622 duration 15
>> ath0: scan_next: chan   1g ->  46a [passive, dwell min 2 max 14]
>> ath0: scan_next: stopped, [ticks 87637, dwell min 2 scanend 87637]
>> ath0: ieee80211_bg_scan: active scan, ticks 87642 duration 15
>> ath0: scan_next: chan   1g ->   2g [active, dwell min 2 max 14]
>> ath0: scan_next: stopped, [ticks 87657, dwell min 2 scanend 87657]
>> ath0: ieee80211_bg_scan: active scan, ticks 90151 duration 15
>> ath0: scan_next: chan   1g ->   3g [active, dwell min 2 max 14]
>> ath0: scan_next: stopped, [ticks 90166, dwell min 2 scanend 90166]
>> ath0: ieee80211_bg_scan: active scan, ticks 92660 duration 15
>> ath0: scan_next: chan   1g ->   4g [active, dwell min 2 max 14]
>> ath0: scan_next: stopped, [ticks 92675, dwell min 2 scanend 92675]
>> ath0: beacon miss
>> ath0: ieee80211_bg_scan: active scan, ticks 95271 duration 15
>> ath0: scan_next: chan   1g ->   5g [active, dwell min 2 max 14]
>> ath0: scan_next: stopped, [ticks 95286, dwell min 2 scanend 95286]
>> ath0: beacon miss
>> ath0: ieee80211_bg_scan: active scan, ticks 99715 duration 15
>> ath0: scan_next: chan   1g ->   8g [active, dwell min 2 max 14]
>> ath0: scan_next: stopped, [ticks 99730, dwell min 2 scanend 99730]
>> ath0: ieee80211_bg_scan: active scan, ticks 102224 duration 15
>> ath0: scan_next: chan   1g ->   9g [active, dwell min 2 max 14]
>> ath0: scan_next: stopped, [ticks 102239, dwell min 2 scanend 102239]
>> ath0: ieee80211_bg_scan: active scan, ticks 104732 duration 15
>> ath0: scan_next: chan   1g ->  10g [active, dwell min 2 max 14]
>> ath0: scan_next: stopped, [ticks 104747, dwell min 2 scanend 104747]
>> ath0: ieee80211_bg_scan: active scan, ticks 107241 duration 15
>> ath0: scan_next: chan   1g ->  12g [passive, dwell min 2 max 14]
>> ath0: scan_next: stopped, [ticks 107256, dwell min 2 scanend 107256]
>> ath0: ieee80211_bg_scan: active scan, ticks 107263 duration 15
>> ath0: scan_next: chan   1g ->  14b [passive, dwell min 2 max 14]
>> ath0: scan_next: stopped, [ticks 107278, dwell min 2 scanend 107278]
>> ath0: ieee80211_bg_scan: active scan, ticks 107282 duration 15
>> ath0: scan_next: chan   1g -> 149a [passive, dwell min 2 max 14]
>> ath0: scan_next: stopped, [ticks 107297, dwell min 2 scanend 107297]
>> ath0: ieee80211_bg_scan: active scan, ticks 107303 duration 15
>> ath0: scan_next: chan   1g -> 153a [passive, dwell min 2 max 14]
>> ath0: scan_next: stopped, [ticks 107318, dwell min 2 scanend 107318]
>> ath0: ieee80211_bg_scan: active scan, ticks 107323 duration 15
>> ath0: scan_next: chan   1g -> 157a [passive, dwell min 2 max 14]
>> ath0: scan_next: stopped, [ticks 107338, dwell min 2 scanend 107338]
>> ath0: ieee80211_bg_scan: active scan, ticks 107344 duration 15
>> ath0: scan_next: chan   1g -> 161a [passive, dwell min 2 max 14]
>> ath0: scan_next: stopped, [ticks 107359, dwell min 2 scanend 107359]
>> ath0: ieee80211_bg_scan: active scan, ticks 107366 duration 15
>> ath0: scan_next: chan   1g -> 165a [passive, dwell min 2 max 14]
>> ath0: scan_next: stopped, [ticks 107381, dwell min 2 scanend 107381]
>> ath0: ieee80211_bg_scan: active scan, ticks 107385 duration 15
>> ath0: scan_next: chan   1g -> 100a [passive, dwell min 2 max 14]
>> ath0: scan_next: stopped, [ticks 107400, dwell min 2 scanend 107400]
>> ath0: ieee80211_bg_scan: active scan, ticks 107405 duration 15
>> ath0: scan_next: chan   1g -> 104a [passive, dwell min 2 max 14]
>> ath0: scan_next: stopped, [ticks 107420, dwell min 2 scanend 107420]
>> ath0: ieee80211_bg_scan: active scan, ticks 107426 duration 15
>> ath0: scan_next: chan   1g -> 108a [passive, dwell min 2 max 14]
>> ath0: scan_next: stopped, [ticks 107441, dwell min 2 scanend 107441]
>> ath0: ieee80211_bg_scan: active scan, ticks 107446 duration 15
>> ath0: scan_next: chan   1g -> 112a [passive, dwell min 2 max 14]
>> ath0: scan_next: stopped, [ticks 107461, dwell min 2 scanend 107461]
>> ath0: ieee80211_bg_scan: active scan, ticks 107467 duration 15
>> ath0: scan_next: chan   1g -> 116a [passive, dwell min 2 max 14]
>> ath0: scan_next: stopped, [ticks 107482, dwell min 2 scanend 107482]
>> ath0: ieee80211_bg_scan: active scan, ticks 107487 duration 15
>> ath0: scan_next: chan   1g -> 120a [passive, dwell min 2 max 14]
>> ath0: scan_next: stopped, [ticks 107502, dwell min 2 scanend 107502]
>> ath0: ieee80211_bg_scan: active scan, ticks 107507 duration 15
>> ath0: scan_next: chan   1g -> 124a [passive, dwell min 2 max 14]
>> ath0: scan_next: stopped, [ticks 107522, dwell min 2 scanend 107522]
>> ath0: ieee80211_bg_scan: active scan, ticks 107528 duration 15
>> ath0: scan_next: chan   1g -> 128a [passive, dwell min 2 max 14]
>> ath0: scan_next: stopped, [ticks 107543, dwell min 2 scanend 107543]
>> ath0: ieee80211_bg_scan: active scan, ticks 107548 duration 15
>> ath0: scan_next: chan   1g -> 132a [passive, dwell min 2 max 14]
>> ath0: scan_next: stopped, [ticks 107563, dwell min 2 scanend 107563]
>> ath0: ieee80211_bg_scan: active scan, ticks 107569 duration 15
>> ath0: scan_next: chan   1g -> 136a [passive, dwell min 2 max 14]
>> ath0: scan_next: stopped, [ticks 107584, dwell min 2 scanend 107584]
>> ath0: ieee80211_bg_scan: active scan, ticks 107589 duration 15
>> ath0: scan_next: chan   1g -> 140a [passive, dwell min 2 max 14]
>> ath0: scan_next: done, [ticks 107604, dwell min 2 scanend 107604]
>> ath0: [00:13:1a:47:7a:33] sta power save mode off
>> ath0: notify scan done
>>
>>   
> The above looks wrong; the bg scan should leave the bss channel
> briefly then return to check for frames. Instead it appears it's never
> returning. Also any outbound packets should cause the bg scan to be
> canceled (look for ieee80211_cancel_scan in ath_start).

I think I am getting a bit closer to the real problem.  Check out this
sequence (run with hz=1000 NB!):

ath0: scan_next: stopped, [ticks 14980883, dwell min 20 scanend 14980873]
ath_start: dequeue packet 0xc38ef000
ath_start: power save, packet=0xc38ef000
ath0: [00:13:1a:47:7a:33] save frame with age 40, 1 now queued
ath_start: dequeue packet 0x0
ath0: ieee80211_bg_scan: active scan, ticks 14981030 duration 150
ath0: scan_next: chan   1g ->  13g [passive, dwell min 20 max 149]
ath0: scan_next: stopped, [ticks 14981190, dwell min 20 scanend 14981180]
ath0: ieee80211_bg_scan: active scan, ticks 14981236 duration 150
ath0: scan_next: chan   1g ->  52a [passive, dwell min 20 max 149]
ath0: scan_next: stopped, [ticks 14981396, dwell min 20 scanend 14981386]
ath0: ieee80211_bg_scan: active scan, ticks 14981441 duration 150
ath0: scan_next: chan   1g ->  56a [passive, dwell min 20 max 149]
ath0: scan_next: stopped, [ticks 14981601, dwell min 20 scanend 14981591]
ath0: ieee80211_bg_scan: active scan, ticks 14981645 duration 150
ath0: scan_next: chan   1g ->  60a [passive, dwell min 20 max 149]
ath0: scan_next: stopped, [ticks 14981805, dwell min 20 scanend 14981795]
ath0: ieee80211_bg_scan: active scan, ticks 14981850 duration 150
ath0: scan_next: chan   1g ->  64a [passive, dwell min 20 max 149]
ath0: scan_next: stopped, [ticks 14982010, dwell min 20 scanend 14982000]
ath0: ieee80211_bg_scan: active scan, ticks 14982059 duration 150
ath0: scan_next: chan   1g ->  36a [passive, dwell min 20 max 149]
ath0: scan_next: stopped, [ticks 14982219, dwell min 20 scanend 14982209]
ath0: ieee80211_bg_scan: active scan, ticks 14982259 duration 150
ath0: scan_next: chan   1g ->  40a [passive, dwell min 20 max 149]
ath0: scan_next: stopped, [ticks 14982419, dwell min 20 scanend 14982409]
ath0: ieee80211_bg_scan: active scan, ticks 14982467 duration 150
ath0: scan_next: chan   1g ->  44a [passive, dwell min 20 max 149]
ath0: scan_next: stopped, [ticks 14982627, dwell min 20 scanend 14982617]
ath0: ieee80211_bg_scan: active scan, ticks 14982669 duration 150
ath0: scan_next: chan   1g ->  48a [passive, dwell min 20 max 149]
ath0: scan_next: stopped, [ticks 14982829, dwell min 20 scanend 14982819]
ath0: ieee80211_bg_scan: active scan, ticks 14982874 duration 150
ath0: scan_next: chan   1g ->  34a [passive, dwell min 20 max 149]
ath0: scan_next: stopped, [ticks 14983034, dwell min 20 scanend 14983024]
ath0: ieee80211_bg_scan: active scan, ticks 14983079 duration 150
ath0: scan_next: chan   1g ->  38a [passive, dwell min 20 max 149]
ath0: scan_next: stopped, [ticks 14983239, dwell min 20 scanend 14983229]
ath0: ieee80211_bg_scan: active scan, ticks 14983283 duration 150
ath0: scan_next: chan   1g ->  42a [passive, dwell min 20 max 149]
ath0: scan_next: stopped, [ticks 14983443, dwell min 20 scanend 14983433]
ath0: ieee80211_bg_scan: active scan, ticks 14983488 duration 150
ath0: scan_next: chan   1g ->  46a [passive, dwell min 20 max 149]
ath_start: dequeue packet 0xc37d4d00
ath0: ieee80211_cancel_scan: cancel active scan
ath_start: power save, packet=0xc37d4d00
ath0: [00:13:1a:47:7a:33] save frame with age 0, 2 now queued
ath_start: dequeue packet 0x0
ath0: scan_next: done, [ticks 14983598, dwell min 20 scanend 14983638]
ath0: [00:13:1a:47:7a:33] sta power save mode off

Now, when the first packet arrives (top of the log), IEEE80211_F_SCAN
is NOT set.  scan_next just cleared the flag (line 816 in
ieee80211_scan.c), but because it is not done scanning, power save is
still on.  So, ath_start does not call ieee80211_cancel_scan, but
rather just queues the packet.

When the next packet arrives (bottom of the log), it happens to be in
the middle of a scan period, so IEEE80211_F_SCAN is set, and ath_start
calls ieee80211_cancel_scan, terminating the scan (well after a little
while at least).

Question: after scan_next is run, reporting "stopped", what makes
ieee80211_bg_scan to be called the next time?  In the time between
these two events, IEEE80211_F_SCAN is not set, but power save is "on",
making all packets queue up.  This window apparently gets larger the
lower hz you run on.

IMO, it would be better that ieee80211_cancel_scan immediately
terminated scanning and did callout_drain on scan_next.  But that does
not close the window when IEEE80211_F_SCAN is not set.  So either the
scanning logic needs to change, or the test in ath_start.

Bengt
From ascholles at yahoo.com  Fri Feb 20 15:22:15 2009
From: ascholles at yahoo.com (ALLEN SCHOLLES)
Date: Fri Feb 20 15:24:25 2009
Subject: Fresh Cut BG, SBLC, MTN, Bonds and CDs For Lease
Message-ID: <9A.DB.22976.4D73F994@ec5>

Hello,

We are direct providers of Fresh Cut BG, SBLC, MTN, Bonds and CDs, which we have specifically for lease. We do not have any broker chain in this offer or get involved in Chauffeur driven offers. We deliver with time and precision as set forth in the agreement. You are at liberty to engage our leased facilities into trade programs as well as in signature project(s) such as Aviation, Agriculture, Automobile, Petroleum, Telecommunication, construction of Dams, Bridges and any other turnkey project(s) etc. Our terms and Conditions are reasonable.
For further details and procedure. Please contact Allen.

Email:- allenscholles@ymail.com
Tel:-      44-208-099-9129

Why Do 8 of 10 Companies Use Leasing To Acquire Equipment?

? PROTECTS AND PRESERVES BANK AND CREDIT LINES
CONSERVING WORKING CAPITAL AND MAXIMIZING ? CASH FLOW


? OVERCOMES BUDGET LIMITATIONS WHILE SIMPLIFYING CURRENT BUDGETING AND ACCOUNTING

? MAY ALLOW OFF-BALANCE SHEET TREATMENT AND TAX ADVANTAGES

? CONVENIENT AND QUICK APPROVAL PROCESS

? FLEXIBLE PAYMENT PROGRAMS TO MATCH YOUR NEEDS

? OFFERS A MANAGEABLE AND ECONOMICAL WAY OF KEEPING UP WITH RAPIDLY CHANGING TECHNOLOGIES

? ACTS AS A HEDGE AGAINST INFLATION - FIXED PAYMENTS FOR THE TERM OF THE LEASE

? PAYS FOR ITSELF OUT OF EARNINGS OR SAVINGS GENERATED BY THE EQUIPMENT LEASED

LEASING ALLOWS YOUR COMPANY TO RETAIN CASH AND MAKE IT AVAILABLE FOR REINVESTMENT, OPERATIONS OR EXPANSION. 


 | po box 23 | Bakers Mills | New York | 12811 | USA

Click Here to Unsubscribe: http://ct.ymdirect1.com/rd/cts?d=10007-16945-13181-7900-294-589169-0-0-0-1-6645-153&list_id=13181&email=mobile@freebsd.org&message_id=16945

Privacy Policy: http://ct.ymdirect1.com/rd/cts?d=10007-16945-13181-7900-294-589170-0-0-0-1-6645-153

Powered by Yesmail Direct.