I just pulled the latest wireless-testing kernel, however, much like
the previous wireless-testing kernel I was working on, when attempting
to ping one node from another on a mesh, using ath5k, the node
attempting to ping completely freezes after about 7 pings are
(succesfully) sent. Anyone have any idea what is going wrong here?
Cheers
Keir
Hi Keir. If the system really crashes, you should have some output.
Can you please set:
echo 8 > /proc/sys/kernel/printk
...and use your serial console and try to reproduce this? Thanks,
-Andrey
On Mon, Jan 26, 2009 at 9:56 AM, Keir <[email protected]> wrote:
> Right, managed to set up a serial terminal, ran cat /proc/kmsg, but
> still no output of interest (just mesh plink stuff leading up to the
> connection being established), what should I do next?
>
> Cheers
>
> Keir
>
> 2009/1/26 Keir <[email protected]>:
>> "sudo cat /proc/kmsg > log" doesnt produce anything of interest.
>>
>> Will look into the serial console thing, never done it before.
>>
>> Keir
>>
>> 2009/1/24 Andrey Yurovsky <[email protected]>:
>>> Can you post logs of the crash (dmesg output)? You may need to
>>> connect a serial console to the PC in question to get them if the
>>> machine is really hard-locking, otherwise see if you can capture the
>>> output of dmesg
>>>
>>> On Sat, Jan 24, 2009 at 8:04 AM, Keir <[email protected]> wrote:
>>>> Tried that commit, still no luck :( It consistently freezes up on
>>>> ping, though sometimes it's the machine doing the pining, and other
>>>> times it's the machine being pinged. Wondering what I can do to help
>>>> debug this?
>>>>
>>>> Keir
>>>>
>>>> 2009/1/23 Andrey Yurovsky <[email protected]>:
>>>>> Hi Keir. Incidentally, we're using ath5k mesh right now at commit
>>>>> 93bd2ac7301b0879821e584991f82de372d62bf6 (that's just after the
>>>>> 2.6.29-rc1 tag but before -rc2) an things work fine. I haven't had a
>>>>> chance to try head of wireless-testing this week.
>>>>>
>>>>> -Andrey
>>>>>
>>>>> On Fri, Jan 23, 2009 at 8:03 AM, Keir <[email protected]> wrote:
>>>>>> I just pulled the latest wireless-testing kernel, however, much like
>>>>>> the previous wireless-testing kernel I was working on, when attempting
>>>>>> to ping one node from another on a mesh, using ath5k, the node
>>>>>> attempting to ping completely freezes after about 7 pings are
>>>>>> (succesfully) sent. Anyone have any idea what is going wrong here?
>>>>>>
>>>>>> Cheers
>>>>>>
>>>>>> Keir
>>>>>> --
>>>>>> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
>>>>>> the body of a message to [email protected]
>>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>>>
>>>>>
>>>>
>>>
>>
>
Hi Keir. Incidentally, we're using ath5k mesh right now at commit
93bd2ac7301b0879821e584991f82de372d62bf6 (that's just after the
2.6.29-rc1 tag but before -rc2) an things work fine. I haven't had a
chance to try head of wireless-testing this week.
-Andrey
On Fri, Jan 23, 2009 at 8:03 AM, Keir <[email protected]> wrote:
> I just pulled the latest wireless-testing kernel, however, much like
> the previous wireless-testing kernel I was working on, when attempting
> to ping one node from another on a mesh, using ath5k, the node
> attempting to ping completely freezes after about 7 pings are
> (succesfully) sent. Anyone have any idea what is going wrong here?
>
> Cheers
>
> Keir
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Can you post logs of the crash (dmesg output)? You may need to
connect a serial console to the PC in question to get them if the
machine is really hard-locking, otherwise see if you can capture the
output of dmesg
On Sat, Jan 24, 2009 at 8:04 AM, Keir <[email protected]> wrote:
> Tried that commit, still no luck :( It consistently freezes up on
> ping, though sometimes it's the machine doing the pining, and other
> times it's the machine being pinged. Wondering what I can do to help
> debug this?
>
> Keir
>
> 2009/1/23 Andrey Yurovsky <[email protected]>:
>> Hi Keir. Incidentally, we're using ath5k mesh right now at commit
>> 93bd2ac7301b0879821e584991f82de372d62bf6 (that's just after the
>> 2.6.29-rc1 tag but before -rc2) an things work fine. I haven't had a
>> chance to try head of wireless-testing this week.
>>
>> -Andrey
>>
>> On Fri, Jan 23, 2009 at 8:03 AM, Keir <[email protected]> wrote:
>>> I just pulled the latest wireless-testing kernel, however, much like
>>> the previous wireless-testing kernel I was working on, when attempting
>>> to ping one node from another on a mesh, using ath5k, the node
>>> attempting to ping completely freezes after about 7 pings are
>>> (succesfully) sent. Anyone have any idea what is going wrong here?
>>>
>>> Cheers
>>>
>>> Keir
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
>>> the body of a message to [email protected]
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>
>>
>
I see the same crash everytime I try to use ath5k. I have this device:
05:00.0 Ethernet controller [0200]: Atheros Communications Inc.
AR5212/AR5213 Multiprotocol MAC/baseband processor [168c:0013] (rev
01)
Subsystem: Device [1948:3a02]
Flags: bus master, medium devsel, latency 64, IRQ 11
Memory at f9df0000 (32-bit, non-prefetchable) [size=64K]
Capabilities: [44] Power Management version 2
Kernel modules: ath5k, ath_pci
I use stock 2.6.28.2
On Fri, Jan 30, 2009 at 6:01 AM, Keir <[email protected]> wrote:
> Could you send me the .config you are using? Just so i can make sure
> my kernel is exactly the same?
>
> Cheers
>
> Keir
>
> 2009/1/30 Keir <[email protected]>:
>> I did the following in my serial console:
>>
>> root@kyp:/home/keir/Desktop/iw-0.9.6# echo 8 > /proc/sys/kernel/printk
>> root@kyp:/home/keir/Desktop/iw-0.9.6# ping -I mesh0 10.0.0.2
>> PING 10.0.0.2 (10.0.0.2) from 10.0.0.3 mesh0: 56(84) bytes of data.
>> 64 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=2.67 ms
>> 64 bytes from 10.0.0.2: icmp_seq=2 ttl=64 time=0.550 ms
>> 64 bytes from 10.0.0.2: icmp_seq=3 ttl=64 time=0.445 ms
>> 64 bytes from 10.0.0.2: icmp_seq=4 ttl=64 time=6.28 ms
>> 64 bytes from 10.0.0.2: icmp_seq=5 ttl=64 time=2.19 ms
>>
>> At which point the console freezes with no further output.
>>
>> Any ideas?
>>
>> Cheers
>>
>> Keir
>>
>> 2009/1/28 Andrey Yurovsky <[email protected]>
>>>
>>> Hi Keir. If the system really crashes, you should have some output.
>>> Can you please set:
>>>
>>> echo 8 > /proc/sys/kernel/printk
>>>
>>> ...and use your serial console and try to reproduce this? Thanks,
>>>
>>> -Andrey
>>>
>>> On Mon, Jan 26, 2009 at 9:56 AM, Keir <[email protected]> wrote:
>>> > Right, managed to set up a serial terminal, ran cat /proc/kmsg, but
>>> > still no output of interest (just mesh plink stuff leading up to the
>>> > connection being established), what should I do next?
>>> >
>>> > Cheers
>>> >
>>> > Keir
>>> >
>>> > 2009/1/26 Keir <[email protected]>:
>>> >> "sudo cat /proc/kmsg > log" doesnt produce anything of interest.
>>> >>
>>> >> Will look into the serial console thing, never done it before.
>>> >>
>>> >> Keir
>>> >>
>>> >> 2009/1/24 Andrey Yurovsky <[email protected]>:
>>> >>> Can you post logs of the crash (dmesg output)? You may need to
>>> >>> connect a serial console to the PC in question to get them if the
>>> >>> machine is really hard-locking, otherwise see if you can capture the
>>> >>> output of dmesg
>>> >>>
>>> >>> On Sat, Jan 24, 2009 at 8:04 AM, Keir <[email protected]> wrote:
>>> >>>> Tried that commit, still no luck :( It consistently freezes up on
>>> >>>> ping, though sometimes it's the machine doing the pining, and other
>>> >>>> times it's the machine being pinged. Wondering what I can do to help
>>> >>>> debug this?
>>> >>>>
>>> >>>> Keir
>>> >>>>
>>> >>>> 2009/1/23 Andrey Yurovsky <[email protected]>:
>>> >>>>> Hi Keir. Incidentally, we're using ath5k mesh right now at commit
>>> >>>>> 93bd2ac7301b0879821e584991f82de372d62bf6 (that's just after the
>>> >>>>> 2.6.29-rc1 tag but before -rc2) an things work fine. I haven't had a
>>> >>>>> chance to try head of wireless-testing this week.
>>> >>>>>
>>> >>>>> -Andrey
>>> >>>>>
>>> >>>>> On Fri, Jan 23, 2009 at 8:03 AM, Keir <[email protected]> wrote:
>>> >>>>>> I just pulled the latest wireless-testing kernel, however, much like
>>> >>>>>> the previous wireless-testing kernel I was working on, when attempting
>>> >>>>>> to ping one node from another on a mesh, using ath5k, the node
>>> >>>>>> attempting to ping completely freezes after about 7 pings are
>>> >>>>>> (succesfully) sent. Anyone have any idea what is going wrong here?
>>> >>>>>>
>>> >>>>>> Cheers
>>> >>>>>>
>>> >>>>>> Keir
>>> >>>>>> --
>>> >>>>>> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
>>> >>>>>> the body of a message to [email protected]
>>> >>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>> >>>>>>
>>> >>>>>
>>> >>>>
>>> >>>
>>> >>
>>> >
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Right, managed to set up a serial terminal, ran cat /proc/kmsg, but
still no output of interest (just mesh plink stuff leading up to the
connection being established), what should I do next?
Cheers
Keir
2009/1/26 Keir <[email protected]>:
> "sudo cat /proc/kmsg > log" doesnt produce anything of interest.
>
> Will look into the serial console thing, never done it before.
>
> Keir
>
> 2009/1/24 Andrey Yurovsky <[email protected]>:
>> Can you post logs of the crash (dmesg output)? You may need to
>> connect a serial console to the PC in question to get them if the
>> machine is really hard-locking, otherwise see if you can capture the
>> output of dmesg
>>
>> On Sat, Jan 24, 2009 at 8:04 AM, Keir <[email protected]> wrote:
>>> Tried that commit, still no luck :( It consistently freezes up on
>>> ping, though sometimes it's the machine doing the pining, and other
>>> times it's the machine being pinged. Wondering what I can do to help
>>> debug this?
>>>
>>> Keir
>>>
>>> 2009/1/23 Andrey Yurovsky <[email protected]>:
>>>> Hi Keir. Incidentally, we're using ath5k mesh right now at commit
>>>> 93bd2ac7301b0879821e584991f82de372d62bf6 (that's just after the
>>>> 2.6.29-rc1 tag but before -rc2) an things work fine. I haven't had a
>>>> chance to try head of wireless-testing this week.
>>>>
>>>> -Andrey
>>>>
>>>> On Fri, Jan 23, 2009 at 8:03 AM, Keir <[email protected]> wrote:
>>>>> I just pulled the latest wireless-testing kernel, however, much like
>>>>> the previous wireless-testing kernel I was working on, when attempting
>>>>> to ping one node from another on a mesh, using ath5k, the node
>>>>> attempting to ping completely freezes after about 7 pings are
>>>>> (succesfully) sent. Anyone have any idea what is going wrong here?
>>>>>
>>>>> Cheers
>>>>>
>>>>> Keir
>>>>> --
>>>>> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
>>>>> the body of a message to [email protected]
>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>>
>>>>
>>>
>>
>
I did the following in my serial console:
root@kyp:/home/keir/Desktop/iw-0.9.6# echo 8 > /proc/sys/kernel/printk
root@kyp:/home/keir/Desktop/iw-0.9.6# ping -I mesh0 10.0.0.2
PING 10.0.0.2 (10.0.0.2) from 10.0.0.3 mesh0: 56(84) bytes of data.
64 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=2.67 ms
64 bytes from 10.0.0.2: icmp_seq=2 ttl=64 time=0.550 ms
64 bytes from 10.0.0.2: icmp_seq=3 ttl=64 time=0.445 ms
64 bytes from 10.0.0.2: icmp_seq=4 ttl=64 time=6.28 ms
64 bytes from 10.0.0.2: icmp_seq=5 ttl=64 time=2.19 ms
At which point the console freezes with no further output.
Any ideas?
Cheers
Keir
2009/1/28 Andrey Yurovsky <[email protected]>
>
> Hi Keir. If the system really crashes, you should have some output.
> Can you please set:
>
> echo 8 > /proc/sys/kernel/printk
>
> ...and use your serial console and try to reproduce this? Thanks,
>
> -Andrey
>
> On Mon, Jan 26, 2009 at 9:56 AM, Keir <[email protected]> wrote:
> > Right, managed to set up a serial terminal, ran cat /proc/kmsg, but
> > still no output of interest (just mesh plink stuff leading up to the
> > connection being established), what should I do next?
> >
> > Cheers
> >
> > Keir
> >
> > 2009/1/26 Keir <[email protected]>:
> >> "sudo cat /proc/kmsg > log" doesnt produce anything of interest.
> >>
> >> Will look into the serial console thing, never done it before.
> >>
> >> Keir
> >>
> >> 2009/1/24 Andrey Yurovsky <[email protected]>:
> >>> Can you post logs of the crash (dmesg output)? You may need to
> >>> connect a serial console to the PC in question to get them if the
> >>> machine is really hard-locking, otherwise see if you can capture the
> >>> output of dmesg
> >>>
> >>> On Sat, Jan 24, 2009 at 8:04 AM, Keir <[email protected]> wrote:
> >>>> Tried that commit, still no luck :( It consistently freezes up on
> >>>> ping, though sometimes it's the machine doing the pining, and other
> >>>> times it's the machine being pinged. Wondering what I can do to help
> >>>> debug this?
> >>>>
> >>>> Keir
> >>>>
> >>>> 2009/1/23 Andrey Yurovsky <[email protected]>:
> >>>>> Hi Keir. Incidentally, we're using ath5k mesh right now at commit
> >>>>> 93bd2ac7301b0879821e584991f82de372d62bf6 (that's just after the
> >>>>> 2.6.29-rc1 tag but before -rc2) an things work fine. I haven't had a
> >>>>> chance to try head of wireless-testing this week.
> >>>>>
> >>>>> -Andrey
> >>>>>
> >>>>> On Fri, Jan 23, 2009 at 8:03 AM, Keir <[email protected]> wrote:
> >>>>>> I just pulled the latest wireless-testing kernel, however, much like
> >>>>>> the previous wireless-testing kernel I was working on, when attempting
> >>>>>> to ping one node from another on a mesh, using ath5k, the node
> >>>>>> attempting to ping completely freezes after about 7 pings are
> >>>>>> (succesfully) sent. Anyone have any idea what is going wrong here?
> >>>>>>
> >>>>>> Cheers
> >>>>>>
> >>>>>> Keir
> >>>>>> --
> >>>>>> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> >>>>>> the body of a message to [email protected]
> >>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> >
"sudo cat /proc/kmsg > log" doesnt produce anything of interest.
Will look into the serial console thing, never done it before.
Keir
2009/1/24 Andrey Yurovsky <[email protected]>:
> Can you post logs of the crash (dmesg output)? You may need to
> connect a serial console to the PC in question to get them if the
> machine is really hard-locking, otherwise see if you can capture the
> output of dmesg
>
> On Sat, Jan 24, 2009 at 8:04 AM, Keir <[email protected]> wrote:
>> Tried that commit, still no luck :( It consistently freezes up on
>> ping, though sometimes it's the machine doing the pining, and other
>> times it's the machine being pinged. Wondering what I can do to help
>> debug this?
>>
>> Keir
>>
>> 2009/1/23 Andrey Yurovsky <[email protected]>:
>>> Hi Keir. Incidentally, we're using ath5k mesh right now at commit
>>> 93bd2ac7301b0879821e584991f82de372d62bf6 (that's just after the
>>> 2.6.29-rc1 tag but before -rc2) an things work fine. I haven't had a
>>> chance to try head of wireless-testing this week.
>>>
>>> -Andrey
>>>
>>> On Fri, Jan 23, 2009 at 8:03 AM, Keir <[email protected]> wrote:
>>>> I just pulled the latest wireless-testing kernel, however, much like
>>>> the previous wireless-testing kernel I was working on, when attempting
>>>> to ping one node from another on a mesh, using ath5k, the node
>>>> attempting to ping completely freezes after about 7 pings are
>>>> (succesfully) sent. Anyone have any idea what is going wrong here?
>>>>
>>>> Cheers
>>>>
>>>> Keir
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
>>>> the body of a message to [email protected]
>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>
>>>
>>
>
Could you send me the .config you are using? Just so i can make sure
my kernel is exactly the same?
Cheers
Keir
2009/1/30 Keir <[email protected]>:
> I did the following in my serial console:
>
> root@kyp:/home/keir/Desktop/iw-0.9.6# echo 8 > /proc/sys/kernel/printk
> root@kyp:/home/keir/Desktop/iw-0.9.6# ping -I mesh0 10.0.0.2
> PING 10.0.0.2 (10.0.0.2) from 10.0.0.3 mesh0: 56(84) bytes of data.
> 64 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=2.67 ms
> 64 bytes from 10.0.0.2: icmp_seq=2 ttl=64 time=0.550 ms
> 64 bytes from 10.0.0.2: icmp_seq=3 ttl=64 time=0.445 ms
> 64 bytes from 10.0.0.2: icmp_seq=4 ttl=64 time=6.28 ms
> 64 bytes from 10.0.0.2: icmp_seq=5 ttl=64 time=2.19 ms
>
> At which point the console freezes with no further output.
>
> Any ideas?
>
> Cheers
>
> Keir
>
> 2009/1/28 Andrey Yurovsky <[email protected]>
>>
>> Hi Keir. If the system really crashes, you should have some output.
>> Can you please set:
>>
>> echo 8 > /proc/sys/kernel/printk
>>
>> ...and use your serial console and try to reproduce this? Thanks,
>>
>> -Andrey
>>
>> On Mon, Jan 26, 2009 at 9:56 AM, Keir <[email protected]> wrote:
>> > Right, managed to set up a serial terminal, ran cat /proc/kmsg, but
>> > still no output of interest (just mesh plink stuff leading up to the
>> > connection being established), what should I do next?
>> >
>> > Cheers
>> >
>> > Keir
>> >
>> > 2009/1/26 Keir <[email protected]>:
>> >> "sudo cat /proc/kmsg > log" doesnt produce anything of interest.
>> >>
>> >> Will look into the serial console thing, never done it before.
>> >>
>> >> Keir
>> >>
>> >> 2009/1/24 Andrey Yurovsky <[email protected]>:
>> >>> Can you post logs of the crash (dmesg output)? You may need to
>> >>> connect a serial console to the PC in question to get them if the
>> >>> machine is really hard-locking, otherwise see if you can capture the
>> >>> output of dmesg
>> >>>
>> >>> On Sat, Jan 24, 2009 at 8:04 AM, Keir <[email protected]> wrote:
>> >>>> Tried that commit, still no luck :( It consistently freezes up on
>> >>>> ping, though sometimes it's the machine doing the pining, and other
>> >>>> times it's the machine being pinged. Wondering what I can do to help
>> >>>> debug this?
>> >>>>
>> >>>> Keir
>> >>>>
>> >>>> 2009/1/23 Andrey Yurovsky <[email protected]>:
>> >>>>> Hi Keir. Incidentally, we're using ath5k mesh right now at commit
>> >>>>> 93bd2ac7301b0879821e584991f82de372d62bf6 (that's just after the
>> >>>>> 2.6.29-rc1 tag but before -rc2) an things work fine. I haven't had a
>> >>>>> chance to try head of wireless-testing this week.
>> >>>>>
>> >>>>> -Andrey
>> >>>>>
>> >>>>> On Fri, Jan 23, 2009 at 8:03 AM, Keir <[email protected]> wrote:
>> >>>>>> I just pulled the latest wireless-testing kernel, however, much like
>> >>>>>> the previous wireless-testing kernel I was working on, when attempting
>> >>>>>> to ping one node from another on a mesh, using ath5k, the node
>> >>>>>> attempting to ping completely freezes after about 7 pings are
>> >>>>>> (succesfully) sent. Anyone have any idea what is going wrong here?
>> >>>>>>
>> >>>>>> Cheers
>> >>>>>>
>> >>>>>> Keir
>> >>>>>> --
>> >>>>>> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
>> >>>>>> the body of a message to [email protected]
>> >>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> >>>>>>
>> >>>>>
>> >>>>
>> >>>
>> >>
>> >
>
Tried that commit, still no luck :( It consistently freezes up on
ping, though sometimes it's the machine doing the pining, and other
times it's the machine being pinged. Wondering what I can do to help
debug this?
Keir
2009/1/23 Andrey Yurovsky <[email protected]>:
> Hi Keir. Incidentally, we're using ath5k mesh right now at commit
> 93bd2ac7301b0879821e584991f82de372d62bf6 (that's just after the
> 2.6.29-rc1 tag but before -rc2) an things work fine. I haven't had a
> chance to try head of wireless-testing this week.
>
> -Andrey
>
> On Fri, Jan 23, 2009 at 8:03 AM, Keir <[email protected]> wrote:
>> I just pulled the latest wireless-testing kernel, however, much like
>> the previous wireless-testing kernel I was working on, when attempting
>> to ping one node from another on a mesh, using ath5k, the node
>> attempting to ping completely freezes after about 7 pings are
>> (succesfully) sent. Anyone have any idea what is going wrong here?
>>
>> Cheers
>>
>> Keir
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
>> the body of a message to [email protected]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
No I don't have stack trace. The system completely freezes, to a point
where even the magic sysreq key doesn't respond. I can try this patch.
what does it fix, exactly?
On Mon, Feb 2, 2009 at 1:33 PM, Bob Copeland <[email protected]> wrote:
> On Mon, Feb 2, 2009 at 3:55 PM, Mike Cui <[email protected]> wrote:
>> No. crash happens when I use it in regular access point mode.
>>
>
> Do you have a stack trace? And does this patch help?
>
> http://bugzilla.kernel.org/attachment.cgi?id=19985
> --
> Bob Copeland %% http://www.bobcopeland.com
>
On Mon, Feb 2, 2009 at 3:55 PM, Mike Cui <[email protected]> wrote:
> No. crash happens when I use it in regular access point mode.
>
Do you have a stack trace? And does this patch help?
http://bugzilla.kernel.org/attachment.cgi?id=19985
--
Bob Copeland %% http://www.bobcopeland.com
On Mon, 2009-02-02 at 15:13 -0800, Mike Cui wrote:
> No I don't have stack trace. The system completely freezes, to a point
> where even the magic sysreq key doesn't respond.
Just switch to a vt _before_ making it crash.
johannes
Cards I am using are all:
02:07.0 Ethernet controller: Atheros Communications Inc. AR5212/AR5213
Multiprotocol MAC/baseband processor [168c:0013] (rev 01)
Subsystem: Netgear Unknown device [1385:5a00]
Flags: bus master, medium devsel, latency 168, IRQ 16
Memory at ff6f0000 (32-bit, non-prefetchable) [size=64K]
Capabilities: [44] Power Management version 2
Did you mean specifically with the mesh stack Mike?
Cheers
Keir
2009/1/30 Mike Cui <[email protected]>:
> I see the same crash everytime I try to use ath5k. I have this device:
>
> 05:00.0 Ethernet controller [0200]: Atheros Communications Inc.
> AR5212/AR5213 Multiprotocol MAC/baseband processor [168c:0013] (rev
> 01)
> Subsystem: Device [1948:3a02]
> Flags: bus master, medium devsel, latency 64, IRQ 11
> Memory at f9df0000 (32-bit, non-prefetchable) [size=64K]
> Capabilities: [44] Power Management version 2
> Kernel modules: ath5k, ath_pci
>
> I use stock 2.6.28.2
>
> On Fri, Jan 30, 2009 at 6:01 AM, Keir <[email protected]> wrote:
>> Could you send me the .config you are using? Just so i can make sure
>> my kernel is exactly the same?
>>
>> Cheers
>>
>> Keir
>>
>> 2009/1/30 Keir <[email protected]>:
>>> I did the following in my serial console:
>>>
>>> root@kyp:/home/keir/Desktop/iw-0.9.6# echo 8 > /proc/sys/kernel/printk
>>> root@kyp:/home/keir/Desktop/iw-0.9.6# ping -I mesh0 10.0.0.2
>>> PING 10.0.0.2 (10.0.0.2) from 10.0.0.3 mesh0: 56(84) bytes of data.
>>> 64 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=2.67 ms
>>> 64 bytes from 10.0.0.2: icmp_seq=2 ttl=64 time=0.550 ms
>>> 64 bytes from 10.0.0.2: icmp_seq=3 ttl=64 time=0.445 ms
>>> 64 bytes from 10.0.0.2: icmp_seq=4 ttl=64 time=6.28 ms
>>> 64 bytes from 10.0.0.2: icmp_seq=5 ttl=64 time=2.19 ms
>>>
>>> At which point the console freezes with no further output.
>>>
>>> Any ideas?
>>>
>>> Cheers
>>>
>>> Keir
>>>
>>> 2009/1/28 Andrey Yurovsky <[email protected]>
>>>>
>>>> Hi Keir. If the system really crashes, you should have some output.
>>>> Can you please set:
>>>>
>>>> echo 8 > /proc/sys/kernel/printk
>>>>
>>>> ...and use your serial console and try to reproduce this? Thanks,
>>>>
>>>> -Andrey
>>>>
>>>> On Mon, Jan 26, 2009 at 9:56 AM, Keir <[email protected]> wrote:
>>>> > Right, managed to set up a serial terminal, ran cat /proc/kmsg, but
>>>> > still no output of interest (just mesh plink stuff leading up to the
>>>> > connection being established), what should I do next?
>>>> >
>>>> > Cheers
>>>> >
>>>> > Keir
>>>> >
>>>> > 2009/1/26 Keir <[email protected]>:
>>>> >> "sudo cat /proc/kmsg > log" doesnt produce anything of interest.
>>>> >>
>>>> >> Will look into the serial console thing, never done it before.
>>>> >>
>>>> >> Keir
>>>> >>
>>>> >> 2009/1/24 Andrey Yurovsky <[email protected]>:
>>>> >>> Can you post logs of the crash (dmesg output)? You may need to
>>>> >>> connect a serial console to the PC in question to get them if the
>>>> >>> machine is really hard-locking, otherwise see if you can capture the
>>>> >>> output of dmesg
>>>> >>>
>>>> >>> On Sat, Jan 24, 2009 at 8:04 AM, Keir <[email protected]> wrote:
>>>> >>>> Tried that commit, still no luck :( It consistently freezes up on
>>>> >>>> ping, though sometimes it's the machine doing the pining, and other
>>>> >>>> times it's the machine being pinged. Wondering what I can do to help
>>>> >>>> debug this?
>>>> >>>>
>>>> >>>> Keir
>>>> >>>>
>>>> >>>> 2009/1/23 Andrey Yurovsky <[email protected]>:
>>>> >>>>> Hi Keir. Incidentally, we're using ath5k mesh right now at commit
>>>> >>>>> 93bd2ac7301b0879821e584991f82de372d62bf6 (that's just after the
>>>> >>>>> 2.6.29-rc1 tag but before -rc2) an things work fine. I haven't had a
>>>> >>>>> chance to try head of wireless-testing this week.
>>>> >>>>>
>>>> >>>>> -Andrey
>>>> >>>>>
>>>> >>>>> On Fri, Jan 23, 2009 at 8:03 AM, Keir <[email protected]> wrote:
>>>> >>>>>> I just pulled the latest wireless-testing kernel, however, much like
>>>> >>>>>> the previous wireless-testing kernel I was working on, when attempting
>>>> >>>>>> to ping one node from another on a mesh, using ath5k, the node
>>>> >>>>>> attempting to ping completely freezes after about 7 pings are
>>>> >>>>>> (succesfully) sent. Anyone have any idea what is going wrong here?
>>>> >>>>>>
>>>> >>>>>> Cheers
>>>> >>>>>>
>>>> >>>>>> Keir
>>>> >>>>>> --
>>>> >>>>>> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
>>>> >>>>>> the body of a message to [email protected]
>>>> >>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>> >>>>>>
>>>> >>>>>
>>>> >>>>
>>>> >>>
>>>> >>
>>>> >
>>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
>> the body of a message to [email protected]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
No. crash happens when I use it in regular access point mode.
On Mon, Feb 2, 2009 at 10:13 AM, Keir <[email protected]> wrote:
> Cards I am using are all:
>
> 02:07.0 Ethernet controller: Atheros Communications Inc. AR5212/AR5213
> Multiprotocol MAC/baseband processor [168c:0013] (rev 01)
> Subsystem: Netgear Unknown device [1385:5a00]
> Flags: bus master, medium devsel, latency 168, IRQ 16
> Memory at ff6f0000 (32-bit, non-prefetchable) [size=64K]
> Capabilities: [44] Power Management version 2
>
> Did you mean specifically with the mesh stack Mike?
>
> Cheers
>
> Keir
>
> 2009/1/30 Mike Cui <[email protected]>:
>> I see the same crash everytime I try to use ath5k. I have this device:
>>
>> 05:00.0 Ethernet controller [0200]: Atheros Communications Inc.
>> AR5212/AR5213 Multiprotocol MAC/baseband processor [168c:0013] (rev
>> 01)
>> Subsystem: Device [1948:3a02]
>> Flags: bus master, medium devsel, latency 64, IRQ 11
>> Memory at f9df0000 (32-bit, non-prefetchable) [size=64K]
>> Capabilities: [44] Power Management version 2
>> Kernel modules: ath5k, ath_pci
>>
>> I use stock 2.6.28.2
>>
>> On Fri, Jan 30, 2009 at 6:01 AM, Keir <[email protected]> wrote:
>>> Could you send me the .config you are using? Just so i can make sure
>>> my kernel is exactly the same?
>>>
>>> Cheers
>>>
>>> Keir
>>>
>>> 2009/1/30 Keir <[email protected]>:
>>>> I did the following in my serial console:
>>>>
>>>> root@kyp:/home/keir/Desktop/iw-0.9.6# echo 8 > /proc/sys/kernel/printk
>>>> root@kyp:/home/keir/Desktop/iw-0.9.6# ping -I mesh0 10.0.0.2
>>>> PING 10.0.0.2 (10.0.0.2) from 10.0.0.3 mesh0: 56(84) bytes of data.
>>>> 64 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=2.67 ms
>>>> 64 bytes from 10.0.0.2: icmp_seq=2 ttl=64 time=0.550 ms
>>>> 64 bytes from 10.0.0.2: icmp_seq=3 ttl=64 time=0.445 ms
>>>> 64 bytes from 10.0.0.2: icmp_seq=4 ttl=64 time=6.28 ms
>>>> 64 bytes from 10.0.0.2: icmp_seq=5 ttl=64 time=2.19 ms
>>>>
>>>> At which point the console freezes with no further output.
>>>>
>>>> Any ideas?
>>>>
>>>> Cheers
>>>>
>>>> Keir
>>>>
>>>> 2009/1/28 Andrey Yurovsky <[email protected]>
>>>>>
>>>>> Hi Keir. If the system really crashes, you should have some output.
>>>>> Can you please set:
>>>>>
>>>>> echo 8 > /proc/sys/kernel/printk
>>>>>
>>>>> ...and use your serial console and try to reproduce this? Thanks,
>>>>>
>>>>> -Andrey
>>>>>
>>>>> On Mon, Jan 26, 2009 at 9:56 AM, Keir <[email protected]> wrote:
>>>>> > Right, managed to set up a serial terminal, ran cat /proc/kmsg, but
>>>>> > still no output of interest (just mesh plink stuff leading up to the
>>>>> > connection being established), what should I do next?
>>>>> >
>>>>> > Cheers
>>>>> >
>>>>> > Keir
>>>>> >
>>>>> > 2009/1/26 Keir <[email protected]>:
>>>>> >> "sudo cat /proc/kmsg > log" doesnt produce anything of interest.
>>>>> >>
>>>>> >> Will look into the serial console thing, never done it before.
>>>>> >>
>>>>> >> Keir
>>>>> >>
>>>>> >> 2009/1/24 Andrey Yurovsky <[email protected]>:
>>>>> >>> Can you post logs of the crash (dmesg output)? You may need to
>>>>> >>> connect a serial console to the PC in question to get them if the
>>>>> >>> machine is really hard-locking, otherwise see if you can capture the
>>>>> >>> output of dmesg
>>>>> >>>
>>>>> >>> On Sat, Jan 24, 2009 at 8:04 AM, Keir <[email protected]> wrote:
>>>>> >>>> Tried that commit, still no luck :( It consistently freezes up on
>>>>> >>>> ping, though sometimes it's the machine doing the pining, and other
>>>>> >>>> times it's the machine being pinged. Wondering what I can do to help
>>>>> >>>> debug this?
>>>>> >>>>
>>>>> >>>> Keir
>>>>> >>>>
>>>>> >>>> 2009/1/23 Andrey Yurovsky <[email protected]>:
>>>>> >>>>> Hi Keir. Incidentally, we're using ath5k mesh right now at commit
>>>>> >>>>> 93bd2ac7301b0879821e584991f82de372d62bf6 (that's just after the
>>>>> >>>>> 2.6.29-rc1 tag but before -rc2) an things work fine. I haven't had a
>>>>> >>>>> chance to try head of wireless-testing this week.
>>>>> >>>>>
>>>>> >>>>> -Andrey
>>>>> >>>>>
>>>>> >>>>> On Fri, Jan 23, 2009 at 8:03 AM, Keir <[email protected]> wrote:
>>>>> >>>>>> I just pulled the latest wireless-testing kernel, however, much like
>>>>> >>>>>> the previous wireless-testing kernel I was working on, when attempting
>>>>> >>>>>> to ping one node from another on a mesh, using ath5k, the node
>>>>> >>>>>> attempting to ping completely freezes after about 7 pings are
>>>>> >>>>>> (succesfully) sent. Anyone have any idea what is going wrong here?
>>>>> >>>>>>
>>>>> >>>>>> Cheers
>>>>> >>>>>>
>>>>> >>>>>> Keir
>>>>> >>>>>> --
>>>>> >>>>>> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
>>>>> >>>>>> the body of a message to [email protected]
>>>>> >>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>> >>>>>>
>>>>> >>>>>
>>>>> >>>>
>>>>> >>>
>>>>> >>
>>>>> >
>>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
>>> the body of a message to [email protected]
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>
>>
>
On Mon, Feb 2, 2009 at 6:13 PM, Mike Cui <[email protected]> wrote:
> No I don't have stack trace. The system completely freezes, to a point
> where even the magic sysreq key doesn't respond. I can try this patch.
> what does it fix, exactly?
The patch is by Christian Lamparter. It seems we currently accept STAs
that don't advertise any rates we can use, which will cause the rate
controller to eventually select a null rate. This can happen in AP mode
but I don't know if it has anything to do with the mesh problem.
--
Bob Copeland %% http://www.bobcopeland.com