Re: ath0: unable to attach hardware
_var.h:157: warning: its scope is only this >definition >>>>>or declaration, which is probably not what you want >>>>>> @/net/if_var.h:167: warning: 'struct sockaddr' declared >inside >>>>>parameter list >>>>>> @/net/if_var.h:187: error: 'AF_MAX' undeclared here (not in a >>>>>function) >>>>>> @/net/if_var.h:718: error: field 'if_data' has incomplete >type >>>>>> /usr/src/sys/modules/ath/../../dev/ath/ath_hal/ah.c: In >>>function >>>>>'ath_hal_attach': >>>>>> /usr/src/sys/modules/ath/../../dev/ath/ath_hal/ah.c:65: >>>warning: >>>>>dereferencing 'void *' pointer >>>>>> /usr/src/sys/modules/ath/../../dev/ath/ath_hal/ah.c:65: >error: >>>>>request for member 'sc_ifp' in something not a structure or >union >>>>>> /usr/src/sys/modules/ath/../../dev/ath/ath_hal/ah.c:70: >>>warning: >>>>>dereferencing 'void *' pointer >>>>>> /usr/src/sys/modules/ath/../../dev/ath/ath_hal/ah.c:70: >error: >>>>>request for member 'sc_ifp' in something not a structure or >union >>>>>> *** Error code 1 >>>>>> >>>>>> The full output has been posted to >>>>>http://nopaste.info/408e62ac0f.html >>>>>> >>>>>> I'm willing and hoping to help troubleshoot this issue, but >>>>>please keep in mind that I'm new to FreeBSD, so please give >>>>>detailed instructions whenever you can. >>>>>> >>>>>> Thank you very much! >>>>>> >>>>>>> >>>>>>>Hi, >>>>>>> >>>>>>>Ok. I'm travelling for a little bit; if I don't reply in a >few >>>>>>>days, >>>>>>>please poke me again. >>>>>>> >>>>>>>It may be that the device is asleep for a bit longer (failing >>>>>this >>>>>>>test) and has completed resetting at this point. >>>>>>> >>>>>>>It may be that the power on sequence is not quite right for >>>some >>>>>>>reason. >>>>>>> >>>>>>>Would you mind recompiling your kernel and making if_ath a >kld, >>>>>>>rather >>>>>>>than statically in the kernel? >>>>>>> >>>>>>>Thanks, >>>>>>> >>>>>>> >>>>>>>Adrian >>>>>>> >>>>>>>> >>>>>>>> attached to this e-mail you find the output of dmesg. What >I >>>>>>>guess the most relevant lines could be is: >>>>>>>> >>>>>>>> ath0: mem 0xfdee-0xfdee irq 16 at >>>device >>>>>>>4.0 on pci2 >>>>>>>> ar5212ChipTest: address test failed addr: 0x8000 - >>>>>>>wr:0x != rd:0x >>>>>>>> ar5212Attach: hardware self-test failed >>>>>>>> ath0: unable to attach hardware; HAL status 14 >>>>>>>> device_attach: ath0 attach returned 6 >>>>>>>> >>>>>>>> I read the registers 4004 and 4010 again to make sure the >>>>>values >>>>>>>still are the same, which indeed they are. >>>>>>>> >>>>>>>> I hope this helps. >>>>>>>> >>>>>>>> Thanks! >>>>>>>> >>>>>>>> On Donnerstag, 13. Dezember 2012 at 10:18 PM, "Adrian >Chadd" >>>>>>> wrote: >>>>>>>>> >>>>>>>>>On 13 December 2012 13:11, wrote: >>>>>>>>>> Hello everyone, >>>>>>>>>> >>>>>>>>>> I'm afraid I still don't know what exactly BAR is, or >how I >>>>>get >>>>>>>>>its value that I'm supposed to plug into the line John >>>>>provided: >>>>>>>>>> dd if=/dev/mem bs=4 iseek=((start of bar + reg offset)/4) >>>>>>>>>count=1 | hd >>>>>>>>>> >>>>>>>>>> I assumed that "start of bar" is 0xfdee in my case, >>>since >>>>>>>>>dmesg reports >>>>>>>>>> ath0: mem 0xfdee-0xfdee irq 16 at >>>>>device >>>>>>>>>4.0 on pci2 >>>>>>>>> >>>>>>>>>Yup. >>>>>>>>> >>>>>>>>>> This is what I get: >>>>>>>>>> # dd if=/dev/mem bs=4 iseek=`echo "ibase=16; >>>>>(FDEE+4004)/4" >>>>>>>>>| bc` count=1 | hd >>>>>>>>>> 00 00 01 00 >>>>>>>>>> # dd if=/dev/mem bs=4 iseek=`echo "ibase=16; >>>>>(FDEE+4010)/4" >>>>>>>>>| bc` count=1 | hd >>>>>>>>>> 14 00 01 00 >>>>>>>>>> >>>>>>>>>> Please correct me if my assumption about "start of bar" >was >>>>>>>>>wrong and/or I made some other mistake. >>>>>>>>>> Also, please don't hesitate to ask me to do anything else >>>>>that >>>>>>>>>might help you during debugging. >>>>>>>>>> >>>>>>>>>> Thank you very much for the effort. >>>>>>>>> >>>>>>>>>Hm. Wait, what's the rest of the ath0: output? >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>Adrian >>>>>> >>>> >> ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ath0: unable to attach hardware
i.c:168: undefined reference to >>`ath_attach' >>> if_ath_pci.o: In function `ath_pci_probe': >>> /usr/src/sys/dev/ath/if_ath_pci.c:82: undefined reference to >>`ath_hal_probe' >>> *** Error code 1 >>> >>> I'm sorry for being so unexperienced. What am I doing wrong? >>> >>>> >>>>Hi, >>>> >>>>Just leave all of the ath/ah options in the kernel. >>>> >>>>Then comment out >>>> >>>>device ath >>>>device ath_hal >>>>device ath_rate_sample >>>> >>>>.. but yes, leave all the options in there. >>>> >>>> >>>> >>>>Adrian >>>> >>>> >>>>On 27 December 2012 12:06, wrote: >>>>> Hello, >>>>> >>>>> I hope you had a pleasant trip. Sorry for not replying for a >>>>while. >>>>> >>>>> Anyway, I tried to do what you asked me to. However, it seems >>>>like I misunderstood the handbook and/or your request, as I >>failed >>>>to compile the kernel. >>>>> >>>>> I copied my previous, working kernel config to a new file, and >>>>commented the devices ath, ath_pci, ath_hal and ath_rate_sample, >>>>as well as the options AH_SUPPORT_AR5416, AH_DEBUG and ATH_DEBUG. >>>>I did this because I could not find instructions in the handbook >>>>that explained how to build a module as a kld, and commenting the >>>>modules out was my best guess. Please point me to the relevant >>>>section in the handbook in the case that the information was >>>>actually there and I just was unable to find it. >>>>> The full kernel config can be seen here: >>>>http://nopaste.info/d7475552bd.html >>>>> Finally, I went to /usr/src and entered >>>>> make buildkernel KERNCONF=PAVILIONNOATH >>>>> >>>>> This is what I suspect is the relevant output: >>>>> >>>>> cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL - >>DKLD_MODULE >>>>-nostdinc -I. -I/usr/src/sys/modules/ath/../../dev/ath - >>>>I/usr/src/sys/modules/ath/../../dev/ath/ath_hal - >>>>DHAVE_KERNEL_OPTION_HEADERS -include >>>>/usr/obj/usr/src/sys/PAVILIONNOATH/opt_global.h -I. -I@ - >>>>I@/contrib/altq -finline-limit=8000 --param inline-unit- >>growth=100 >>>>--param large-function-growth=1000 -fno-common -g -fno-omit- >>frame- >>>>pointer -I/usr/obj/usr/src/sys/PAVILIONNOATH -mno-sse - >>>>mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float -fno- >>>>asynchronous-unwind-tables -ffreestanding -fstack-protector - >>>>std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls - >>>>Wnested-externs -Wstrict-prototypes -Wmissing-prototypes - >>>>Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign - >>>>fformat-extensions -Wmissing-include-dirs -fdiagnostics-show- >>>>option -c /usr/src/sys/modules/ath/../../dev/ath/ath_hal/ah.c >>>>> In file included from >>>>/usr/src/sys/modules/ath/../../dev/ath/ath_hal/ah.c:55: >>>>> @/net/if_var.h:125: error: 'IFNAMSIZ' undeclared here (not in a >>>>function) >>>>> @/net/if_var.h:151: error: field 'if_data' has incomplete type >>>>> cc1: warnings being treated as errors >>>>> @/net/if_var.h:157: warning: 'struct sockaddr' declared inside >>>>parameter list >>>>> @/net/if_var.h:157: warning: its scope is only this definition >>>>or declaration, which is probably not what you want >>>>> @/net/if_var.h:167: warning: 'struct sockaddr' declared inside >>>>parameter list >>>>> @/net/if_var.h:187: error: 'AF_MAX' undeclared here (not in a >>>>function) >>>>> @/net/if_var.h:718: error: field 'if_data' has incomplete type >>>>> /usr/src/sys/modules/ath/../../dev/ath/ath_hal/ah.c: In >>function >>>>'ath_hal_attach': >>>>> /usr/src/sys/modules/ath/../../dev/ath/ath_hal/ah.c:65: >>warning: >>>>dereferencing 'void *' pointer >>>>> /usr/src/sys/modules/ath/../../dev/ath/ath_hal/ah.c:65: error: >>>>request for member 'sc_ifp' in something not a structure or union >>>>> /usr/src/sys/modules/ath/../../dev/ath/ath_hal/ah.c:70: >>warning: >>>>d
Re: ath0: unable to attach hardware
vice ath_rate_sample >>> >>>.. but yes, leave all the options in there. >>> >>> >>> >>>Adrian >>> >>> >>>On 27 December 2012 12:06, wrote: >>>> Hello, >>>> >>>> I hope you had a pleasant trip. Sorry for not replying for a >>>while. >>>> >>>> Anyway, I tried to do what you asked me to. However, it seems >>>like I misunderstood the handbook and/or your request, as I >failed >>>to compile the kernel. >>>> >>>> I copied my previous, working kernel config to a new file, and >>>commented the devices ath, ath_pci, ath_hal and ath_rate_sample, >>>as well as the options AH_SUPPORT_AR5416, AH_DEBUG and ATH_DEBUG. >>>I did this because I could not find instructions in the handbook >>>that explained how to build a module as a kld, and commenting the >>>modules out was my best guess. Please point me to the relevant >>>section in the handbook in the case that the information was >>>actually there and I just was unable to find it. >>>> The full kernel config can be seen here: >>>http://nopaste.info/d7475552bd.html >>>> Finally, I went to /usr/src and entered >>>> make buildkernel KERNCONF=PAVILIONNOATH >>>> >>>> This is what I suspect is the relevant output: >>>> >>>> cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL - >DKLD_MODULE >>>-nostdinc -I. -I/usr/src/sys/modules/ath/../../dev/ath - >>>I/usr/src/sys/modules/ath/../../dev/ath/ath_hal - >>>DHAVE_KERNEL_OPTION_HEADERS -include >>>/usr/obj/usr/src/sys/PAVILIONNOATH/opt_global.h -I. -I@ - >>>I@/contrib/altq -finline-limit=8000 --param inline-unit- >growth=100 >>>--param large-function-growth=1000 -fno-common -g -fno-omit- >frame- >>>pointer -I/usr/obj/usr/src/sys/PAVILIONNOATH -mno-sse - >>>mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float -fno- >>>asynchronous-unwind-tables -ffreestanding -fstack-protector - >>>std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls - >>>Wnested-externs -Wstrict-prototypes -Wmissing-prototypes - >>>Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign - >>>fformat-extensions -Wmissing-include-dirs -fdiagnostics-show- >>>option -c /usr/src/sys/modules/ath/../../dev/ath/ath_hal/ah.c >>>> In file included from >>>/usr/src/sys/modules/ath/../../dev/ath/ath_hal/ah.c:55: >>>> @/net/if_var.h:125: error: 'IFNAMSIZ' undeclared here (not in a >>>function) >>>> @/net/if_var.h:151: error: field 'if_data' has incomplete type >>>> cc1: warnings being treated as errors >>>> @/net/if_var.h:157: warning: 'struct sockaddr' declared inside >>>parameter list >>>> @/net/if_var.h:157: warning: its scope is only this definition >>>or declaration, which is probably not what you want >>>> @/net/if_var.h:167: warning: 'struct sockaddr' declared inside >>>parameter list >>>> @/net/if_var.h:187: error: 'AF_MAX' undeclared here (not in a >>>function) >>>> @/net/if_var.h:718: error: field 'if_data' has incomplete type >>>> /usr/src/sys/modules/ath/../../dev/ath/ath_hal/ah.c: In >function >>>'ath_hal_attach': >>>> /usr/src/sys/modules/ath/../../dev/ath/ath_hal/ah.c:65: >warning: >>>dereferencing 'void *' pointer >>>> /usr/src/sys/modules/ath/../../dev/ath/ath_hal/ah.c:65: error: >>>request for member 'sc_ifp' in something not a structure or union >>>> /usr/src/sys/modules/ath/../../dev/ath/ath_hal/ah.c:70: >warning: >>>dereferencing 'void *' pointer >>>> /usr/src/sys/modules/ath/../../dev/ath/ath_hal/ah.c:70: error: >>>request for member 'sc_ifp' in something not a structure or union >>>> *** Error code 1 >>>> >>>> The full output has been posted to >>>http://nopaste.info/408e62ac0f.html >>>> >>>> I'm willing and hoping to help troubleshoot this issue, but >>>please keep in mind that I'm new to FreeBSD, so please give >>>detailed instructions whenever you can. >>>> >>>> Thank you very much! >>>> >>>>> >>>>>Hi, >>>>> >>>>>Ok. I'm travelling for a little bit; if I don't reply in a few >>>>>days, >>>>>please poke me again. >>>>> >>>>>
Re: ath0: unable to attach hardware
gt;>> cc1: warnings being treated as errors >>> @/net/if_var.h:157: warning: 'struct sockaddr' declared inside >>parameter list >>> @/net/if_var.h:157: warning: its scope is only this definition >>or declaration, which is probably not what you want >>> @/net/if_var.h:167: warning: 'struct sockaddr' declared inside >>parameter list >>> @/net/if_var.h:187: error: 'AF_MAX' undeclared here (not in a >>function) >>> @/net/if_var.h:718: error: field 'if_data' has incomplete type >>> /usr/src/sys/modules/ath/../../dev/ath/ath_hal/ah.c: In function >>'ath_hal_attach': >>> /usr/src/sys/modules/ath/../../dev/ath/ath_hal/ah.c:65: warning: >>dereferencing 'void *' pointer >>> /usr/src/sys/modules/ath/../../dev/ath/ath_hal/ah.c:65: error: >>request for member 'sc_ifp' in something not a structure or union >>> /usr/src/sys/modules/ath/../../dev/ath/ath_hal/ah.c:70: warning: >>dereferencing 'void *' pointer >>> /usr/src/sys/modules/ath/../../dev/ath/ath_hal/ah.c:70: error: >>request for member 'sc_ifp' in something not a structure or union >>> *** Error code 1 >>> >>> The full output has been posted to >>http://nopaste.info/408e62ac0f.html >>> >>> I'm willing and hoping to help troubleshoot this issue, but >>please keep in mind that I'm new to FreeBSD, so please give >>detailed instructions whenever you can. >>> >>> Thank you very much! >>> >>>> >>>>Hi, >>>> >>>>Ok. I'm travelling for a little bit; if I don't reply in a few >>>>days, >>>>please poke me again. >>>> >>>>It may be that the device is asleep for a bit longer (failing >>this >>>>test) and has completed resetting at this point. >>>> >>>>It may be that the power on sequence is not quite right for some >>>>reason. >>>> >>>>Would you mind recompiling your kernel and making if_ath a kld, >>>>rather >>>>than statically in the kernel? >>>> >>>>Thanks, >>>> >>>> >>>>Adrian >>>> >>>>> >>>>> attached to this e-mail you find the output of dmesg. What I >>>>guess the most relevant lines could be is: >>>>> >>>>> ath0: mem 0xfdee-0xfdee irq 16 at device >>>>4.0 on pci2 >>>>> ar5212ChipTest: address test failed addr: 0x8000 - >>>>wr:0x != rd:0x >>>>> ar5212Attach: hardware self-test failed >>>>> ath0: unable to attach hardware; HAL status 14 >>>>> device_attach: ath0 attach returned 6 >>>>> >>>>> I read the registers 4004 and 4010 again to make sure the >>values >>>>still are the same, which indeed they are. >>>>> >>>>> I hope this helps. >>>>> >>>>> Thanks! >>>>> >>>>> On Donnerstag, 13. Dezember 2012 at 10:18 PM, "Adrian Chadd" >>>> wrote: >>>>>> >>>>>>On 13 December 2012 13:11, wrote: >>>>>>> Hello everyone, >>>>>>> >>>>>>> I'm afraid I still don't know what exactly BAR is, or how I >>get >>>>>>its value that I'm supposed to plug into the line John >>provided: >>>>>>> dd if=/dev/mem bs=4 iseek=((start of bar + reg offset)/4) >>>>>>count=1 | hd >>>>>>> >>>>>>> I assumed that "start of bar" is 0xfdee in my case, since >>>>>>dmesg reports >>>>>>> ath0: mem 0xfdee-0xfdee irq 16 at >>device >>>>>>4.0 on pci2 >>>>>> >>>>>>Yup. >>>>>> >>>>>>> This is what I get: >>>>>>> # dd if=/dev/mem bs=4 iseek=`echo "ibase=16; >>(FDEE+4004)/4" >>>>>>| bc` count=1 | hd >>>>>>> 00 00 01 00 >>>>>>> # dd if=/dev/mem bs=4 iseek=`echo "ibase=16; >>(FDEE+4010)/4" >>>>>>| bc` count=1 | hd >>>>>>> 14 00 01 00 >>>>>>> >>>>>>> Please correct me if my assumption about "start of bar" was >>>>>>wrong and/or I made some other mistake. >>>>>>> Also, please don't hesitate to ask me to do anything else >>that >>>>>>might help you during debugging. >>>>>>> >>>>>>> Thank you very much for the effort. >>>>>> >>>>>>Hm. Wait, what's the rest of the ath0: output? >>>>>> >>>>>> >>>>>> >>>>>>Adrian >>> > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ath0: unable to attach hardware
#x27;if_data' has incomplete type >> /usr/src/sys/modules/ath/../../dev/ath/ath_hal/ah.c: In function >'ath_hal_attach': >> /usr/src/sys/modules/ath/../../dev/ath/ath_hal/ah.c:65: warning: >dereferencing 'void *' pointer >> /usr/src/sys/modules/ath/../../dev/ath/ath_hal/ah.c:65: error: >request for member 'sc_ifp' in something not a structure or union >> /usr/src/sys/modules/ath/../../dev/ath/ath_hal/ah.c:70: warning: >dereferencing 'void *' pointer >> /usr/src/sys/modules/ath/../../dev/ath/ath_hal/ah.c:70: error: >request for member 'sc_ifp' in something not a structure or union >> *** Error code 1 >> >> The full output has been posted to >http://nopaste.info/408e62ac0f.html >> >> I'm willing and hoping to help troubleshoot this issue, but >please keep in mind that I'm new to FreeBSD, so please give >detailed instructions whenever you can. >> >> Thank you very much! >> >>> >>>Hi, >>> >>>Ok. I'm travelling for a little bit; if I don't reply in a few >>>days, >>>please poke me again. >>> >>>It may be that the device is asleep for a bit longer (failing >this >>>test) and has completed resetting at this point. >>> >>>It may be that the power on sequence is not quite right for some >>>reason. >>> >>>Would you mind recompiling your kernel and making if_ath a kld, >>>rather >>>than statically in the kernel? >>> >>>Thanks, >>> >>> >>>Adrian >>> >>>> >>>> attached to this e-mail you find the output of dmesg. What I >>>guess the most relevant lines could be is: >>>> >>>> ath0: mem 0xfdee-0xfdee irq 16 at device >>>4.0 on pci2 >>>> ar5212ChipTest: address test failed addr: 0x8000 - >>>wr:0x != rd:0x >>>> ar5212Attach: hardware self-test failed >>>> ath0: unable to attach hardware; HAL status 14 >>>> device_attach: ath0 attach returned 6 >>>> >>>> I read the registers 4004 and 4010 again to make sure the >values >>>still are the same, which indeed they are. >>>> >>>> I hope this helps. >>>> >>>> Thanks! >>>> >>>> On Donnerstag, 13. Dezember 2012 at 10:18 PM, "Adrian Chadd" >>> wrote: >>>>> >>>>>On 13 December 2012 13:11, wrote: >>>>>> Hello everyone, >>>>>> >>>>>> I'm afraid I still don't know what exactly BAR is, or how I >get >>>>>its value that I'm supposed to plug into the line John >provided: >>>>>> dd if=/dev/mem bs=4 iseek=((start of bar + reg offset)/4) >>>>>count=1 | hd >>>>>> >>>>>> I assumed that "start of bar" is 0xfdee in my case, since >>>>>dmesg reports >>>>>> ath0: mem 0xfdee-0xfdee irq 16 at >device >>>>>4.0 on pci2 >>>>> >>>>>Yup. >>>>> >>>>>> This is what I get: >>>>>> # dd if=/dev/mem bs=4 iseek=`echo "ibase=16; >(FDEE+4004)/4" >>>>>| bc` count=1 | hd >>>>>> 00 00 01 00 >>>>>> # dd if=/dev/mem bs=4 iseek=`echo "ibase=16; >(FDEE+4010)/4" >>>>>| bc` count=1 | hd >>>>>> 14 00 01 00 >>>>>> >>>>>> Please correct me if my assumption about "start of bar" was >>>>>wrong and/or I made some other mistake. >>>>>> Also, please don't hesitate to ask me to do anything else >that >>>>>might help you during debugging. >>>>>> >>>>>> Thank you very much for the effort. >>>>> >>>>>Hm. Wait, what's the rest of the ath0: output? >>>>> >>>>> >>>>> >>>>>Adrian >> ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ath0: unable to attach hardware
Hi, Just leave all of the ath/ah options in the kernel. Then comment out device ath device ath_hal device ath_rate_sample .. but yes, leave all the options in there. Adrian On 27 December 2012 12:06, wrote: > Hello, > > I hope you had a pleasant trip. Sorry for not replying for a while. > > Anyway, I tried to do what you asked me to. However, it seems like I > misunderstood the handbook and/or your request, as I failed to compile the > kernel. > > I copied my previous, working kernel config to a new file, and commented the > devices ath, ath_pci, ath_hal and ath_rate_sample, as well as the options > AH_SUPPORT_AR5416, AH_DEBUG and ATH_DEBUG. I did this because I could not > find instructions in the handbook that explained how to build a module as a > kld, and commenting the modules out was my best guess. Please point me to the > relevant section in the handbook in the case that the information was > actually there and I just was unable to find it. > The full kernel config can be seen here: http://nopaste.info/d7475552bd.html > Finally, I went to /usr/src and entered > make buildkernel KERNCONF=PAVILIONNOATH > > This is what I suspect is the relevant output: > > cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc > -I. -I/usr/src/sys/modules/ath/../../dev/ath > -I/usr/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS > -include /usr/obj/usr/src/sys/PAVILIONNOATH/opt_global.h -I. -I@ > -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param > large-function-growth=1000 -fno-common -g -fno-omit-frame-pointer > -I/usr/obj/usr/src/sys/PAVILIONNOATH -mno-sse -mcmodel=kernel -mno-red-zone > -mno-mmx -msoft-float -fno-asynchronous-unwind-tables -ffreestanding > -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls > -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith > -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions > -Wmissing-include-dirs -fdiagnostics-show-option -c > /usr/src/sys/modules/ath/../../dev/ath/ath_hal/ah.c > In file included from /usr/src/sys/modules/ath/../../dev/ath/ath_hal/ah.c:55: > @/net/if_var.h:125: error: 'IFNAMSIZ' undeclared here (not in a function) > @/net/if_var.h:151: error: field 'if_data' has incomplete type > cc1: warnings being treated as errors > @/net/if_var.h:157: warning: 'struct sockaddr' declared inside parameter list > @/net/if_var.h:157: warning: its scope is only this definition or > declaration, which is probably not what you want > @/net/if_var.h:167: warning: 'struct sockaddr' declared inside parameter list > @/net/if_var.h:187: error: 'AF_MAX' undeclared here (not in a function) > @/net/if_var.h:718: error: field 'if_data' has incomplete type > /usr/src/sys/modules/ath/../../dev/ath/ath_hal/ah.c: In function > 'ath_hal_attach': > /usr/src/sys/modules/ath/../../dev/ath/ath_hal/ah.c:65: warning: > dereferencing 'void *' pointer > /usr/src/sys/modules/ath/../../dev/ath/ath_hal/ah.c:65: error: request for > member 'sc_ifp' in something not a structure or union > /usr/src/sys/modules/ath/../../dev/ath/ath_hal/ah.c:70: warning: > dereferencing 'void *' pointer > /usr/src/sys/modules/ath/../../dev/ath/ath_hal/ah.c:70: error: request for > member 'sc_ifp' in something not a structure or union > *** Error code 1 > > The full output has been posted to http://nopaste.info/408e62ac0f.html > > I'm willing and hoping to help troubleshoot this issue, but please keep in > mind that I'm new to FreeBSD, so please give detailed instructions whenever > you can. > > Thank you very much! > >> >>Hi, >> >>Ok. I'm travelling for a little bit; if I don't reply in a few >>days, >>please poke me again. >> >>It may be that the device is asleep for a bit longer (failing this >>test) and has completed resetting at this point. >> >>It may be that the power on sequence is not quite right for some >>reason. >> >>Would you mind recompiling your kernel and making if_ath a kld, >>rather >>than statically in the kernel? >> >>Thanks, >> >> >>Adrian >> >>> >>> attached to this e-mail you find the output of dmesg. What I >>guess the most relevant lines could be is: >>> >>> ath0: mem 0xfdee-0xfdee irq 16 at device >>4.0 on pci2 >>> ar5212ChipTest: address test failed addr: 0x8000 - >>wr:0x != rd:0x >>> ar5212Attach: hardware self-test failed >>> ath0: unable to attach hardware; HAL
Re: ath0: unable to attach hardware
Hello, I hope you had a pleasant trip. Sorry for not replying for a while. Anyway, I tried to do what you asked me to. However, it seems like I misunderstood the handbook and/or your request, as I failed to compile the kernel. I copied my previous, working kernel config to a new file, and commented the devices ath, ath_pci, ath_hal and ath_rate_sample, as well as the options AH_SUPPORT_AR5416, AH_DEBUG and ATH_DEBUG. I did this because I could not find instructions in the handbook that explained how to build a module as a kld, and commenting the modules out was my best guess. Please point me to the relevant section in the handbook in the case that the information was actually there and I just was unable to find it. The full kernel config can be seen here: http://nopaste.info/d7475552bd.html Finally, I went to /usr/src and entered make buildkernel KERNCONF=PAVILIONNOATH This is what I suspect is the relevant output: cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/usr/src/sys/modules/ath/../../dev/ath -I/usr/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/PAVILIONNOATH/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -fno-omit-frame-pointer -I/usr/obj/usr/src/sys/PAVILIONNOATH -mno-sse -mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /usr/src/sys/modules/ath/../../dev/ath/ath_hal/ah.c In file included from /usr/src/sys/modules/ath/../../dev/ath/ath_hal/ah.c:55: @/net/if_var.h:125: error: 'IFNAMSIZ' undeclared here (not in a function) @/net/if_var.h:151: error: field 'if_data' has incomplete type cc1: warnings being treated as errors @/net/if_var.h:157: warning: 'struct sockaddr' declared inside parameter list @/net/if_var.h:157: warning: its scope is only this definition or declaration, which is probably not what you want @/net/if_var.h:167: warning: 'struct sockaddr' declared inside parameter list @/net/if_var.h:187: error: 'AF_MAX' undeclared here (not in a function) @/net/if_var.h:718: error: field 'if_data' has incomplete type /usr/src/sys/modules/ath/../../dev/ath/ath_hal/ah.c: In function 'ath_hal_attach': /usr/src/sys/modules/ath/../../dev/ath/ath_hal/ah.c:65: warning: dereferencing 'void *' pointer /usr/src/sys/modules/ath/../../dev/ath/ath_hal/ah.c:65: error: request for member 'sc_ifp' in something not a structure or union /usr/src/sys/modules/ath/../../dev/ath/ath_hal/ah.c:70: warning: dereferencing 'void *' pointer /usr/src/sys/modules/ath/../../dev/ath/ath_hal/ah.c:70: error: request for member 'sc_ifp' in something not a structure or union *** Error code 1 The full output has been posted to http://nopaste.info/408e62ac0f.html I'm willing and hoping to help troubleshoot this issue, but please keep in mind that I'm new to FreeBSD, so please give detailed instructions whenever you can. Thank you very much! > >Hi, > >Ok. I'm travelling for a little bit; if I don't reply in a few >days, >please poke me again. > >It may be that the device is asleep for a bit longer (failing this >test) and has completed resetting at this point. > >It may be that the power on sequence is not quite right for some >reason. > >Would you mind recompiling your kernel and making if_ath a kld, >rather >than statically in the kernel? > >Thanks, > > >Adrian > >> >> attached to this e-mail you find the output of dmesg. What I >guess the most relevant lines could be is: >> >> ath0: mem 0xfdee-0xfdee irq 16 at device >4.0 on pci2 >> ar5212ChipTest: address test failed addr: 0x8000 - >wr:0x != rd:0x >> ar5212Attach: hardware self-test failed >> ath0: unable to attach hardware; HAL status 14 >> device_attach: ath0 attach returned 6 >> >> I read the registers 4004 and 4010 again to make sure the values >still are the same, which indeed they are. >> >> I hope this helps. >> >> Thanks! >> >> On Donnerstag, 13. Dezember 2012 at 10:18 PM, "Adrian Chadd" > wrote: >>> >>>On 13 December 2012 13:11, wrote: >>>> Hello everyone, >>>> >>>> I'm afraid I still don't know what exactly BAR is, or how I get >>>its value that I'm supposed to plug into the line John provided: >>>>
Re: ath0: unable to attach hardware
Hi, Ok. I'm travelling for a little bit; if I don't reply in a few days, please poke me again. It may be that the device is asleep for a bit longer (failing this test) and has completed resetting at this point. It may be that the power on sequence is not quite right for some reason. Would you mind recompiling your kernel and making if_ath a kld, rather than statically in the kernel? Thanks, Adrian > > attached to this e-mail you find the output of dmesg. What I guess the most > relevant lines could be is: > > ath0: mem 0xfdee-0xfdee irq 16 at device 4.0 on pci2 > ar5212ChipTest: address test failed addr: 0x8000 - wr:0x != > rd:0x > ar5212Attach: hardware self-test failed > ath0: unable to attach hardware; HAL status 14 > device_attach: ath0 attach returned 6 > > I read the registers 4004 and 4010 again to make sure the values still are > the same, which indeed they are. > > I hope this helps. > > Thanks! > > On Donnerstag, 13. Dezember 2012 at 10:18 PM, "Adrian Chadd" > wrote: >> >>On 13 December 2012 13:11, wrote: >>> Hello everyone, >>> >>> I'm afraid I still don't know what exactly BAR is, or how I get >>its value that I'm supposed to plug into the line John provided: >>> dd if=/dev/mem bs=4 iseek=((start of bar + reg offset)/4) >>count=1 | hd >>> >>> I assumed that "start of bar" is 0xfdee in my case, since >>dmesg reports >>> ath0: mem 0xfdee-0xfdee irq 16 at device >>4.0 on pci2 >> >>Yup. >> >>> This is what I get: >>> # dd if=/dev/mem bs=4 iseek=`echo "ibase=16; (FDEE+4004)/4" >>| bc` count=1 | hd >>> 00 00 01 00 >>> # dd if=/dev/mem bs=4 iseek=`echo "ibase=16; (FDEE+4010)/4" >>| bc` count=1 | hd >>> 14 00 01 00 >>> >>> Please correct me if my assumption about "start of bar" was >>wrong and/or I made some other mistake. >>> Also, please don't hesitate to ask me to do anything else that >>might help you during debugging. >>> >>> Thank you very much for the effort. >> >>Hm. Wait, what's the rest of the ath0: output? >> >> >> >>Adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ath0: unable to attach hardware
On 13 December 2012 13:11, wrote: > Hello everyone, > > I'm afraid I still don't know what exactly BAR is, or how I get its value > that I'm supposed to plug into the line John provided: > dd if=/dev/mem bs=4 iseek=((start of bar + reg offset)/4) count=1 | hd > > I assumed that "start of bar" is 0xfdee in my case, since dmesg reports > ath0: mem 0xfdee-0xfdee irq 16 at device 4.0 on pci2 Yup. > This is what I get: > # dd if=/dev/mem bs=4 iseek=`echo "ibase=16; (FDEE+4004)/4" | bc` count=1 > | hd > 00 00 01 00 > # dd if=/dev/mem bs=4 iseek=`echo "ibase=16; (FDEE+4010)/4" | bc` count=1 > | hd > 14 00 01 00 > > Please correct me if my assumption about "start of bar" was wrong and/or I > made some other mistake. > Also, please don't hesitate to ask me to do anything else that might help you > during debugging. > > Thank you very much for the effort. Hm. Wait, what's the rest of the ath0: output? Adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ath0: unable to attach hardware
Hello everyone, I'm afraid I still don't know what exactly BAR is, or how I get its value that I'm supposed to plug into the line John provided: dd if=/dev/mem bs=4 iseek=((start of bar + reg offset)/4) count=1 | hd I assumed that "start of bar" is 0xfdee in my case, since dmesg reports ath0: mem 0xfdee-0xfdee irq 16 at device 4.0 on pci2 This is what I get: # dd if=/dev/mem bs=4 iseek=`echo "ibase=16; (FDEE+4004)/4" | bc` count=1 | hd 00 00 01 00 # dd if=/dev/mem bs=4 iseek=`echo "ibase=16; (FDEE+4010)/4" | bc` count=1 | hd 14 00 01 00 Please correct me if my assumption about "start of bar" was wrong and/or I made some other mistake. Also, please don't hesitate to ask me to do anything else that might help you during debugging. Thank you very much for the effort. > >On 11 December 2012 12:49, John Baldwin wrote: > > >> Look, it's up to you to look at more registers if you want to >debug this >> further. PCI says everything is ok, so the ball is in your >court. > >Right, that's why I've asked for those two above registers. > >There are other things that could be wrong - eg, the device may >actually not have reset correctly. > >This isn't the first time that someone's come to me with a "linux >works, freebsd doesn't" for an AR5212 era NIC. ath5k and FreeBSD do >the same thing at probe/attach time. I believe they do the same >thing >during device power-on time too. There's some corner cases where >the >chip doesn't reset right because the BIOS PCI bus reset code does >things in a brain dead manner (eg doing two PCI bus resets back to >back with not enough time in between for the MAC to settle.) > >There may be PCI code differences in how Linux and FreeBSD does >things >like "reset the PCI bus." > > > >Adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ath0: unable to attach hardware
On 11 December 2012 12:49, John Baldwin wrote: > Look, it's up to you to look at more registers if you want to debug this > further. PCI says everything is ok, so the ball is in your court. Right, that's why I've asked for those two above registers. There are other things that could be wrong - eg, the device may actually not have reset correctly. This isn't the first time that someone's come to me with a "linux works, freebsd doesn't" for an AR5212 era NIC. ath5k and FreeBSD do the same thing at probe/attach time. I believe they do the same thing during device power-on time too. There's some corner cases where the chip doesn't reset right because the BIOS PCI bus reset code does things in a brain dead manner (eg doing two PCI bus resets back to back with not enough time in between for the MAC to settle.) There may be PCI code differences in how Linux and FreeBSD does things like "reset the PCI bus." Adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ath0: unable to attach hardware
On Monday, December 10, 2012 5:20:53 pm Adrian Chadd wrote: > Hi, > > The fact the initial probe/attach fails by returning 0x means > the chip isn't "right" on the bus. > > It's either just not mapped in correctly, or it's "powered off." > > If it were just asleep, it'd return 0xdeadc0de or 0xdeadbeef or > something similar like that. > > Try AR_SCR (0x4004) and AR_PCICFG (0x4010) . > > Thanks, Look, it's up to you to look at more registers if you want to debug this further. PCI says everything is ok, so the ball is in your court. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ath0: unable to attach hardware
Hi, The fact the initial probe/attach fails by returning 0x means the chip isn't "right" on the bus. It's either just not mapped in correctly, or it's "powered off." If it were just asleep, it'd return 0xdeadc0de or 0xdeadbeef or something similar like that. Try AR_SCR (0x4004) and AR_PCICFG (0x4010) . Thanks, Adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ath0: unable to attach hardware
On Friday, December 07, 2012 4:59:37 am hu...@hush.com wrote: > Hello, > > thank you for your answer. > > Unfortunately, I'm unexperienced with FreeBSD, and am absolutely unfamiliar with hardware specifics. During this mail conversion, I have heard abour BAR for the first time, and therefore, I know neither what exactly I should do (e.g. how I can find the start of bar, which register offsets would be interesting, etc.), nor what the results would tell me. > > I'm sorry if I'm tedious, but I would be very grateful if you could provide some more guidance. > > Thank you very much! Adrian should be able to do that for you. He knows which registers he wants to see. > On Dienstag, 4. Dezember 2012 at 7:43 PM, "John Baldwin" wrote: > > > >On Friday, November 23, 2012 5:56:02 pm Adrian Chadd wrote: > >> Thanks for this! > >> > >> I'm sorry it hasn't gotten any more attention. I've cc'ed john > >because > >> he understands the PCI-PCI resource allocation stuff and I > >currently > >> don't; I'm hoping he can stare at this and see what's going on. > >> > >> But yes, if it were an ath(4) problem, the NIC would be returning > >> 0xdeadbeef, 0xdeadc0de, etc. It wouldn't return 0x - that > >> happens when there's nothing mapped at that address. > >> > >> The PCI config space that you've provided shows BAR(0) is > >programmed > >correctly.. > > > >Your dmesg shows that another device behind the same PCI-PCI > >bridge is working > >fine (fxp0), so the bridge is configured correctly. Also, the PCI > >command > >register for ath0 has memory decoding enabled, so everything > >should be fine > >from PCI's perspective. Note that if you want to examine specific > >registers > >you can use dd with /dev/mem (albeit carefully), e.g. > > > > dd if=/dev/mem bs=4 iseek=((start of bar + reg offset)/4) > >count=1 | hd > > > >to read a single 32-bit register. I think that the card is in > >fact returning > >the value you see from its registers. I would do some reads of > >other > >registers using dd to see if all of the device registers are > >returning -1 or > >if only certain registers are. > > > >-- > >John Baldwin > > -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ath0: unable to attach hardware
Hello, thank you for your answer. Unfortunately, I'm unexperienced with FreeBSD, and am absolutely unfamiliar with hardware specifics. During this mail conversion, I have heard abour BAR for the first time, and therefore, I know neither what exactly I should do (e.g. how I can find the start of bar, which register offsets would be interesting, etc.), nor what the results would tell me. I'm sorry if I'm tedious, but I would be very grateful if you could provide some more guidance. Thank you very much! On Dienstag, 4. Dezember 2012 at 7:43 PM, "John Baldwin" wrote: > >On Friday, November 23, 2012 5:56:02 pm Adrian Chadd wrote: >> Thanks for this! >> >> I'm sorry it hasn't gotten any more attention. I've cc'ed john >because >> he understands the PCI-PCI resource allocation stuff and I >currently >> don't; I'm hoping he can stare at this and see what's going on. >> >> But yes, if it were an ath(4) problem, the NIC would be returning >> 0xdeadbeef, 0xdeadc0de, etc. It wouldn't return 0x - that >> happens when there's nothing mapped at that address. >> >> The PCI config space that you've provided shows BAR(0) is >programmed >correctly.. > >Your dmesg shows that another device behind the same PCI-PCI >bridge is working >fine (fxp0), so the bridge is configured correctly. Also, the PCI >command >register for ath0 has memory decoding enabled, so everything >should be fine >from PCI's perspective. Note that if you want to examine specific >registers >you can use dd with /dev/mem (albeit carefully), e.g. > > dd if=/dev/mem bs=4 iseek=((start of bar + reg offset)/4) >count=1 | hd > >to read a single 32-bit register. I think that the card is in >fact returning >the value you see from its registers. I would do some reads of >other >registers using dd to see if all of the device registers are >returning -1 or >if only certain registers are. > >-- >John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ath0: unable to attach hardware
On Friday, November 23, 2012 5:56:02 pm Adrian Chadd wrote: > Thanks for this! > > I'm sorry it hasn't gotten any more attention. I've cc'ed john because > he understands the PCI-PCI resource allocation stuff and I currently > don't; I'm hoping he can stare at this and see what's going on. > > But yes, if it were an ath(4) problem, the NIC would be returning > 0xdeadbeef, 0xdeadc0de, etc. It wouldn't return 0x - that > happens when there's nothing mapped at that address. > > The PCI config space that you've provided shows BAR(0) is programmed correctly.. Your dmesg shows that another device behind the same PCI-PCI bridge is working fine (fxp0), so the bridge is configured correctly. Also, the PCI command register for ath0 has memory decoding enabled, so everything should be fine from PCI's perspective. Note that if you want to examine specific registers you can use dd with /dev/mem (albeit carefully), e.g. dd if=/dev/mem bs=4 iseek=((start of bar + reg offset)/4) count=1 | hd to read a single 32-bit register. I think that the card is in fact returning the value you see from its registers. I would do some reads of other registers using dd to see if all of the device registers are returning -1 or if only certain registers are. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ath0: unable to attach hardware
00 >>>> >>>> I hope this helps you out. If not, please let me know what else >>>I can do. >>>> >>>> Thanks! >>>> >>>> On Freitag, 9. November 2012 at 5:45 PM, "Adrian Chadd" >>> wrote: >>>>> >>>>>Can you use pciconf to dump the config space? >>>>> >>>>>I think its pciconf -r 0:255 >>>>> >>>>>thanks! >>>>> >>>>> >>>>> >>>>>adrian >>>>> >>>>>On 9 November 2012 01:57, wrote: >>>>>> Hello again, >>>>>> >>>>>> the mail I'm replying to (and which is cited below) hasn't >>>>>caused a reaction yet. Seeing that this mailing list has quite a >>>>>lot of traffic, I'm worried that the mail, and the issue it >>tries >>>>>to point out, will be forgotten. >>>>>> Should I file a bug report in hopes that the issue will >>>somewhen >>>>>be investigated/resolved? >>>>>> >>>>>> Again, I'm offering any kind of help I'm able to provide, i.e. >>>>>delivering more information upon (hopefully detailed enough for >>>me >>>>>to understand) request, testing proposed fixes and doing some >>>>>progamming on my own; for the latter, please keep in mind that I >>>>>have no experience with the FreeBSD codebase or hardware >>>>>programming. >>>>>> >>>>>> Thanks! >>>>>> >>>>>> On Samstag, 3. November 2012 at 11:43 AM, hu...@hush.com >>wrote: >>>>>>> >>>>>>>Hello everyone, >>>>>>> >>>>>>>I'm new to FreeBSD and wanted to install 9.0-RELEASE amd64 on >>a >>>>>PC >>>>>>>I was given. At first glance, it seems like everything is >>>>>working, >>>>>>>except the wireless LAN PCI card. >>>>>>> >>>>>>>I started a thread on freebsd-wireless on the 31st of October >>>>>(see >>>>>>>here: http://lists.freebsd.org/pipermail/freebsd- >>wireless/2012- >>>>>>>October/002511.html or a repost of my original message with >>>>>proper >>>>>>>formatting: http://lists.freebsd.org/pipermail/freebsd- >>>>>>>wireless/2012-October/002513.html ) >>>>>>> >>>>>>>Short summary: >>>>>>>The card has the strings "Anatel", "WN5301A-H1-V02" and >>>>>>>"KN160562*7" printed on it, although I'm not sure which, if >>>any, >>>>>>>of those is a proper product number. >>>>>>>After setting >>>>>>> >>>>>>>hw.ath.debug=1 >>>>>>>hw.ath.hal.debug=1 >>>>>>> >>>>>>>I receive >>>>>>> >>>>>>>ath0: mem 0xfdee-0xfdee irq 16 at >>device >>>>>>>4.0 on pci2 >>>>>>>ar5212ChipTest: address test failed addr: 0x8000 - >>>>>>>wr:0x != rd:0x >>>>>>>ar5212Attach: hardware self-test failed >>>>>>>ath0: unable to attach hardware; HAL status 14 >>>>>>>device_attach: ath0 attach returned 6 >>>>>>> >>>>>>>and am left unable to use the device. >>>>>>>I tried 8.3-RELEASE i386 as well as 10.0-CURRENT amd64 and >>i386 >>>>>>>snapshots from https://snapshots.glenbarber.us/Latest/ >>>>>(seemlingly >>>>>>>built a few days ago) and received the same messages, >>although >>>I >>>>>>>did not get the debug messages since I booted off of the >>>>>>>installation media and therefore had a stock kernel, which >>>>>>>seemingly doesn't enable ATH_DEBUG and AH_DEBUG. Booting the >>>>>>>Ubuntu 12.04 amd64 installation media, I can use the NIC >>>without >>>>>>>having any problems. >>>>>>> >>>>>>>Adrian Chadd tried to help me via freebsd-wireless (thank you >>>>>>>again,) but ultimately asked me this: >>>>>>>"Please try a recent -HEAD i386 and amd64 snapshot and if that >>>>>>>doesn't >>>>>>>work, you could try posting for help on freebsd-current. But >>>>>please >>>>>>>stress that I think it's a bus enumeration and PCI bridge >>>>>>>programming >>>>>>>problem, _not_ a driver problem." >>>>>>> >>>>>>>And so I did. >>>>>>> >>>>>>>I'd be very glad if you could try to help me. Of course, I'm >>>>>>>willing to provide any kind of information you might need, but >>>>>>>please keep in mind that I'm new to FreeBSD and therefore >>would >>>>>be >>>>>>>thankful if you stated your instructions/requests in a newbie- >>>>>>>friendly way. >>>>>>> >>>>>>>Thank you. >>>>>>> >>>>>>>___ >>>>>>>freebsd-current@freebsd.org mailing list >>>>>>>http://lists.freebsd.org/mailman/listinfo/freebsd-current >>>>>>>To unsubscribe, send any mail to "freebsd-current- >>>>>>>unsubscr...@freebsd.org" >>>>>> >>>>>> ___ >>>>>> freebsd-current@freebsd.org mailing list >>>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-current >>>>>> To unsubscribe, send any mail to "freebsd-current- >>>>>unsubscr...@freebsd.org" >>>> > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ath0: unable to attach hardware
ld I file a bug report in hopes that the issue will >>somewhen >>>>be investigated/resolved? >>>>> >>>>> Again, I'm offering any kind of help I'm able to provide, i.e. >>>>delivering more information upon (hopefully detailed enough for >>me >>>>to understand) request, testing proposed fixes and doing some >>>>progamming on my own; for the latter, please keep in mind that I >>>>have no experience with the FreeBSD codebase or hardware >>>>programming. >>>>> >>>>> Thanks! >>>>> >>>>> On Samstag, 3. November 2012 at 11:43 AM, hu...@hush.com >wrote: >>>>>> >>>>>>Hello everyone, >>>>>> >>>>>>I'm new to FreeBSD and wanted to install 9.0-RELEASE amd64 on >a >>>>PC >>>>>>I was given. At first glance, it seems like everything is >>>>working, >>>>>>except the wireless LAN PCI card. >>>>>> >>>>>>I started a thread on freebsd-wireless on the 31st of October >>>>(see >>>>>>here: http://lists.freebsd.org/pipermail/freebsd- >wireless/2012- >>>>>>October/002511.html or a repost of my original message with >>>>proper >>>>>>formatting: http://lists.freebsd.org/pipermail/freebsd- >>>>>>wireless/2012-October/002513.html ) >>>>>> >>>>>>Short summary: >>>>>>The card has the strings "Anatel", "WN5301A-H1-V02" and >>>>>>"KN160562*7" printed on it, although I'm not sure which, if >>any, >>>>>>of those is a proper product number. >>>>>>After setting >>>>>> >>>>>>hw.ath.debug=1 >>>>>>hw.ath.hal.debug=1 >>>>>> >>>>>>I receive >>>>>> >>>>>>ath0: mem 0xfdee-0xfdee irq 16 at >device >>>>>>4.0 on pci2 >>>>>>ar5212ChipTest: address test failed addr: 0x8000 - >>>>>>wr:0x != rd:0x >>>>>>ar5212Attach: hardware self-test failed >>>>>>ath0: unable to attach hardware; HAL status 14 >>>>>>device_attach: ath0 attach returned 6 >>>>>> >>>>>>and am left unable to use the device. >>>>>>I tried 8.3-RELEASE i386 as well as 10.0-CURRENT amd64 and >i386 >>>>>>snapshots from https://snapshots.glenbarber.us/Latest/ >>>>(seemlingly >>>>>>built a few days ago) and received the same messages, >although >>I >>>>>>did not get the debug messages since I booted off of the >>>>>>installation media and therefore had a stock kernel, which >>>>>>seemingly doesn't enable ATH_DEBUG and AH_DEBUG. Booting the >>>>>>Ubuntu 12.04 amd64 installation media, I can use the NIC >>without >>>>>>having any problems. >>>>>> >>>>>>Adrian Chadd tried to help me via freebsd-wireless (thank you >>>>>>again,) but ultimately asked me this: >>>>>>"Please try a recent -HEAD i386 and amd64 snapshot and if that >>>>>>doesn't >>>>>>work, you could try posting for help on freebsd-current. But >>>>please >>>>>>stress that I think it's a bus enumeration and PCI bridge >>>>>>programming >>>>>>problem, _not_ a driver problem." >>>>>> >>>>>>And so I did. >>>>>> >>>>>>I'd be very glad if you could try to help me. Of course, I'm >>>>>>willing to provide any kind of information you might need, but >>>>>>please keep in mind that I'm new to FreeBSD and therefore >would >>>>be >>>>>>thankful if you stated your instructions/requests in a newbie- >>>>>>friendly way. >>>>>> >>>>>>Thank you. >>>>>> >>>>>>___ >>>>>>freebsd-current@freebsd.org mailing list >>>>>>http://lists.freebsd.org/mailman/listinfo/freebsd-current >>>>>>To unsubscribe, send any mail to "freebsd-current- >>>>>>unsubscr...@freebsd.org" >>>>> >>>>> ___ >>>>> freebsd-current@freebsd.org mailing list >>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-current >>>>> To unsubscribe, send any mail to "freebsd-current- >>>>unsubscr...@freebsd.org" >>> ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ath0: unable to attach hardware
Hi, I'm CC'ing jhb@ (who is likely busy after Hurricane Sandy..) who spends time in the PCI bridge code. That looks correct (ie, the BAR(0) entry matches your dmesg entry.) The 0x register response however means that it isn't mapped into that particular region correctly. An asleep NIC will return 0xdeadbeef, 0xdeadc0de, etc. It doesn't return 0x for registers (well, except for AR_ISR, but that isn't being probed at this point.) Did you post a boot -v to -current, showing what all the PCI bridges are? I'd like to ensure that they're all setup right. Unfortunately I don't have time to try and figure out what's going on with the PCI bridge and resource allocation side of things. John - I think this is a PCI-PCI bridge resource allocation / setup problem. The BAR(0) for the NIC matches what the probe/attach line for ath0 says. but the register value of 0x to me indicates the NIC isn't mapped into that space correctly. The internal PCI glue in the NIC will return 0xdeadbeef, 0xdeadc0de, etc as register contents if the device is asleep and hasn't been woken up or reset correctly. It won't return 0x. I would really appreciate any help you or others can provide on this. Thanks, Adrian On 9 November 2012 15:25, wrote: > Hello, > > thank you for your reply. > > I've entered the following > pciconf -r ath0@pci0:2:4:0 0:255 > and received this output: > > 001b168c 02900406 0201 2008 > fdee > 5001 500111ad > 0044 1c0a0110 > 01c20001 c6004000 > > > > > > > > > > > > > I hope this helps you out. If not, please let me know what else I can do. > > Thanks! > > On Freitag, 9. November 2012 at 5:45 PM, "Adrian Chadd" > wrote: >> >>Can you use pciconf to dump the config space? >> >>I think its pciconf -r 0:255 >> >>thanks! >> >> >> >>adrian >> >>On 9 November 2012 01:57, wrote: >>> Hello again, >>> >>> the mail I'm replying to (and which is cited below) hasn't >>caused a reaction yet. Seeing that this mailing list has quite a >>lot of traffic, I'm worried that the mail, and the issue it tries >>to point out, will be forgotten. >>> Should I file a bug report in hopes that the issue will somewhen >>be investigated/resolved? >>> >>> Again, I'm offering any kind of help I'm able to provide, i.e. >>delivering more information upon (hopefully detailed enough for me >>to understand) request, testing proposed fixes and doing some >>progamming on my own; for the latter, please keep in mind that I >>have no experience with the FreeBSD codebase or hardware >>programming. >>> >>> Thanks! >>> >>> On Samstag, 3. November 2012 at 11:43 AM, hu...@hush.com wrote: >>>> >>>>Hello everyone, >>>> >>>>I'm new to FreeBSD and wanted to install 9.0-RELEASE amd64 on a >>PC >>>>I was given. At first glance, it seems like everything is >>working, >>>>except the wireless LAN PCI card. >>>> >>>>I started a thread on freebsd-wireless on the 31st of October >>(see >>>>here: http://lists.freebsd.org/pipermail/freebsd-wireless/2012- >>>>October/002511.html or a repost of my original message with >>proper >>>>formatting: http://lists.freebsd.org/pipermail/freebsd- >>>>wireless/2012-October/002513.html ) >>>> >>>>Short summary: >>>>The card has the strings "Anatel", "WN5301A-H1-V02" and >>>>"KN160562*7" printed on it, although I'm not sure which, if any, >>>>of those is a proper product number. >>>>After setting >>>> >>>>hw.ath.debug=1 >>>>hw.ath.hal.debug=1 >>>> >>>>I receive >>>> >>>>ath0: mem 0xfdee-0xfdee irq 16 at device >>>>4.0 on pci2 >>>>ar5212ChipTest: address test failed addr: 0x8000 - >>>>wr:0x != rd:0x >>>>ar5212Attach: hardware self-test failed >>>>ath0: unabl
Re: ath0: unable to attach hardware
Hello,
thank you for your reply.
I've entered the following
pciconf -r ath0@pci0:2:4:0 0:255
and received this output:
001b168c 02900406 0201 2008
fdee
5001 500111ad
0044 1c0a0110
01c20001 c6004000
I hope this helps you out. If not, please let me know what else I can do.
Thanks!
On Freitag, 9. November 2012 at 5:45 PM, "Adrian Chadd"
wrote:
>
>Can you use pciconf to dump the config space?
>
>I think its pciconf -r 0:255
>
>thanks!
>
>
>
>adrian
>
>On 9 November 2012 01:57, wrote:
>> Hello again,
>>
>> the mail I'm replying to (and which is cited below) hasn't
>caused a reaction yet. Seeing that this mailing list has quite a
>lot of traffic, I'm worried that the mail, and the issue it tries
>to point out, will be forgotten.
>> Should I file a bug report in hopes that the issue will somewhen
>be investigated/resolved?
>>
>> Again, I'm offering any kind of help I'm able to provide, i.e.
>delivering more information upon (hopefully detailed enough for me
>to understand) request, testing proposed fixes and doing some
>progamming on my own; for the latter, please keep in mind that I
>have no experience with the FreeBSD codebase or hardware
>programming.
>>
>> Thanks!
>>
>> On Samstag, 3. November 2012 at 11:43 AM, hu...@hush.com wrote:
>>>
>>>Hello everyone,
>>>
>>>I'm new to FreeBSD and wanted to install 9.0-RELEASE amd64 on a
>PC
>>>I was given. At first glance, it seems like everything is
>working,
>>>except the wireless LAN PCI card.
>>>
>>>I started a thread on freebsd-wireless on the 31st of October
>(see
>>>here: http://lists.freebsd.org/pipermail/freebsd-wireless/2012-
>>>October/002511.html or a repost of my original message with
>proper
>>>formatting: http://lists.freebsd.org/pipermail/freebsd-
>>>wireless/2012-October/002513.html )
>>>
>>>Short summary:
>>>The card has the strings "Anatel", "WN5301A-H1-V02" and
>>>"KN160562*7" printed on it, although I'm not sure which, if any,
>>>of those is a proper product number.
>>>After setting
>>>
>>>hw.ath.debug=1
>>>hw.ath.hal.debug=1
>>>
>>>I receive
>>>
>>>ath0: mem 0xfdee-0xfdee irq 16 at device
>>>4.0 on pci2
>>>ar5212ChipTest: address test failed addr: 0x8000 -
>>>wr:0x != rd:0x
>>>ar5212Attach: hardware self-test failed
>>>ath0: unable to attach hardware; HAL status 14
>>>device_attach: ath0 attach returned 6
>>>
>>>and am left unable to use the device.
>>>I tried 8.3-RELEASE i386 as well as 10.0-CURRENT amd64 and i386
>>>snapshots from https://snapshots.glenbarber.us/Latest/
>(seemlingly
>>>built a few days ago) and received the same messages, although I
>>>did not get the debug messages since I booted off of the
>>>installation media and therefore had a stock kernel, which
>>>seemingly doesn't enable ATH_DEBUG and AH_DEBUG. Booting the
>>>Ubuntu 12.04 amd64 installation media, I can use the NIC without
>>>having any problems.
>>>
>>>Adrian Chadd tried to help me via freebsd-wireless (thank you
>>>again,) but ultimately asked me this:
>>>"Please try a recent -HEAD i386 and amd64 snapshot and if that
>>>doesn't
>>>work, you could try posting for help on freebsd-current. But
>please
>>>stress that I think it's a bus enumeration and PCI bridge
>>>programming
>>>problem, _not_ a driver problem."
>>>
>>>And so I did.
>>>
>>>I'd be very glad if you could try to help me. Of course, I'm
>>>willing to provide any kind of information you might need, but
>>>please keep in mind that I'm new to FreeBSD and therefore would
>be
>>>thankful if you stated your instructions/requests in a newbie-
>>>friendly way.
>>>
>>>Thank you.
>>>
>>>___
>>>freebsd-current@freebsd.org mailing list
>>>http://lists.freebsd.org/mailman/listinfo/freebsd-current
>>>To unsubscribe, send any mail to "freebsd-current-
>>>unsubscr...@freebsd.org"
>>
>> ___
>> freebsd-current@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to "freebsd-current-
>unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ath0: unable to attach hardware
Can you use pciconf to dump the config space? I think its pciconf -r 0:255 thanks! adrian On 9 November 2012 01:57, wrote: > Hello again, > > the mail I'm replying to (and which is cited below) hasn't caused a reaction > yet. Seeing that this mailing list has quite a lot of traffic, I'm worried > that the mail, and the issue it tries to point out, will be forgotten. > Should I file a bug report in hopes that the issue will somewhen be > investigated/resolved? > > Again, I'm offering any kind of help I'm able to provide, i.e. delivering > more information upon (hopefully detailed enough for me to understand) > request, testing proposed fixes and doing some progamming on my own; for the > latter, please keep in mind that I have no experience with the FreeBSD > codebase or hardware programming. > > Thanks! > > On Samstag, 3. November 2012 at 11:43 AM, hu...@hush.com wrote: >> >>Hello everyone, >> >>I'm new to FreeBSD and wanted to install 9.0-RELEASE amd64 on a PC >>I was given. At first glance, it seems like everything is working, >>except the wireless LAN PCI card. >> >>I started a thread on freebsd-wireless on the 31st of October (see >>here: http://lists.freebsd.org/pipermail/freebsd-wireless/2012- >>October/002511.html or a repost of my original message with proper >>formatting: http://lists.freebsd.org/pipermail/freebsd- >>wireless/2012-October/002513.html ) >> >>Short summary: >>The card has the strings "Anatel", "WN5301A-H1-V02" and >>"KN160562*7" printed on it, although I'm not sure which, if any, >>of those is a proper product number. >>After setting >> >>hw.ath.debug=1 >>hw.ath.hal.debug=1 >> >>I receive >> >>ath0: mem 0xfdee-0xfdee irq 16 at device >>4.0 on pci2 >>ar5212ChipTest: address test failed addr: 0x8000 - >>wr:0x != rd:0x >>ar5212Attach: hardware self-test failed >>ath0: unable to attach hardware; HAL status 14 >>device_attach: ath0 attach returned 6 >> >>and am left unable to use the device. >>I tried 8.3-RELEASE i386 as well as 10.0-CURRENT amd64 and i386 >>snapshots from https://snapshots.glenbarber.us/Latest/ (seemlingly >>built a few days ago) and received the same messages, although I >>did not get the debug messages since I booted off of the >>installation media and therefore had a stock kernel, which >>seemingly doesn't enable ATH_DEBUG and AH_DEBUG. Booting the >>Ubuntu 12.04 amd64 installation media, I can use the NIC without >>having any problems. >> >>Adrian Chadd tried to help me via freebsd-wireless (thank you >>again,) but ultimately asked me this: >>"Please try a recent -HEAD i386 and amd64 snapshot and if that >>doesn't >>work, you could try posting for help on freebsd-current. But please >>stress that I think it's a bus enumeration and PCI bridge >>programming >>problem, _not_ a driver problem." >> >>And so I did. >> >>I'd be very glad if you could try to help me. Of course, I'm >>willing to provide any kind of information you might need, but >>please keep in mind that I'm new to FreeBSD and therefore would be >>thankful if you stated your instructions/requests in a newbie- >>friendly way. >> >>Thank you. >> >>___ >>freebsd-current@freebsd.org mailing list >>http://lists.freebsd.org/mailman/listinfo/freebsd-current >>To unsubscribe, send any mail to "freebsd-current- >>unsubscr...@freebsd.org" > > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ath0: unable to attach hardware
Hello again, the mail I'm replying to (and which is cited below) hasn't caused a reaction yet. Seeing that this mailing list has quite a lot of traffic, I'm worried that the mail, and the issue it tries to point out, will be forgotten. Should I file a bug report in hopes that the issue will somewhen be investigated/resolved? Again, I'm offering any kind of help I'm able to provide, i.e. delivering more information upon (hopefully detailed enough for me to understand) request, testing proposed fixes and doing some progamming on my own; for the latter, please keep in mind that I have no experience with the FreeBSD codebase or hardware programming. Thanks! On Samstag, 3. November 2012 at 11:43 AM, hu...@hush.com wrote: > >Hello everyone, > >I'm new to FreeBSD and wanted to install 9.0-RELEASE amd64 on a PC >I was given. At first glance, it seems like everything is working, >except the wireless LAN PCI card. > >I started a thread on freebsd-wireless on the 31st of October (see >here: http://lists.freebsd.org/pipermail/freebsd-wireless/2012- >October/002511.html or a repost of my original message with proper >formatting: http://lists.freebsd.org/pipermail/freebsd- >wireless/2012-October/002513.html ) > >Short summary: >The card has the strings "Anatel", "WN5301A-H1-V02" and >"KN160562*7" printed on it, although I'm not sure which, if any, >of those is a proper product number. >After setting > >hw.ath.debug=1 >hw.ath.hal.debug=1 > >I receive > >ath0: mem 0xfdee-0xfdee irq 16 at device >4.0 on pci2 >ar5212ChipTest: address test failed addr: 0x8000 - >wr:0x != rd:0x >ar5212Attach: hardware self-test failed >ath0: unable to attach hardware; HAL status 14 >device_attach: ath0 attach returned 6 > >and am left unable to use the device. >I tried 8.3-RELEASE i386 as well as 10.0-CURRENT amd64 and i386 >snapshots from https://snapshots.glenbarber.us/Latest/ (seemlingly >built a few days ago) and received the same messages, although I >did not get the debug messages since I booted off of the >installation media and therefore had a stock kernel, which >seemingly doesn't enable ATH_DEBUG and AH_DEBUG. Booting the >Ubuntu 12.04 amd64 installation media, I can use the NIC without >having any problems. > >Adrian Chadd tried to help me via freebsd-wireless (thank you >again,) but ultimately asked me this: >"Please try a recent -HEAD i386 and amd64 snapshot and if that >doesn't >work, you could try posting for help on freebsd-current. But please >stress that I think it's a bus enumeration and PCI bridge >programming >problem, _not_ a driver problem." > >And so I did. > >I'd be very glad if you could try to help me. Of course, I'm >willing to provide any kind of information you might need, but >please keep in mind that I'm new to FreeBSD and therefore would be >thankful if you stated your instructions/requests in a newbie- >friendly way. > >Thank you. > >___ >freebsd-current@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-current >To unsubscribe, send any mail to "freebsd-current- >unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
ath0: unable to attach hardware
Hello everyone, I'm new to FreeBSD and wanted to install 9.0-RELEASE amd64 on a PC I was given. At first glance, it seems like everything is working, except the wireless LAN PCI card. I started a thread on freebsd-wireless on the 31st of October (see here: http://lists.freebsd.org/pipermail/freebsd-wireless/2012-October/002511.html or a repost of my original message with proper formatting: http://lists.freebsd.org/pipermail/freebsd-wireless/2012-October/002513.html ) Short summary: The card has the strings "Anatel", "WN5301A-H1-V02" and "KN160562*7" printed on it, although I'm not sure which, if any, of those is a proper product number. After setting hw.ath.debug=1 hw.ath.hal.debug=1 I receive ath0: mem 0xfdee-0xfdee irq 16 at device 4.0 on pci2 ar5212ChipTest: address test failed addr: 0x8000 - wr:0x != rd:0x ar5212Attach: hardware self-test failed ath0: unable to attach hardware; HAL status 14 device_attach: ath0 attach returned 6 and am left unable to use the device. I tried 8.3-RELEASE i386 as well as 10.0-CURRENT amd64 and i386 snapshots from https://snapshots.glenbarber.us/Latest/ (seemlingly built a few days ago) and received the same messages, although I did not get the debug messages since I booted off of the installation media and therefore had a stock kernel, which seemingly doesn't enable ATH_DEBUG and AH_DEBUG. Booting the Ubuntu 12.04 amd64 installation media, I can use the NIC without having any problems. Adrian Chadd tried to help me via freebsd-wireless (thank you again,) but ultimately asked me this: "Please try a recent -HEAD i386 and amd64 snapshot and if that doesn't work, you could try posting for help on freebsd-current. But please stress that I think it's a bus enumeration and PCI bridge programming problem, _not_ a driver problem." And so I did. I'd be very glad if you could try to help me. Of course, I'm willing to provide any kind of information you might need, but please keep in mind that I'm new to FreeBSD and therefore would be thankful if you stated your instructions/requests in a newbie-friendly way. Thank you. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
