ckaddr' 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'
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/m
ys/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
>>>> *
ror 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
ou 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
;>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 add
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
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
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
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
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
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_P
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
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 o
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.
>
> Bu
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 t
nd 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
reebsd-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-
>>>
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
>>>
ber.
>>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
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
>ar5212A
fff
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/ (seemli
23 matches
Mail list logo
