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:05:59 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:32 UTC