FW: pci_find_device returned value?

WANG,YIDING (yiding_wang@am.exch.hp.com)
Fri, 25 Jun 1999 11:26:20 -0600


Thanks for the help fromall of you so far. I have downloaded kdb but
haven't figured out how to use it yet. It looks scary to recompile all
kernel which is required by involving kdb. I will try it later.

One question now. When call pci_find_device(), the returned base address
are:
base[0]= 0 (Reserved, in our case)
base[1]= 6501 (Low IO Address)
base[2]= 6601 (Hi IO Address)
base[3]= e10600000 (MEM Base)
base[4]= e10000008 (RAM Base)
base[5]= e10400000 (SROM Base)

The base address 3, 4, 5 look like virtual address. Is that true?

In my driver, after I get those address, it was converted to virtual address
with bus_to_virt() function call. If the returned address is virtual, then
no need to convert.

Thanks!

-eddie
-----Original Message-----
From: Stephen C. Tweedie [mailto:sct@redhat.com]
Sent: Monday, June 21, 1999 3:20 AM
To: WANG,YIDING (HP-SanJose,ex1)
Cc: 'Stephen C. Tweedie'
Subject: RE: Again: Redhat 6.0 kernel paging fails

Hi,

On Fri, 18 Jun 1999 13:06:46 -0600, "WANG,YIDING (HP-SanJose,ex1)"
<yiding_wang@am.exch.hp.com> said:

> Thanks for the response. At least I know that the community has some
people
> really can help.

> You are right about the address. The matter of fact is I have no idea in
> what case that the message of "Unable to handle kernel paging request at
> virtual address 0001c000" comes out? The address looks like a physical
> address to me.

The oops always occurs from a CPU page fault, and because it is coming
from software the fault address is always virtual. And yes, it looks
like a physical address: that's the entire reason for the oops, you
have tried to dereference an invalid virtual address.

The important thing to look for in the oops is the EIP and the stack
trace: that tells you exactly where in the kernel the fault occurred,
and what the call trace on the stack looks like. ksymoops (in
linux/scripts) will decode this.

> It's a virtual address Another thing is since there is no kernel
> debugger in Linux,

gdbstub: ftp://ftp.gcom.com/pub/linux/src/

Remote serial debugger (requires two machines, lets you run
gdb over the serial port between them, allows full
source-level kernel debugging)

SGI debugger: http://reality.sgi.com/slurn_engr/

Built-in kernel debugger

> I was trying to glook into source code to find where this message
> comes out but not being able to so far. I down load source code
> from RedHat 6.0 CD-ROM with rpm command. There are many files ended
> with *.gz which is not readable. Do you know how to make it becomes
> text file?

gzip/gunzip. The kernel source is in the kernel-source rpm, though.

--Stephen

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/