Hi,
I maybe should add that whenever I haven't explicitly mentioned the version of
FreeBSD I'm using, it's 9.0-RELEASE, as it is in this case. Is this maybe the
cause of confusion?
If you're still unsure why the build fails, please let me know how I can help
to resolve this issue.
Thank you!
Erm.. that's confusing. I've never seen this build problem before. The
modules should build fine..
On 29 December 2012 07:29, wrote:
> Hi,
>
> here's my new config: http://nopaste.info/7c11afee7c.html
> and here's the complete kernel build output:
> http://nopaste.info/34db985f16.html
> The err
Hi,
here's my new config: http://nopaste.info/7c11afee7c.html
and here's the complete kernel build output: http://nopaste.info/34db985f16.html
The error message is this:
cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I.
-I/usr/src/sys/modules/ath/../../dev/ath
-I/u
Oh, comment out the if_ath_pci device too.
Sorry, forgot about that.
adrian
On 28 December 2012 03:48, wrote:
> Hello again,
>
> here's the new kernel config: http://nopaste.info/d7929aa100.html
> and here's the make output: http://nopaste.info/ae7826ba48.html
> The error messages I get whe
Hello again,
here's the new kernel config: http://nopaste.info/d7929aa100.html
and here's the make output: http://nopaste.info/ae7826ba48.html
The error messages I get when building are these:
cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -g -Wall
-Wredundant-decls -Wnested-e
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.
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 comm
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 m
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
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
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
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 wi
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
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 w
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 some
22 matches
Mail list logo
