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 0xffffffff - that happens when there's nothing mapped at that address. The PCI config space that you've provided shows BAR(0) is programmed correctly.. adrian On 23 November 2012 13:35, <husyh_at_hush.com> wrote: > Hello everyone, > > since this problem hasn't got any attention in the last 14 days, I decided to file a bug report, so that this issue doesn't sink into oblivion: http://www.freebsd.org/cgi/query-pr.cgi?pr=173883 > > I'm still very glad for any attempt to help, and willing to provide more information and/or test things if you provide some guidance. > > Thanks! > > On Samstag, 10. November 2012 at 2:39 PM, husyh_at_hush.com wrote: >> >>Hello everyone, >> >>I took both the i386 and amd64 November snapshots of 10.0-CURRENT >>from https://snapshots.glenbarber.us/Latest/, and when the >>bootloader on the DVD appeared, I selected the verbose boot >>option, waited for the installer to come up, dropped to a shell >>and issued "dmesg", the output of which I piped to two files which >>hopefully are attached to this e-mail. In case they are stripped >>from the mailing list, I've posted their contents to a nopaste: >>http://nopaste.info/a445c43d6a.html for amd64 >>http://nopaste.info/bac000949c.html for i386 >> >>I hope this is the information you were asking for. Please let me >>know if I can do anything else. >> >>Thank you very much. >> >>On Samstag, 10. November 2012 at 7:49 AM, "Adrian Chadd" >><adrian_at_freebsd.org> wrote: >>> >>>Hi, >>> >>>I'm CC'ing jhb_at_ (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 0xffffffff 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 0xffffffff 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 0xffffffff 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 0xffffffff. >>> >>>I would really appreciate any help you or others can provide on >>>this. >>> >>>Thanks, >>> >>> >>> >>>Adrian >>> >>>On 9 November 2012 15:25, <husyh_at_hush.com> wrote: >>>> Hello, >>>> >>>> thank you for your reply. >>>> >>>> I've entered the following >>>> pciconf -r ath0_at_pci0:2:4:0 0:255 >>>> and received this output: >>>> >>>> 001b168c 02900406 02000001 00002008 >>>> fdee0000 00000000 00000000 00000000 >>>> 00000000 00000000 00005001 500111ad >>>> 00000000 00000044 00000000 1c0a0110 >>>> 00000000 01c20001 c6004000 00000000 >>>> 00000000 00000000 00000000 00000000 >>>> 00000000 00000000 00000000 00000000 >>>> 00000000 00000000 00000000 00000000 >>>> 00000000 00000000 00000000 00000000 >>>> 00000000 00000000 00000000 00000000 >>>> 00000000 00000000 00000000 00000000 >>>> 00000000 00000000 00000000 00000000 >>>> 00000000 00000000 00000000 00000000 >>>> 00000000 00000000 00000000 00000000 >>>> 00000000 00000000 00000000 00000000 >>>> 00000000 00000000 00000000 00000000 >>>> >>>> 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" >>><adrian_at_freebsd.org> wrote: >>>>> >>>>>Can you use pciconf to dump the config space? >>>>> >>>>>I think its pciconf -r <ath pci device string> 0:255 >>>>> >>>>>thanks! >>>>> >>>>> >>>>> >>>>>adrian >>>>> >>>>>On 9 November 2012 01:57, <husyh_at_hush.com> 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, husyh_at_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: <Atheros 5413> mem 0xfdee0000-0xfdeeffff irq 16 at >>device >>>>>>>4.0 on pci2 >>>>>>>ar5212ChipTest: address test failed addr: 0x00008000 - >>>>>>>wr:0x00000000 != rd:0xffffffff >>>>>>>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_at_freebsd.org mailing list >>>>>>>http://lists.freebsd.org/mailman/listinfo/freebsd-current >>>>>>>To unsubscribe, send any mail to "freebsd-current- >>>>>>>unsubscribe_at_freebsd.org" >>>>>> >>>>>> _______________________________________________ >>>>>> freebsd-current_at_freebsd.org mailing list >>>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-current >>>>>> To unsubscribe, send any mail to "freebsd-current- >>>>>unsubscribe_at_freebsd.org" >>>> >Received on Fri Nov 23 2012 - 21:56:04 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:32 UTC