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